Port forwarding port 80 sends requests back to the pfSense web interface
-
Just posted the config. Same result with HTTP checked instead of HTTPS in System > Advanced (with the exception that, as expected, I can no longer get to the WebGUI since TCP/80's forwarded to the internal host and WebGUI is no longer listening on HTTPS).
I will have to play later…
Ive been using since pre 1. days so may have skewed understanding here and there.
nipstech- anything to add? ;D
-
I re-created the NAT and now it's working…I'm puzzled???
-
Now I'm having a different problem. When I try to access a web page on one of the domains I'm hosting locally using my local network (LAN) it times out. When I try to access it from a public network (OPT1) I get a "connection reset" error. The IIS log shows the packets never reach the server.
-
@nipstech:
Now I'm having a different problem. When I try to access a web page on one of the domains I'm hosting locally using my local network (LAN) it times out.
You're probably using an external DNS server for your LAN hosts. Have you tried entering a host override in your DNS settings to resolve the domain name against an internal address? As for the second issue, have you checked the routing on your web server is correct?
-
For my internal (LAN) hosts I'm using MS DNS since I have an Active Directory domain. The domain's DNS is set to forward external requests to pfSense. pfSense is set to use 127.0.0.1 and OpenDNS. I'm not sure what you mean by routing but IIS is bound to the server's IP address and host headers both with and without the www.
 -
Ok, so let me rephrase it: When you do a lookup against your web site name (I assume www.birch.net) from within your LAN do you get your web server's internal address or the external (internet-facing) address? The routing I refer to concerns the web server. Is it's default gateway set to the firewall where the returning traffic has to lead back through?
-
When I do a lookup I see the external address. The default gateway on the server points to the firewall.
UPDATE: I changed the DNS settings on the firewall and deleted the 127.0.0.1 entry. Now I can access the web server from my LAN but when trying to access it from OPT1 I get the message that the connection was reset.
-
Just posted the config. Same result with HTTP checked instead of HTTPS in System > Advanced (with the exception that, as expected, I can no longer get to the WebGUI since TCP/80's forwarded to the internal host and WebGUI is no longer listening on HTTPS).
This is one of those "Legends of pfSense" that likely has more basis in outdated, amateur youtube walkthroughs than in reality. Maybe it used to be the case.
Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system.
What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No.
-
@nipstech:
When I do a lookup I see the external address.
This problem comes up a lot on this forum. Your LAN clients are trying to access a local web server by bouncing the traffic off your firewall's external address back into your LAN/DMZ. The better way to do this is to create an A record in your AD DNS server for your internal web server resolving to it's internal address. That way traffic on your local network will stay in your local network and hit the web server directly. Your external DNS should resolve to the external address so that the traffic is correctly directed to outside firewall interface.
@nipstech:I changed the DNS settings on the firewall and deleted the 127.0.0.1 entry. Now I can access the web server from my LAN but when trying to access it from OPT1 I get the message that the connection was reset.
Sounds like your port forward rule isn't correct. Post your NAT and firewall rules for the WAN-2-LAN traffic to your web server.
-
Ok here they are…
I really appreciate all the help :)
-
@cmb:
Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system.
What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No.
Im trying to remember where I got this "bad behavior" but would have only taken once for me to hold onto it. :o ;D Since I use a different port on the GUI anyways Ive never really tested it after the first time.
-
@cmb:
Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system.
What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No.
Im trying to remember where I got this "bad behavior" but would have only taken once for me to hold onto it. :o ;D Since I use a different port on the GUI anyways Ive never really tested it after the first time.
Not to resurrect any posts here… But I ran into the same issue as OP. Only my NAT rules were correct (as proposed by Derelict). In my experience, on PfSense 2.3.4, PF RDR does not take precedence, and will cause you to get locked out of the gui if you configure it to forward 80 to a different server. The only thing that works, is as ChPalmer describes; Change the port the WebGUI is listening on and disable the redirect, so it doesn't keep listening on 80. Then, and only then, the PF succeeds. To reflect on CMB; It was not a browser cache in my case. For the OP's 'other' issue; You probably forgot to open 80 somewhere on your destination server (or along the route).
Why this comment?
If PF RDR should take precedence always, which would be a great feature, it is not working. Maybe a bug fix is in order.Thanks all.
