Firewall rules get scrambled
-
In a nutshell, can someone explain what rule changes do and do not require a state reset. (version 2.1.5R)
-
Does disabling/enabling rule logging require a reset?
-
Does disabling/enabling a rule require a reset?
-
Does adding or removing one rule require a reset?
-
Without a state reset will traffic eventually begin hitting the correct rules after they disconnect and are in a CLOSED state for 30 minutes or more?
State resets are very disruptive with a couple hundred users of a PfSense router in production mode. It seems that after a rule is added it shifts the rules in such a way that traffic that shouldn't hit certain rules does. It's like scrambled eggs where a rule, with logging, that only hits with a destination port of say 1194 is now triggered by traffic that doesn't have that destination port. Many rules begin behaving this way.
I tried just clearing states on one adapter. If I clear the Wan adapter it goes well but not sure if really effective at resetting all the rules correctly. If I clear the Lan adapter states I loose the modem unless I disable and re-enable the PfSense Wan adapter. Currently I'm having to do my rule changes on sleepless nights. I don't dare touch rules during peak demand.
Thanks for your help…
-
-
From what I understand…
Does disabling/enabling rule logging require a reset? No
Does disabling/enabling a rule require a reset? Perhaps
Does adding or removing one rule require a reset? Perhaps
Without a state reset will traffic eventually begin hitting the correct rules after they disconnect and are in a CLOSED state for 30 minutes or more? Yes, but much shorter timeframe. If they close a connection then any new similar connection will hit the new rule and be handled accordingly.pf is a stateful firewall, which means that any traffic that you initiate which is allowed out will automatically have the return traffic allowed back in, even if there isn't a specific rule that allows it. What this means is that firewall rules that change existing access will not have the rule respected by an existing state until that state is closed. This can potentially be a major security risk if you're trying to close off something that's open. You have to weigh the potential disruption against the potential risk factor. The default timeout for an open state is 24 hours (86400s).
-
I've never seen that behavior, so I'm not sure what you're doing exactly. Changing the rules will reload the ruleset in pf. pf is very logical, the scrambling must be due to the way you have the ruleset configured. You can go through /tmp/rules.debug yourself, or get reams of info from various options on the status or diag menus.
If there is an established state, it will continue until it expires, or you reset the state. If someone has a persistent connection, it could continue indefinitely, but once the connection is closed it should expire shortly and new connections would obey the new ruleset.
I generally don't reset states when changing rules. If there is something like an infected host, I will clear states selectively.
What do you mean by clearing states on LAN or WAN? It doesn't work like that…
In short, you don't need to clear states for most rule changes. If someone is doing something you don't like, only clear their states.
Also, scrambled eggs are tasty. Especially with bacon. -
Hi .-,
I tried your suggested /tmp/rules.debug and get an access denied msg. I have sudo pkg installed on PfSense 2.1.5-R(x64). What you describe is how I would expect pf to behave. I can do most without incident, enable/disable logging, enable/disable rule. But if I remove or add a rule this will cause issues on the order of 50% of the time. Example; I have a rule, call it #100, with logging enabled and all works fine after reboot. Rule #100 shows recent hits in the system log/firewall tab having 204.1.1.1 as a destination IP just as the rule is entered. I then add or remove a floating rule, and apply, which resyncs pf. From this point forward I begin to see log entries with 204.1.1.1 as a destination IP which should be labeled as rule #100 but instead it shows as rule #99 with rule #99's description. And rule 99 has nothing related to an IP of 204.1.1.1. I don't know what else to call this but scrambled eggs tasty or not. ;) Reset states or reboot and all is normal again.By clearing Lan / Wan states I mean the same as you clearing states selectively, such as when one LAN IP isn't hitting the correct rule I would issue a /sbin/pfctl -k 192.168.x.x or to clear all Lan states, /sbin/pfctl -i igb2 -F all. I'm sure you're familiar.
-
Not sure about the access denied message, I usually operate from the shell when digging through the rules- tail grep more, etc.
If you add or remove a rule, the established states will still be referencing the old rule number, so will now be inconsistent with the new rule numbers.
I would recommend clearing states from the GUI. Doing a -F all from the command line will blow away everything. -
I later figured out your suggested /tmp/rules.debug was really meant to be pfctl -f ./tmp/rules.debug which is why I received the "access denied" message. Works fine with complete syntax. Not sure specifically what you were suggesting I look for.
I most often do clear states via the GUI. I could also use 'pfctl -F states', rather than '…all', which does the same thing as the GUI.
Just this morning I saw the same issue happen again. I added a rule and found another rule state still intact and passing data but was no longer hitting the assigned queue per the GUI pftop-labels list. I killed the two states and the IPsec client auto-connected to the same rule but now had data hitting the queue. So it's not that the connection state is being broken, just the match queue associated with the connection state. So every time I add a rule I risk sending Wan out queue rules to default creating customer complaints, especially VoIP users.
