Order of FW Rules...
-
It has always been my understanding that until you add firewall rules to an interface allowing a specified type of traffic, all traffic on that interface is blocked. So what is the purpose of a BLOCK rule?
When a device is on my IoT network, I don't want it to have access to anything on any of the other VLANs (or the default LAN).
Following is a screenshot of the rules I have defined on my IoT Firewall.
They allow access to the DNS on the firewall and to use the gateway for internet access (or at least that is what is supposed to happen). But when I'm connected to this VLAN, I'm still able to access devices in the default LAN: 10.1.1.1 (the pfSense Router), 10.1.1.2 (the ProxMox machine that hosts pfSense and Home Assistant) and 10.1.1.3 (my managed switch). Shouldn't the fact that I haven't created a rule to allow that activity be enough to prevent it? I previously tried making a rule that blocks any traffic destined for any network other than IoT. If I put that at the top of the list, I couldn't access ANYTHING while connected to IoT -- internet or otherwise. If I put that rule at the bottom of the list, there was no change -- I could access anything including the default LAN.
-
@doni49 Do you have any floating rules?
Your rule is any any, but your forcing out your wan gateway. If the gateway is down that rule could be created without the gateway setting depending on your setting.
Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated - but with that policy route - there are couple of settings that come to mind that could maybe cause what your seeing
Floating tab is evaluated first - so if you have stuff in there it could supersede what rules you have on the interface. Also states that have been created would still work until the state is gone, or killed, etc.
Also you have some sort of VM setup - that could be have something to do with it, maybe you don't have your networks actually isolated at layer 2?
But normally those rules would no allow this iot network to talk to your other networks because your shoving it out your wan gateway. But since it is an any rule, and if your wan gateway could get to your lan?
It is always best to be explicit in your rules and block what you don't want to allow.. before you allow what you want, if you want to have a locked down vlan/network that can not talk to your other networks, or pfsense gui, etc.. Here is an example of such a locked down network.
This "test" network of mine can ping pfsense test IP, can ask pfsense for dns, and ntp and can talk to my pihole on 192.168.3.10, but then it can not talk to any other firewall IP.. Nor can it get to any other rfc1918 network - my other networks.. But then it is allowed to talk to the internet.
-
@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
