Order of FW Rules...
-
@johnpoz
Thanks for the reply. I'll respond to a couple of things you noted and take a closer look at the rest of your reply -- probably in the morning.I have no floating rules. I've read that they can be more of a security risk than anything so I've avoided them.
I have Proxmox installed with two VMs installed: Home Assistant (configured in proxmox to use VLAN 200 -- I'm guessing that's what you were asking about on segregating the VMs) and pfSense. That is not assigned a VLAN tag it is my understanding that leaving it without a VLAN tag automatically puts it in the default LAN and that's where it want it to live.
-
@johnpoz
I decided to just look at it tonight.I'm confident the gateway wasn't down when this was happening -- I was streaming youtube on my Roku at the time of testing this and it uses the same gateway.
But I changed up the rules to see if I could improve things. With this set of rules, my phone when connected to IoT, is able to access both the internet and home assistant (10.20.0.2). But I was still able to access pfSense's admin pages which would be 10.1.1.1 and should be covered by the RFC1918 blocking rule.
I liked the idea of including a rule to allow NTP access so I added that.
Edit: I noticed that the Alias says 10.0.0.0/32. I changed that to 10.0.0.0/8, saved it and then was still able to access 10.1.1.1 from my phone that is connected to IoT.This is from the configuration page for the IoT Interface.
I started accumulating smart devices in the last 9 months or so and I'm already up to 90. So I wanted to build in room for growth -- yes, I know /22 will allow for alot of devices.
-
I now suspect that maybe I was testing it too soon after updating the rules. I just tried it again and was unable to access 10.1.1.1.
Thanks!
-
@doni49 As I mentioned states would allow traffic.. States are evaluated before rules. If there is a state that allows the traffic, it would be used before any rule that would prevent the creation of the state in the first place.
-
One thing I like to do:
Diagnostics, Command Prompt and enter:
pfctl -srThat will give you all the rules in the order and expanded. It helps me when I can't remember "which is applied first, floating interface or something else".
As for a block rule, if it's near/at the top of the list then yes it would be evaluated first, evaluation doesn't always mean applied. As @johnpoz says state would override application.
-
@johnpoz said in Order of FW Rules...:
@doni49 States are evaluated before rules.
I guess that's where my confusion lies. I'll have to read up on "states".
-
BTW... I suspect that I wasn't waiting long enough after saving my rules edits before testing for access. Because even though I was still able to access 10.1.1.1 from an IoT device before I went to bed, that is no longer the case.
It all seems to be working as desired this morning.
-
@doni49 said in Order of FW Rules...:
BTW... I suspect that I wasn't waiting long enough after saving my rules edits before testing for access. Because even though I was still able to access 10.1.1.1 from an IoT device before I went to bed, that is no longer the case.
It all seems to be working as desired this morning.
That's exactly what John said. If there's an existing state, traffic will pass.
If you are constantly pinging a device, and then add a rule to block ping, it'll still constantly ping until you stop pinging, and then the existing state times out.
So if you create a new new, it may help to kill all states on that interface if you don't want to wait for the timeout. -
@doni49 said in Order of FW Rules...:
I'll have to read up on "states".
Yeah I would recommend that, since pfsense is a stateful firewall.. Pretty handy to understand what a state is ;)
-
@doni49 said in Order of FW Rules...:
@johnpoz said in Order of FW Rules...:
@doni49 States are evaluated before rules.
I guess that's where my confusion lies. I'll have to read up on "states".
See https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#new-rules-are-not-applied
