Feature #12092
closed
Utilize new ``pfctl`` abilities to kill states
100%
Description
In the latest pf changes present on 2.6.0, pfctl now supports killing states by label. We are using this to kill schedule states, but we could also use it to kill states for specific rules. Caveat being the rules must have a unique label.
: pfctl -vvsr | grep -A2 Test123 @115(1624974401) pass in quick on vmx0 reply-to (vmx0 198.51.100.1) inet proto tcp from any to 198.51.100.6 port = http flags S/SA keep state label "USER_RULE: Test123" [ Evaluations: 73 Packets: 6 Bytes: 344 States: 1 ] [ Inserted: pid 64790 State Creations: 2 ] : pfctl -vvss | grep -A4 198.51.100.6:80 all tcp 198.51.100.6:80 <- 198.51.100.142:53432 ESTABLISHED:ESTABLISHED [2154389371 + 64256] wscale 9 [3322164514 + 65537] wscale 7 age 00:18:39, expires in 23:59:31, 2:1 pkts, 112:60 bytes, rule 115 id: 0b24db6000000001 creatorid: 69dbf34f gateway: 198.51.100.1 origif: vmx0 : pfctl -k label -k 'USER_RULE: Test123' killed 1 states : pfctl -vvss | grep -A4 198.51.100.6:80 :
The rule label must match exactly, it does not support partial, wildcard, or regex matching.
It may or may not be viable to have an icon on each rule row to do this since users may not realize that if they have a generic (or no) rule description that it will kill states for anything else with that same label. Such an icon could at least be hidden for rules with an empty label, but that may or may not be sufficient.
As an alternative tactic, pf now also supports multiple labels per rule, and we could add the rule ID as another label (e.g. label ruleid:<num>), which would be more accurate than relying on the user-entered description. That also assumes the rule has an ID in its configuration, which we may need to check is always true.
The states display could have an input/button, perhaps in a collapsed advanced panel, to pick a label to kill from a drop-down list of all unique rule labels to avoid potential user input errors. That may not be viable since it wouldn't scale well, though. Systems with many rules may have problems rendering the box or finding/picking rules from the list.
Note that this does not solve problems like #1947 since this only affects states created by the rule matching the label, not traffic which would match the rule.
If it's not viable to add in the GUI then we should at least note it somewhere in the docs.
Related issues
Updated by 
Updated by 
Updated by