There is a rule that only needs to be active every once in a while. If it is enabled and then disabled, usually the Rule description no longer makes sense when viewed from:
Firewall: Diagnostics: States
If "Reset state table" is performed, they go back to normal, but of course, that action resets all the clients.
I realize this is a "Stateful inspection firewall". I assume, unless reset, the states expire at some point and the description returns to normal.
Option 1:
Ignore incorrect "Rule description"? (that would be hard to do, personally)
Option 2:
Is there a second option to makes sure the descriptions are accurate after changes to rule(s)?
If you need to kill the state immediately, are you not able to still do that from the state table without having to reset the whole thing?
One thing you might try is specifying a lower timeout in the pf rule itself. You can enable the advanced view to see options for state tracking and there is one where you can override the default timeout for 'TCP established.' That's the worst case scenario: https://man.openbsd.org/i386/pf.conf#set~18
Don't set it too low or idle connections may drop prematurely while the rule is active. I read somewhere that SSH for example send a keep-alive packet every 5 min, so for that application you wouldn't want to set the pf timeout below 5 min.
Thanks for the ideas, however when I say the descriptions are inaccurate, it applies to over half of the states that were active at the time of the rule change or modification. So not just the specific rule.
I might try this: Firewall: Settings: Advanced: Firewall Optimization (try aggressive?)
Also looked through the built in cron jobs list.
There is an issue open in GitHub, but cannot find it. It mentioned the logic to have the description synced correctly was complicated because of some underlying table.
And I know the documentation does recommend a reset after making changes to the rules.
Just want to confirm I am not missing something obvious.
I didn't realize the scope of the problem w.r.t to all or most of the states. I'll stop here so as not to guess and spread misinformation, but I'll just say that if you try "aggressive" then you might want to test. It could have negative effects that aren't immediately apparent depending on the types of traffic you have.
Rather than enable/disable the rule, perhaps change its function? It sounds like a pass rule (or states would not be an issue), so change some matched element such that it can no longer be matched (e.g source address to 0/0). The method may not be practical - I haven't used it, so there may be side effects I haven't considered.
Quote from: pfry on Today at 05:30:53 PMchange its function
Excellent. I will try that. I actually thought of that, but then forgot. I can test changing it from pass to block, and vice-versa. Any existing states from that rule can just expire. Hopefully that does not change the dynamic table that keeps track of the rules.