Prevent webGUI from binding on WAN interface - Oh, the horror
-
I am using the HAproxy package in pfSense to reverse proxy for two backend servers. To my horror, when opening http/s ports on the firewall and testing access to my servers through the proxy, I found that the pfsense webGUI login was reachable.
One thing I know is that I never want the web gui reachable from the WAN. How can I prevent this? How are people confidently using reverse proxies when the webGUI binds on all interfaces?
-
How exactly are you opening the ports?
-
No idea what are you doing there. Move the webGUI from 80/443 to somewhere else and don't open the firewall ports there.
-
I'm opening the ports by setting an allow rule from any ip:port to the wan IP:80 and 443.
-
And now, even after disabling those allow rules and uninstalling haproxy, port 80 and port 443 are permanently left open despite no rule allowing them. I wonder what happened here. I will shut down the router until I have a chance to restore a backup.
-
You really have no clue what you are doing, have you…
-
I generally do have a clue what I'm doing. But in this case I don't know why my system is behaving this way, so I'm asking for help. Indeed, I don't have a clue why.
-
Hmm, actually, my mobile app port scanner (operating from cell connection) is saying the ports are open, while two internet website port scanners, GRC Shields Up and WhatsMyIP.org, both say they are closed. Seems like my app is giving me bad information.
-
So, it's not just the app. nmap scans from different public IP's yield different results.
-
Bah. Looks like my modem or something else in front of pfSense has the ports open and responding to port scanning. Here's why I think that.
Packet capture on WAN for port X while running nmap against that port -> packets (ARE / ARE NOT) observed in capture
48719 ARE
80 ARE NOT
443 ARE NOTBless it. >:(
-
dont be offended but are some of your test are conducted from the LAN side to the WAN address?
-
Thanks for the idea, but no they are not.
-
"something else in front of pfSense has the ports open and responding to port scanning."
If that was the case how were you getting to the pfsense webgui from the internet as you say? Where you testing from inside your network when you were going to your public wan? If you were testing from your phone maybe it was on wifi at the time vs just your cell network?
If you are creating traffic to your public IP on ports X,Y and or Z and your not seeing it on pfsense then either you have a nat in front of pfsense? And the traffic is not forwarded or isp is blocking it, or something is intercepting it between when you test and pfsense. None of which makes sense when you stated you were getting the pfsense web gui in your first post.
-
I was thinking about that, too. I can't explain it why I could see the management interface before from a public IP despite this apparent interception of packets.
I frequently disconnect my phone from WiFi and use it to test how my IP appears from the open internet. I'm fairly confident that I didn't forget to turn off WiFi when I noticed that the admin interface was available via WAN. Also, other threads on this forum corroborate that the management interface binds on all Interfaces. Seems like a security problem to me, but no one other than the OPs seems to care in those other threads.
Rather than fighting pfsense, the easier path is to just move the management ports (as our testy friend suggested) and keep them blocked rather than doing something risky and more complex like trying to keep the standard ports but not binding on certain interfaces.
Getting back to the mystery of how some packets are intercepted before hitting my firewall and some aren't. I wouldn't put it past a cable provider or cable modem manufacturer to be interfering with my connection, maybe even in intermittent ways. I will know more after I set my reverse proxy back up after tearing it down thinking it was somehow interfering with critical aspects of the firewall.
