pfSense Web UI accessible even without rules
-
@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
