Cannot open for after using secure SSL
-
Hi, after i use dyno and let's encrypt for my SSL, i try to add new ports to open but when i check using port checker all the new ports cannot be open, but all the old ports is still open,
i try to use the old port and change the IP, then i access the website on public, but when i try to add new ports. it was closed.
sample:
port 83 is old port (before i use secure SSL)
port 8013 is new port ( after i use secure SSL )did anyone experience this problem ?
thank you.
-
@ipcam.starinc well that checker does is send a syn.. If it gets no syn,ack back then yeah it would fail. So 192.168.2.177 isn't listening on port 8013 or it has a firewall not allowing traffic too that port.
-
@johnpoz i can access it on local network. 8013
-
@ipcam.starinc said in Cannot open for after using secure SSL:
i can access it on local network
This mans your pfSense LAN interface allow TCP traffic to port 8013.
When you are using the "port checker" (some web site ?), the traffic will not use the LAN interface. It will use the WAN interface.
So the question is : does your pfSense WAN interface allow "TCP to port 8013" traffic ?
This :
shows the NAT rule. Each NAT rule has an associated firewall rule. You will find them on the WAN interface. These firewal rules have matching packet counters ( !!) in front them.
If these counters start to raise, you know they were 'used' (== matched) and traffic entered the WAN interface using that rule.So : what do these counters show you ?
Does your TCP port 8013 traffic even reached pfSense ?Example : some of my WAN NAT Firewall rules :
The first shows the good old IPv4 : 11+ Mbytes of traffic.
The second shows the incoming IPv6 traffic for the same device : 7+ GBytes of traffic. -
Perhaps more accurately it means the server at 192.168.2.177 allows connections to port 8013 from local hosts but it might still be blocking external hosts. Either way it looks like a firewall issue on the server directly to me.
But to be sure try checking the state table (Diag > States) in pfSense when you run the external port checker. Do you see it open states for port 8013 on both interfaces?
-
thank you for the help guys. i fix the problem. i use 443 and HAproxy.
thank you
-
@ipcam.starinc not really a "fix" if you have device X on your network listening on port X, you can forward that port.. If its not working port X is not getting to pfsense wan, internet block, or incorrect setup on pfsense firewall to allow it.
Or your device X is not actually listening on port X, or it has a firewall blocking traffic to X from the source IP.
etc.. etc.. The "fix" if you want to forward that port is to actually fix what is stopping that from working. What your doing is working around your actual issue. Which is fine, but would still be good to know what the actual problem was - if port X is blocked to pfsense, using port Y that is not blocked works but I really wouldn't call it a fix ;)
-
@johnpoz i really don't the problem, but any one of this port i use on my block website. then i can access it on public.
the only problem i have is to access it on public no problem on local networks.
-
@ipcam.starinc well troubleshoot the problem - first thing in any port forwarding is to validate the traffic actually gets to your wan.
Go to like can you see me and send traffic on port X
Do you see the traffic? If not then something in front of pfsense is blocking it, and no your never going to get a port forward to work.
Lets take your original example.. Can you see me . org
It is a 2 second check, but necessary because if you can not see this traffic on your edge - there is no possible way you could ever get it to something inside your firewall.
I have no port fowards for this, I do not listen on that port on pfsense, etc. etc.. But none of that is needed to validate the traffic is actually being seen by pfsense. Just a simple packet capture.
If you see this traffic - then setup sniff on the pfsense interface used to send the traffic - do you see it being sent, do you see a state being created? If not then you have something in pfsense firewalls blocking it, or do not have your port forward setup that evaluates the seen traffic correctly to be sent.
If you see pfsense send it out the proper interface to get to where you are fowarding and you get no answer then the problem is down stream of pfsense.
It should take no more than a couple of minutes to figure out where the issue is.
-
The fact the server is reachable locally but not from an external port forward still points to a firewall rule on the server IMO. Though it could also be a routing issue if the server has no route back.
Proxying the connection just means all the connections to the server are local which is why it now works.
