pfSense Web UI accessible even without rules
-
@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.
-
@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.
-
@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!
-
@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.
-
Perhaps: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#config-disablenegaterules
-
@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.
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.
-
@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?
-
@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
-
@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.
-
@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/24is GUEST network, request comes in from192.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 -
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
