Can't block webconfigurator on the wan.

EricAiken

tried changing the config.xml with a listen statement, that is ignored.

Implications

You cannot restrict the webConfigurator to LAN only via config.xml in 2.7.2.

Any “attempt” to bind it using <listen> is ignored, which explains why sockstat still shows * :443.

This means WAN exposure must be controlled purely via firewall rules, because the GUI process will always listen on all interfaces., but the firewall rules are ignored.

This can't be correct.

EricAiken

the more and more i delve into this the more concerning its getting. It's looking like in 2.7.2 and 2.8.0, you can not unbind 80,443, and 22. It's bound to all interfaces and nginix kernel. And that can't be changed.

Since I can't block those ports with rules on the WAN interface. The only suggestion is to change the port from 443 to something else. However that still leave port 22 wide open.

Do I really have to put a firewall in front of pfsense just to block these three ports?

Please tell me what I'm missing.

EricAiken

I can't believe this:

I changed the webconfigurator to 8443, and it immediately exposed port 8443 to the web, and ignores blocking rules on 8443. WTF?

johnpoz

@EricAiken you say external nmap - running nmap on your internal network hitting your external IP is not an external scan.

Those rules blocking 443 and your webcfgports are pointless since unless you allow traffic it is blocked by the default deny anyway.

Go to something you can send traffic to wan IP from, can you see me . org - or even use the grc scanner.

EricAiken

@johnpoz nope, running from an external ip.

patient0

This post is deleted!

johnpoz

@EricAiken all traffic is denied unless allowed by a rule - if you are seeing open traffic from external to your wan IP. Then you have a rule open - what is in your floating tab.

You have never been able to unbind the gui from specific interfaces, it always listens on all IPs. Same goes for ssh. This hasn't changed in forever.

BTW your attempt at blocking 443, you have 443 as the source port.. That isn't going to be something you would normally every see.

edit:
You sure its not something in front of pfsense answering.. Do your packet capture on your wan, do your scan from external - you see that traffic specific hit your pfsense, and an answer.. So your state table with this traffic and pfsense answering. For pfsense to see traffic and answer you would for sure see both of those things.

example: Here is outside hitting my ports.. both 22 and 8443 which is what my gui listens on. But as you can see no answers, since I have no rules that would allow that traffic on my wan or in my floating tab.

Here you see that those are the ports in use, and you can see my PC currently connected to them via the lan IP.

SteveITS

@EricAiken Check https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#new-rules-are-not-applied ... you should not need to add a block rule since the default rule is to block.

Your fourth rule to block to WebCfgPorts has matched something (0/44B).

stephenw10

If it was something upstream the port wouldn't change when you change the pfSense gui port.

It pretty much has to be a floating rule or interface group passing that traffic.

If you look at the states at the CLI using: pfctl -vss you can see the rule that opened the state.

Then check the rules with pfctl -vsr to see what that rule is.