New state killing mechanisms (#12092)

[jimp]

I just merged in changes for https://redmine.pfsense.org/issues/12092 which add some new manual and automated ways to selectively kill states.

Features

• Added action on firewall rule list to kill states on an interface created by a specific rule (from firewall rule list)
• Added action on gateway status page to kill states created by policy routing rules using a specific gateway name (from gateway status page)
• Added action on gateway status page to kill states using the default gateway (0.0.0.0 or ::) -- these options match states from rules that DO NOT use policy routing or reply-to.
• Added action on gateway status and gateway group page to kill states by gateway IP address (catches route-to/policy routing and reply-to, both inbound and outbound)
• Added action on gateway group status page to kill states created by policy routing rules using a specific gateway group name (catching anything that hits rules without route-to)
• Change global state killing option on System > Advanced, Misc tab to be granular (none, all down, flush all)
• Add per-gateway option to override global behavior (use default, do not kill, kill when down)
• Improve logic when determining which gateways are considered in state killing behavior.
• Log action when killing states
• Upgrade code to convert old setting to new format

The automatic parts are off by default, but can be enabled globally or selectively on individual gateways.

Caveats

There are a few caveats with these features, including:

• Killing states for specific down gateways only affects states created by policy routing rules and reply-to. (read: Won't help on connections relying on switching the default gateway rather than using policy routing rules)
• The ability to kill states for down gateways ignores gateways with monitoring disabled, monitoring action disabled, and gateways which have been forced down manually. This is done to respect the user's preference in behavior and not be overly disruptive.
• May not have any effect on dynamic gateways during a link loss event, as when the link is lost there is currently no way to determine what the previous dynamic gateway IP address was (#12931)
• Manually killing states for a specific gateway by name or gateway group will only kill states created by rules specifically using that group or that gateway. This means that it will only catch states on the way inbound (not outbound) unless there is also a floating rule outbound using that same gateway name or group.
• Similarly, killing states created by a specific rule only kills states created by that one rule on the way inbound, not outbound, since outbound would be a different rule ID.
• You can only kill rules created by a state, not states which would match a rule, so this does not help with things like killing states that match newly added block/reject rules.
• This does not include killing states when a gateway recovers (e.g. when WAN1 recovers, kill states on WAN2) though the underlying changes in pf bring that closer to reality (#855)

Notes

Among other things, this brings back the old "kill states for down gateways" behavior we had many years ago, and can now have again thanks to pf recently natively getting the ability to kill states by gateway. Be sure to read the caveats above and in the GUI to understand the limitations of this behavior.

Should you choose to try this by applying the commit ID to a running system, reboot after. Or at least force a filter reload after and then flush the entire state table.

Note that while we have tested this internally, there could still be some rough edges, so use with caution.

Also note that the option to manually kill states from gateways and groups by name may still be removed as I'm not certain it's useful compared to the other available options given its limitations, and having too many options can be confusing.

[JonathanLee]

@jimp are updates paused for development mode? I have not received a upgrade from 22 of March until today. prior in had a upgrade every day for the experimental updates.

[JonathanLee]

@jonathanlee

I spoke to soon,

Here we go experimental mode,

Thanks Jimp for all you do

[luckman212]

@jimp I haven't looked at the code yet, but are there callable functions in one of the includes to trigger these granular state-killing methods? I have some shell scripts to do fancy state killing (mostly for VOIP issues on multiwan) that would benefit greatly from being able to kill states on a specific gateway / firewall rule combo for example.

[jimp]

@luckman212 said in New state killing mechanisms (#12092):

@jimp I haven't looked at the code yet, but are there callable functions in one of the includes to trigger these granular state-killing methods? I have some shell scripts to do fancy state killing (mostly for VOIP issues on multiwan) that would benefit greatly from being able to kill states on a specific gateway / firewall rule combo for example.

No functions but it's just a matter of passing the right parameters to pfctl -k. You can see examples of most of the types here:

https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/status_gateways.php#L34

[luckman212]

@jimp Thanks I'll have a look.