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
