pfSense Web UI accessible even without rules

viragomann

@nazar-pc said in pfSense Web UI accessible even without rules:

There isn't anything explicit that would allow Web UI on it and access from the WAN side is not enabled in firewall either

The question is, why the gateway routes the LAN IP to pfSense. Seems there is a static route added to it.

This is really strange, it should have been added as a rule that can't be modified like other rules of this kind (Anti-lockout for instance).

It makes sense to allow DHCP requests implicitly if the DHCP server is enabled though. DHCP requests go to the broadcast IP or the interface IP and the source is 0.0.0.0, if the device doesn't have an IP address already. There cannot be any other destination, wouldn't make sense.
But you can add custom rules for blocking DHCP if you want though.

Regarding DNS it behave a bit different. There can be different source IPs and destination IPs depending on the configuration of the requesting device.
pfSense cannot know, what you like to allow.

nazar-pc

@viragomann said in pfSense Web UI accessible even without rules:

The question is, why the gateway routes the LAN IP to pfSense. Seems there is a static route added to it.

Not sure, I have not introduced any rules explicitly, it looks reasonable:

default		WAN_GATEWAY	UGS	6	1500	vtnet0	
8.8.4.4		WAN_GATEWAY	UGHS	9	1500	vtnet0	
127.0.0.1	link#5		UH	2	16384	lo0	
WAN_NET/24	link#1		U	3	1500	vtnet0	
WAN_IP		link#1		UHS	4	16384	lo0	
WAN2_NET/26	link#2		U	8	1500	vtnet1	
WAN2_IP		link#2		UHS	10	16384	lo0	
192.168.1.0/24	link#3		U	1	1500	vtnet2	
192.168.1.1	link#3		UHS	5	16384	lo0	
192.168.2.0/24	link#4		U	11	1500	vtnet3	
192.168.2.1	link#4		UHS	12	16384	lo0

Interfaces:

vtnet0 - wan
vtnet1 - wan2
vtnet2 - lan
vtnet3 - guest

@viragomann said in pfSense Web UI accessible even without rules:

It makes sense to allow DHCP requests implicitly if the DHCP server is enabled though. DHCP requests go to the broadcast IP or the interface IP and the source is 0.0.0.0, if the device doesn't have an IP address already. There cannot be any other destination, wouldn't make sense.
But you can add custom rules for blocking DHCP if you want though.

Regarding DNS it behave a bit different. There can be different source IPs and destination IPs depending on the configuration of the requesting device.
pfSense cannot know, what you like to allow.

Yes, knowing this after the fact makes sense, but not seeing this implicit rule in the interface is misleading. I guess this is a UX-related feature request, will submit it later.

viragomann

@nazar-pc said in pfSense Web UI accessible even without rules:

Not sure, I have not introduced any rules explicitly, it looks reasonable

The routes in question might be on the gateways.

With the policy routing rule, pfSense should direct the traffic to one of the gateways, but it seems that the gateways route the LAN IP back to pfSense for whatever reason.
You can investigate this by sniffing the traffic on the WAN interface.

Yes, knowing this after the fact makes sense, but not seeing this implicit rule in the interface is misleading. I guess this is a UX-related feature request, will submit it later.

You can check all rules out by running

pfctl -sr

This will also show the DHCP rules.

Gertjan

@nazar-pc said in pfSense Web UI accessible even without rules:

Hi, I have just added to my setup a GUEST network (192.168.2.1/24) with two rules on it:

Allow UDP 53 from guest network to "This Firewall"

so that DNS works

Allow any from guest network to !LAN through MultiWAN gateway

so that it has Internet access, but nothing else

The issue is ....

The issue is : your using 'not' or ! rules.

The web GUI listens to all avaible NIs (including WAN !).
This includes notably your GUEST network.
Your NOT LAN rule will not block the access to 192.168.1.x/24 so this is not an issue :

@nazar-pc said in pfSense Web UI accessible even without rules:

I can still access pfSense's Web UI through 192.168.2.1

Think again : 192.168.1.1 is NOT 192.168.2.1, so it rules matches, the traffic passes, you access the GUI.
My advice : stay away from NOT rules

nazar-pc

@gertjan said in pfSense Web UI accessible even without rules:

The issue is : your using 'not' or ! rules.
The web GUI listens to all avaible NIs (including WAN !).
This includes notably your GUEST network.
Your NOT LAN rule will not block the access to 192.168.1.x/24 so this is not an issue :

Everything that is !LAN was routed to WAN, so it should not have hit 192.168.2.1 regardless (if I understand it correctly).

@viragomann said in pfSense Web UI accessible even without rules:

With the policy routing rule, pfSense should direct the traffic to one of the gateways, but it seems that the gateways route the LAN IP back to pfSense for whatever reason.

Yeah, this is a plausible explanation. Though I'm still puzzled why packets for a completely different subnet are even accepted on WAN in this case.
I have adjusted rules for GUEST, but doesn't this mean my ISP can effectively access WebUI as well and I need to add explicit rules to drop it even though it should have been dropped by default (implicit deny all rule at the end according to documentation)?

viragomann

@nazar-pc said in pfSense Web UI accessible even without rules:

Though I'm still puzzled why packets for a completely different subnet are even accepted on WAN in this case.

pfSense listen to any of its IPs, no matter which interface the access is coming in.
This basically applies to any other operating system as well.

I have adjusted rules for GUEST, but doesn't this mean my ISP can effectively access WebUI as well and I need to add explicit rules to drop it even though it should have been dropped by default (implicit deny all rule at the end according to documentation)?

No, as long as there is no rule on the WAN allowing access to the WebUI, there is nothing passed on WAN.

When accessing from inside the guest subnet, the access is evaluated on the guest interface and since there is a rule allowing it, it is passed.

nazar-pc

@viragomann said in pfSense Web UI accessible even without rules:

When accessing from inside the guest subnet, the access is evaluated on the guest interface and since there is a rule allowing it, it is passed.

That was my point, there wasn't a rule that allowed it. There was only a rule that forwards everything to WAN interface.

I understand that server is listening on all IPs, but as far as I understood documentation, it is implicitly deny by default. So not having any rules on either WAN or GUEST networks, yet having GUEST's IP address opening Web UI is counter-intuitive to me. It is as if packets with private IP range re-routed by ISP back to WAN bypass the rules, but only for the pfSense itself.

I feel like something somewhere should have checked that packet for IP A arrived at WAN, but WAN has IP B and no forwarding rules for IP A or port 443, hence packet should be dropped right there. Yet the way I see it it arrived at pfSense's interface bypassing firewall simply because firewall happens to listen on A on another interface (or I guess listening on 0.0.0.0, so IP doesn't even matter).

nazar-pc

And similarly with WAN IP address. It doesn't open directly from the outside because there is no rule allowing it, yet it specifying gateway makes it work all of a sudden. I guess the fact that gateway is specified has some implicit behavior I do not recognize as well. My expectation was it'll forward packets through that gateway, but packets are handled by the interface associated with gateway for some reason.

viragomann

@nazar-pc said in pfSense Web UI accessible even without rules:

I feel like something somewhere should have checked that packet for IP A arrived at WAN, but WAN has IP B and no forwarding rules for IP A or port 443, hence packet should be dropped right there.

I presume, the rule does exactly what you told it to do.

Again, the rule is evaluated on the incoming interface. Since you allow access to any there, it means ANY. "Any" naturally includes also any IP of pfSense itself.
So what do you think is wrong with it??

If you allow access to any destination and direct the packets to your ISP gateway and this routed them back to pfSense, there is nothing else the firewall can do at all. That's not a fault of pfSense, rather one of the gateway. This is not a normal behavior.

There are other methods to block access to your local network or to the pfSense webGUI.
For passing out any access from a guest network, but not allowing access to any other local subnet, I add an alias to pfSense and add all RFC 1918 (private) networks to it.
Then I use this one in the pass rule as destination together with "invert match" checked. That means the rule passes any destination, but privat networks.

However, this rule still allows access to the WAN address if it's public.
To block it, I create a block rule for the destination "This firewall (self)". This is an implicitly created alias in pfSense, which includes any of its IPs. So with this any access to pfSense is blocked and you're save.

nazar-pc

@viragomann said in pfSense Web UI accessible even without rules:

I presume, the rule does exactly what you told it to do.
Again, the rule is evaluated on the incoming interface. Since you allow access to any there, it means ANY. "Any" naturally includes also any IP of pfSense itself.
So what do you think is wrong with it??

I admit it might be doing what it is supposed to, I just don't follow the logic behind it, so far it doesn't make sense to me. I think if packets arrive at WAN and there is no rule to let them through, they should not get through. If they do anyway, something somewhere not working the way it is documented or my understanding is wrong or both.

If you allow access to any destination and direct the packets to your ISP gateway and this routed them back to pfSense, there is nothing else the firewall can do at all. That's not a fault of pfSense, rather one of the gateway. This is not a normal behavior.

I disagree: packets arrive at WAN interface, it is absolutely within pfSense ability to block them at this. The fact that they are not blocked despite documentation is a problem.

There are other methods to block access to your local network or to the pfSense webGUI.
For passing out any access from a guest network, but not allowing access to any other local subnet, I add an alias to pfSense and add all RFC 1918 (private) networks to it.
Then I use this one in the pass rule as destination together with "invert match" checked. That means the rule passes any destination, but privat networks.
However, this rule still allows access to the WAN address if it's public.
To block it, I create a block rule for the destination "This firewall (self)". This is an implicitly created alias in pfSense, which includes any of its IPs. So with this any access to pfSense is blocked and you're save.

I essentially did the same except without an alias, but I do want to understand why things that are supposed to be blocked are not. Because unless I understand that, my config might be vulnerable in other ways due to misunderstanding of underlying logic.

viragomann

@nazar-pc said in pfSense Web UI accessible even without rules:

I think if packets arrive at WAN and there is no rule to let them through

In fact the initial packet arrives on your internal interface, where you have a rule allowing access to any destination. Hence the access is allowed.
If you're not happy with that change the rule as already suggested.

I essentially did the same except without an alias

With "any" as destination instead of the suggested alias? That's pretty a way different though in my understanding.

Best to start with "Firewalling Fundamentals" for better understanding of pfSense.

nazar-pc

@viragomann said in pfSense Web UI accessible even without rules:

In fact the initial packet arrives on your internal interface, where you have a rule allowing access to any destination. Hence the access is allowed.
If you're not happy with that change the rule as already suggested.

Hm... I guess the thing I missed here was that gateway was only applied in case IP address is from a different subnet.
That makes sense for GUEST network now, thanks!
Intuitively it'll work for WAN as well since this is just another interface on that machine and there is no need to route it anywhere.

Nice, thanks for helping to resolve this mystery for me!

viragomann

@nazar-pc said in pfSense Web UI accessible even without rules:

Hm... I guess the thing I missed here was that gateway was only applied in case IP address is from a different subnet.

No, with a gateway stated in the rule (policy routing), pfSense directs the matching traffic strictly to it.
But it's pretty odd that the packets are routed back to pfSense. That's not a normal behavior, as I mentioned already, and I'm not really sure if this happens indeed.

To get sure, you can run a packet capture on the WAN. When the packets are going out there, the source IP should be the WAN address due to outbound NAT.

If you don't see the packets on WAN, maybe there is another rule like a floating or an interface group rule passing the access to pfSense itself.

ptt

Perhaps: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#config-disablenegaterules

nazar-pc

@viragomann said in pfSense Web UI accessible even without rules:

No, with a gateway stated in the rule (policy routing), pfSense directs the matching traffic strictly to it.
But it's pretty odd that the packets are routed back to pfSense. That's not a normal behavior, as I mentioned already, and I'm not really sure if this happens indeed.

To get sure, you can run a packet capture on the WAN. When the packets are going out there, the source IP should be the WAN address due to outbound NAT.

If you don't see the packets on WAN, maybe there is another rule like a floating or an interface group rule passing the access to pfSense itself.

It does capture some packets for sure, lots of things are using port 443, not sure what to look for there. My wireshark skills are rudimentary.

Here is what my rules look like right now. There are no floating rules, WAN is disabled so I only have WAN2 to worry about, which only has a few port forwarding rules.

Rules screenshot

With these rules there is nothing that allows GUEST clients to reach to the pfSense itself, yet it does work just fine.

@ptt said in pfSense Web UI accessible even without rules:

Perhaps: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#config-disablenegaterules

Just tried that option, didn't seem to affect anything. Though apparently it is yet another invisible rule that should have been shown in UI.

viragomann

@nazar-pc
You can filter the IP (destination or source; as said, source should be the WAN IP) and the port.
But yeah, there might be a lot of noise with these if some devices connects to web servers in the internet.
Consider to change the web configurator port to something else in System > Advanced > Administration.

Your gateway in the rule called "MultiWAN" sound like a gateway group, is it?

Which IP are you able to access from the guest subnet, WAN or the guest IP?

nazar-pc

@viragomann said in pfSense Web UI accessible even without rules:

@nazar-pc
You can filter the IP (destination or source; as said, source should be the WAN IP) and the port.
But yeah, there might be a lot of noise with these if some devices connects to web servers in the internet.
Consider to change the web configurator port to something else in System > Advanced > Administration.

Hm, nothing was captured on WAN side at all.

Your gateway in the rule called "MultiWAN" sound like a gateway group, is it?

Yes, it is. Right now has just one WAN interface.

Which IP are you able to access from the guest subnet, WAN or the guest IP?

Guest IP: 192.168.2.1

viragomann

@nazar-pc said in pfSense Web UI accessible even without rules:

Your gateway in the rule called "MultiWAN" sound like a gateway group, is it?

Yes, it is. Right now has just one WAN interface.

I would try to state the gateway, which is in use, in the rule for test. But it should also work properly with a gateway group.

Which IP are you able to access from the guest subnet, WAN or the guest IP?

Guest IP: 192.168.2.1

Normally the gateway doesn't know this network, as long as there is no route added for it.
And as you see nothing on WAN, the packets a possibly not route out in fact.

For investigating I would change the web configurator port. Then try to access it from guest. Should still succeed.
Then go to Diagnostic > States and look for states with the used port. You can filter the state list for it.
The result should show all involved interfaces.

Also to get the rule, which is allowing the access I'd enable logging in each rules, as well in these ones on other interfaces. And then check out the firewall log for the responsible rule.

nazar-pc

@viragomann said in pfSense Web UI accessible even without rules:

I would try to state the gateway, which is in use, in the rule for test. But it should also work properly with a gateway group.

Gateway is probably unrelated, I removed it and behavior is still the same.

@viragomann said in pfSense Web UI accessible even without rules:

Normally the gateway doesn't know this network, as long as there is no route added for it.
And as you see nothing on WAN, the packets a possibly not route out in fact.
For investigating I would change the web configurator port. Then try to access it from guest. Should still succeed.
Then go to Diagnostic > States and look for states with the used port. You can filter the state list for it.
The result should show all involved interfaces.
Also to get the rule, which is allowing the access I'd enable logging in each rules, as well in these ones on other interfaces. And then check out the firewall log for the responsible rule.

I might have confused you. 192.168.2.1/24 is GUEST network, request comes in from 192.168.2.3, here is then state established for it:

GUEST tcp 192.168.2.3:45108 -> 192.168.2.1:12338 ESTABLISHED:ESTABLISHED 18 / 22 2 KiB / 18 KiB

nazar-pc

BTW, I'm on this version, maybe something regressed (potentially):

2.7.0-DEVELOPMENT (amd64)
built on Wed Jan 04 06:05:22 UTC 2023