Make the web GUI only listen on LAN interface?
-
Is it possible to make the web GUI only bind to the LAN interface?
I ask because I'm trying to have the web GUI be on port 443 from my internal network, and have OpenVPN on 443 from the external network. And in fact I had that working - I set up OpenVPN, told it to only bind to the WAN, and everything "just worked" as I wanted it to.
...until I restarted the device, months later. Then when it came up, OpenVPN grabbed 443 on the external IP, but nginx tried to grab *:443 and failed (because OpenVPN already had it), and the web gui didn't come up.
After much gnashing of teeth, and a new USB Mini-B cable so I could get to the serial console, I identified the problem and realized I just needed to tell the web GUI to only bind to the LAN interface. But there appears to be no such setting to do so.
And to be clear, firewall rules don't help here; I need the service to not even try to bind to *:443.
I know, some people will think the "better" option is to switch one of the services to a different port, but either of those alternatives is full of headaches, so I want to avoid them if possible. And my goal seems like it should "just work" if it was configured correctly. (And it has been working, for months, because I manually started OpenVPN second! Although I don't entirely understand why it worked, now that I see the problem.)
-
@truist For reference only, and making the assumption that you've not seen it already—this is what the official documentation has to say on the subject.
I personally wouldn't bother with whatever hacking may be required to modify the system
nginxconfig when thewebConfiguratorlistening port is modifiable from the GUI. (I've also seen lots of folks configure their OVPN instances to listen on 4433, as you seem to be well aware.) But that aside, I'm sure there's a bunch of otherwise hacky ways to skin this cat.You've already created a headache for yourself by unwittingly configuring both to listen on the same port. Why shoot yourself in the foot and reload?
Gratutious mention of
Diagnostics / Socketsto keep an eye on whatever configuration changes you make end up actually doing. -
HAProxy could also be used here. Change both GUI's and OVPN's listening ports, HAProxy listening on 443, and let it proxy any/all requests accordingly. This feels as 'clean' and headache-free (once successfully configured of course) as it could get.
On the other hand it introduces a single point of failure to accessing either service without explicitly specifying port in the request...
-
@tinfoilmatt thank you for the responses!
I didn’t see anything in the docs that seemed to be arguing against this, but it sounded like you thought there was? Am I missing it?
I agree that I got myself in trouble with this already but that’s because I just assumed that the web configurator would only bind to the internal interface… and I thought the success of OpenVPN in binding to the external interface “proved” that that’s what it was doing. But apparently there’s something about how that works that I still don’t understand.
And now that it’s been working this way for a few months, I’d have to update all the clients if I changed the port. Admittedly that’s only a half dozen or so.
But the other problem is that it was on 443 on purpose, to make it less likely to be blocked by traffic blocking systems out in the world. So ideally it would stay on 443.
Thanks for the tip about that diagnostics page - I didn’t know about it.
The haproxy idea is interesting, if there really isn’t a built-in way to do it. I agree that manually messing with the nginx config is fraught with peril.
-
@truist said in Make the web GUI only listen on LAN interface?:
I didn’t see anything in the docs that seemed to be arguing against this, but it sounded like you thought there was? Am I missing it?
No, no—was merely linking to what the docs offer about the webConfigurator's listening port (which says nothing about interface binding/s, that's right).
the web configurator would only bind to the internal interface
This definitely feels like it has the makings of a coherent feature request. Documentation on that here.
The haproxy idea is interesting
I've set out to take on a robust HAProxy config on my personal system a number of times, and for a number of different reasons which would all be satisfied by doing so. But I have yet to get around to any of it. Definitely a rabbit hole's worth of information on how you might pursue this angle here on the forum.
Edited to add:
But the other problem is that it was on 443 on purpose, to make it less likely to be blocked by traffic blocking systems out in the world. So ideally it would stay on 443
Totally valid and bolsters the use of HAProxy to fully accomplish what you're trying to do.
-
@truist here is my take, while it should be an easy setting in the web gui to have the gui only bind to specific interfaces.. This is currently not an option that I am aware of.
Here is what I do to get external use of 443 on the wan or openvpn and other services, you can have your cake and eat it too without having to mess with the nginx config.
Change your pfsense gui to use a different port, I use 8443. Now in in your openvpn config setup port sharing.
in the bottom of the page in your openvpn server setting there is custom options, set
port-share 127.0.0.1 9443
Where you can use any port you want here that is not already in use. Have your haproxy listen on that port.. Where it sends what ends up hitting that port to where you want behind pfsense.
So openvpn listens to the 443 traffic, and says - oh this isn't openvpn traffic and sends it on to the 9443 port, where ha proxy picks it up and does whatever you have setup for it to do.
True your web gui for pfsense now is on 8443, but only admins should be using this anyway, once you setup a bookmark who cares what port the service is actually listening on.
but now you can use 443 on the public side for openvpn, and you can also leverage it for services your hosting behind pfsense. For mine it goes to system so my users can request movies for me to put on my plex.. Because users are pretty stupid - I just tell them to go to my fqdn, and they are in - no need to tell them to use a specific port in the url
-
@johnpoz interesting setup. I guess I'm not sure why that's better than just having haproxy on port 443, splitting all the traffic to "real" services on other ports? Right now, it seems like your web admin traffic has to go through OpenVPN, then haproxy, then the web admin. That's three possible points of failure for one service.
-
I went to file a feature request for this, and it turns out there already is one... 15 years old, and marked "low priority"
-
I got burnt with this my post
I ended up changing pfSense GUI to 8443 and using 443 for TCP and UDP OpenVPN
-
@truist who admins pfsense from the wan?
3 points of failure??? What? Haproxy zero to do with my pfsense web gui - it provides a webserver I run on another box it to my network for users of my plex, to request stuff. But yes if open is down on that tcp 443, then no users can not get that services. Has zero to do with admin of pfsense, and is not the only way to get vpn in, also have 1194 open and also tailscale, etc.
Its just a way I can leverage 443 for openvpn and a service at the same time.
-
@johnpoz oh, I see. I thought you were still using haproxy to route traffic to the webgui. I just misread your original post.
-
Here's the gun and a bullet :
Add the LAN IP right here :
Btw : the ssl (port 443 normally) nginx will be 'locked' to the LAN IPv4 - as you can it still listens on all IPv6 interfaces.
Further down you'll find the place where you can do the same thing for the http (non-ssl) access.
I didn't test this.
The file is : /etc/inc/system.incHappy hunting
