Project

General

Profile

Actions

Feature #12092

open

Utilize new ``pfctl`` ability to kill states by label

Added by Jim Pingle 3 months ago. Updated about 1 month ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
Rules / NAT
Target version:
Start date:
06/29/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
22.01
Release Notes:
Default

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.

Actions #1

Updated by Jim Pingle 3 months ago

  • Target version set to 2.6.0
  • Plus Target Version set to 21.09
Actions #2

Updated by Jim Pingle 3 months ago

Another random thought, it might be possible to leverage this to help with multi-wan (like #8555) since we could kill states for rule(s) using a gateway or group including a down gateway along with the ID of outbound rule(s) on the failed WAN (automatic and also floating rules). Worth investigating, but may not pan out.

Actions #3

Updated by → luckman212 3 months ago

@Jim yes that would be a godsend for multiwan if it works out. I always dreamed of being able to kill specific states that were tagged with a certain label (e.g. SIP connections) during failback events, but the best I was able to do was cobble together hacky shell scripts involving cron, pfctl, grep & awk... this would be so much nicer. I hope it's in the cards.

Actions #4

Updated by Jim Pingle 3 months ago

→ luckman212 wrote:

@Jim yes that would be a godsend for multiwan if it works out. I always dreamed of being able to kill specific states that were tagged with a certain label (e.g. SIP connections) during failback events, but the best I was able to do was cobble together hacky shell scripts involving cron, pfctl, grep & awk... this would be so much nicer. I hope it's in the cards.

Even if this doesn't work out like I'm hoping you could script it easier with a rule label like "SIP connections" to match what you want and then pfctl -k label -k "USER_RULE: SIP connections" to kill the connections matching that rule. Make sure to match in and out using the same label and it should catch them all.

Actions #5

Updated by Marcos Mendoza 3 months ago

Note on "That also assumes the rule has an ID in its configuration, which we may need to check is always true."

This indeed should be taken into account. I've come across more than a handful of configurations were there existed rules without an ID, likely because the upgrade path for that was never hit.

Actions #6

Updated by Jim Pingle about 1 month ago

  • Plus Target Version changed from 21.09 to 22.01

Moving ahead, still needs more thought/planning about how best to approach this

Actions

Also available in: Atom PDF