Forwarding port 80 did`t work
-
Hi I need to forward port 80 to an internal webserver. I created 2 nat rules for http and https. After this I changed the pfsense port to 444 and enabled "Disable HTTP Strict Transport Security". But I still can`t connect with http. Any ideas? https and all the other ports are working fine
-
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
What packages do you have installed, if any? Are you testing from inside or outside your LAN?
Connect to console, shell in and run:
sockstat -4 -lWhat do you get for output?
-
Hi I have no packages installed. If I connect to the server internal with http/https its no problem. If I connect external with https its fine only if I use port 80 nothing happend.
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root xinetd 83672 0 tcp4 127.0.0.1:19000 :
root xinetd 83672 5 udp4 127.0.0.1:19000 :
root xinetd 83672 6 tcp4 127.0.0.1:19001 :
root xinetd 83672 7 udp4 127.0.0.1:19001 :
root xinetd 83672 8 tcp4 127.0.0.1:19002 :
root xinetd 83672 9 udp4 127.0.0.1:19002 :
root xinetd 83672 10 tcp4 127.0.0.1:19003 :
root xinetd 83672 11 udp4 127.0.0.1:19003 :
root syslogd 99090 8 udp4 *:514 :
dhcpd dhcpd 58704 7 udp4 *:67 :
root ntpd 53462 21 udp4 *:123 :
root ntpd 53462 23 udp4 146.4.2.190:123 :
root ntpd 53462 25 udp4 192.168.1.1:123 :
root ntpd 53462 29 udp4 127.0.0.1:123 :
root nginx 52357 5 tcp4 *:444 :
root nginx 52226 5 tcp4 *:444 :
root nginx 52026 5 tcp4 *:444 :
unbound unbound 47087 5 udp4 *:53 :
unbound unbound 47087 6 tcp4 *:53 :
unbound unbound 47087 9 udp4 *:53 :
unbound unbound 47087 10 tcp4 *:53 :
unbound unbound 47087 13 udp4 *:53 :
unbound unbound 47087 14 tcp4 *:53 :
unbound unbound 47087 17 udp4 *:53 :
unbound unbound 47087 18 tcp4 *:53 :
unbound unbound 47087 19 tcp4 127.0.0.1:953 :
root php-fpm 335 4 udp4 : :
root php-fpm 334 4 udp4 : :
root php-fpm 333 4 udp4 : : -
OK, so there is nothing listening on tcp/80 on pfsense that would conflict. Your WebGUI is definitely on tcp/444. Are you sure your http NAT rule is good?
-
-
OK, next is to start doing some small packet captured on WAN and LAN while making a request to your tcp/80 NAT. Again, always test from OUTSIDE your LAN. That may mean using your mobile phone or some other location like your work, or a VPN if you have one. Do your captures and then check them. Is WAN seeing the incoming request? Is LAN passing it to your web server?
-
I am testing from outside. I am just connected to the internal pc with teamviewer. If I am doing a port check from outsite from https://ping.eu/port-chk/ I got port 80 is closed. Funny thing is I have the same problem with port 5900.
If I check the webserver from a LAN computer its fine. I could connect to it. If I try to connect from outside I don`t have any entries at the firewall log from my wan ip here.
-
So do the packet capture like I said and see what it shows you. Perhaps your ISP blocks incoming tcp/80 traffic for consumer accounts?
-
I talked with the isp. They told me if I using the hardware in bridge mode nothing will be blocked from them. So it must something at the firewall. It`s the same with port 5900 also closed.
-
Well, every port should be "closed" if there is nothing listening on those ports on the firewall or being forwarded to LAN.
Go to Diagnostics - Packet Capture. Set it for WAN. Get ready to try and load your http server and then click Start. Hit the server. Click Stop. Either post the capture output here for me or someone else to look at or load it up in Wireshark and look at it yourself. If you post it here, obscure any public IP details. Look to see if WAN is seeing these http requests at all. Do the same thing but select LAN. See if pfSense is passing the packets on.
-
I don`t see any request at port 80. I see all the 443 access etc. I posted it here http://bit.ly/2OmMMft because Akismet is telling me its spam
-
Sorry, I should have told you to narrow the capture using the protocol and port fields. That said, if your WAN isn't seeing the tcp/80 traffic then something is blocking it before it gets to your WAN.
-
Thanks for your help. After a couple of calls with the ISP they found the problem on there site :)
-
@bchristopeit I have the same problem, how did you solve it?
-
OP hasn't been here since he posted that so I doubt he will reply.
He said he called his ISP, and they had configured something incorrectly. They probably flipped his modem into bridged mode.
-
@KOM Entiendo, muchas gracias
