Unbinding Webconfigurator from WAN 443

jsnl

I've read lots of older posts, and I've been frustrated by all of these people who are asking for a totally normal thing - to not allow their Webconfigurator to bind to a particular interface - who all get met by an avalanche of "The firewall blocks this anyways so there's no need" responses.

I'll give you my use-case. On each of my boxes I run two OpenVPN servers. One is on a standard port in UDP world, one is on 443 in TCP world. Why? I have two clients with over-zealous IT departments that block a ridiculous number of outbound ports for "security". They also block so much web traffic that their networks are basically unusable. Modifying the departments' behavior is not an option. Using this tunneling trick works well because to their DPI the traffic looks the same as web traffic. They're not smart enough to look at connect time.

I have 4 working pfSense installations. One on a VM, three on cheap non-native hardware. On three of my four installations, I have a normal OpenVPN server, and my 443 one. They all work exactly as anticipated: I bind OpenVPN to WAN, make an allow rule to 443 on WAN and I access the VPN as intended. However one of the cheaper boxes instead has a race condition where OpenVPN and Webconfigurator fight to grab the port first. Most of the time OpenVPN wins and the behavior is as expected (LAN gets Webconfigurator and WAN gets OpenVPN)... but on a few reboots I've found my Webconfigurator available to the public internet. More recently I've started finding (likely through a recent update) that if Webconfigurator loses the race, it doesn't bind to the LAN address either - making the GUI inaccessible.

I am aware that I could change the port the Webconfigurator binds to. That's not my desire. It is a totally reasonable ask to be able to disable Webconfigurator from binding to an interface. It is a thing that used to be available as a setting, and it's been removed. And to me it doesn't make sense why it's been removed as it seems like it would only aide in additional security and allow for the port to be re-used instead of unnecessarily held on interfaces it's not wanted on. I'm also curious why it works flawlessly on three boxes including two identical ones - but not this one. Was it possible I set the setting a while ago when it was still available and the configurations held?

Can the Webconfigurator binding be manually changed? Also, can we get this feature back in the GUI?

Bob.Dig

@jsnl said in Unbinding Webconfigurator from WAN 443:

I am aware that I could change the port the Webconfigurator binds to.

It is the first thing I do, problems gone. There are other postings where people describe their problems with unbound not listening on all interfaces or interfaces, which are not up at certain times etc. So there are reasons to have it bind to all. There is no more to desire for me at least.

stephenw10

Hmm, I'm surprised that works on any install to be honest. I would expect to see port conflicts and the OpenVPN instance fail to start.

There's no pfSense config option to allow it as you found. Just wondering if you could use port share somehow:
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/port-share.html
Can't see a way.

What you could do though it forward incoming TCP port 443 connections to OpenVPN on a different port. That will prevent any conflicts and also prevent external access to the gui directly.

jsnl

@stephenw10 I wondered that as well. And I hadn't even given it a second thought until I realized that it WASN'T working on one of my boxes, and then I started to wonder why it worked on ANY of them. But it does in fact work on 3 out of 4. And I don't have a good idea why.

So what would the mechanics of that port forward be? Forward from WAN:443 to 127.0.0.1:4443 and set the VPN to be TCP:4443? Would I need to change the OpenVPN Endpoint Configuration Interface to be Localhost instead of WAN?

stephenw10

Yes I would probably use localhost because it's a common config with multiwan setups. Yes you would need to set the OpenVPN server to run on localhost, or 'any'.

But you could just use it as a port forward to port 4443 on WAN still.

marcosm

@Bob.Dig said in Unbinding Webconfigurator from WAN 443:

which are not up at certain times etc

Essentially this. Once the WebGUI binds to a specific interface or address the risk of instability is significantly increased. That risk is not worth the questionable "additional security" of not listening on all.

jsnl

@marcosm Is this a Nginx thing or a function of something else? How does binding to all change that?

Typically the binding is to more than one interface (in my instance it would be LAN, OPT1 (my anti-lockout), and Localhost. I'm not an Nginx kid, I grew up on Apache... but I don't remember that problem on Apache.

Would Watchdog help?

jsnl

@stephenw10 I'm trying to think through the logic flow with an inbound connection to 443 and a server on localhost at 443. I know the firewall routing happens first, but is there anything I need to watch out for to make sure the Webconfigurator doesn't get exposed? Any sort of extra deny or sanity rule? I guess I could add my local subnets to the Login Protection / Pass List as extra insurance....

Gertjan

@jsnl said in Unbinding Webconfigurator from WAN 443:

Can the Webconfigurator binding be manually changed? Also, can we get this feature back in the GUI?

Of course you can.

While

avalanche of "The firewall blocks this anyways so there's no need" responses.

stays true, as it is implied that you have to have confidence in your firewall ( ) you can find posts here on the forum how to do that. Here's one of them ?.

The 'Webconfigurator' is nothing more as a web server that servers you web page. The web site, the GUI, is actually nothing special.
The GUI or 'Webconfigurator' is 'just' nginx, the web server, that does what it is told to do :
"Listen on all interfaces".
So, the solution is : "tell it to listen on one (or more) interface(s) you decide".

nginx, the GUI oir uses this instructions file : /var/etc/nginx-webConfigurator.conf when it start.
Look at the last these lines :

	server {
		listen 80;
		listen [::]:80;
		return 301 https://$http_host$request_uri;
	}

You saw the 'listen' lines ?
That's where it's told to listen on .... all interfaces, as none are specified.
Btw : The first listen is for IPv4 and the second is for IPv6.

There are thousands of publication on the Internet about how to proceed, I'll pick one :
How to make nginx to listen to server_name:port

So, you might thing : I make a copy of the /var/etc/nginx-webConfigurator.conf , edit the original, save and done.
Right ?
Wrong !

When you changed the file, nginx, the process, only parses (uses) it when it starts.
So you restart nginx with console menu number 11.
What does pfSense (always, for all processes !!) will do : fist, it creates a config file for the process to be started, and it uses the GUI settings for that, and then it starts the process.
This means your own edits are gone ...

The real solution is : you have to edit the 'thing' that creates the /var/etc/nginx-webConfigurator.conf file.
It's this file : /etc/incv/system.inc, a text file, it's a PHP script.
Use the find command, and find the first 'listen'.

Scroll a bit upwards, and you find that you're in the "function system_generate_nginx_config" part.

If your LAN IPv4 is "192.168.1.1" then all you need to do is

		$nginx_config .= "\t\tlisten 192.168.1.1:{$nginx_port} ssl;\n";

and save.
Restart the GUI with the console, ssh, or edit a part of the GUI that sets GUI options, like System > Advanced > Admin Access and you're good.

Test :

[26.07-RELEASE][root@pfSense.bhf.tld]/root: sockstat -4 | grep '443'
root    nginx        619  5 tcp4  192.168.1.1:443       *:*
root    nginx        396  5 tcp4  192.168.1.1:443       *:*
root    nginx        280  5 tcp4  192.168.1.1:443       *:*

From now on, the pfSense GUI will use the (my) LAN IPv4 to listen on.

Try also a

sockstat | grep '443'

Maybe you also have to deal with the IPv6 part, I'll leave that one up to you ^^

Several things to be ware of :
You will create a potential shoot in the foot situation.
What if you decide to change your pfSense LAN IPv4 to some other IP ?
You have to remember to redo these edits also.
Also : when you update pfSense, files like /etc/inc/system.inc will be updated, so your edits (10 key strokes max) will be lost.
Hardcoding values is normally not a good thing, as admins are people, and people tend to forget things.
Last but not least : see my post as a proof of concept, not a 'do this, and it works'. There might be (will be) other (even security ?) consequences.

stephenw10

@jsnl said in Unbinding Webconfigurator from WAN 443:

I know the firewall routing happens first, but is there anything I need to watch out for to make sure the Webconfigurator doesn't get exposed? Any sort of extra deny or sanity rule?

Exactly, because the NAT rules are applied to incoming connections before the filter rules your firewall rule on WAN would pass traffic on port 4443. Thus traffic cannot hit the gui on port 443. If it some how didn't match the NAT rule the filter rule will not pass it.

jsnl

Well a big thank you to @Gertjan and @stephenw10 - apparently I don't have the reputation to upvote but if I did you'd receive them!

This is exactly what I was hoping for. I like the "Here's how normal people would do it" answer, AND the "If you're insane and like breaking things each time you update, here's that path" answer. I do have fixed IPs on this box that won't change, but I also hadn't given thought to doing a local port redirect. I get so entrenched in NAT and port-forwards that sometimes you forget that you can do the same thing on the same machine.

Unsure which path I'll take, but I appreciate both methods!

johnpoz

@Gertjan you forgot the part when they come back at some point and say they can't get to their gui, with zero mention of makings such changes.

Gertjan

@johnpoz

Didn't forget that part, and started to write a phrase like "Don't forget to stick a yellow post-it on your router"? but I scraped it.

jsnl gave me the impression that he's aware of this.

But ok, true, others, who find this post later on and use it : be warned ^^

Ankalaev

The port-forward approach seems like the cleaner solution here. Keeping the WebGUI bound normally and forwarding WAN:443 to a different local OpenVPN port avoids relying on a manually modified system.inc, which will get overwritten on updates.

The manual nginx binding is interesting as a proof of concept, but having to reapply it after pfSense updates (and remembering to change it if the LAN address changes) makes it pretty easy to lose access to the GUI later.

I’d probably go with the local port redirect and leave the generated Webconfigurator config untouched.