SOLVED! on my test rig I tried a state-killing option that had NOT solved the problem on my live box, but on the test rig it worked. The setting is in System/Routing/Gateways, "State Killing on Gateway Failure". After changing that from the default to "Kill states using this gateway when it is down", subsequent failover events created a few arpresolve errors in the log, but within 1 second they stopped, after an entry in the log showing a state killing action:

/rc.filter_configure_sync: GW States: Killing states for dynamic down gateway: WAN_DHCP, XX.XX.XX.1

After that worked, I had to figure out why this solved the problem with my test rig but not my live box. Eventually I traced it to a setting in System/Advanced/Miscellaneous in the Gateway Monitoring Section, "Skip rules when gateway is down". In my live box, which has some traffic that needs to be routed only through a VPN, I had enabled the setting "Do not create rules when gateway is down" years ago to make sure, if the VPN was down, that pfSense wouldn't route the traffic through the non-VPN WAN. But as soon as I cleared that check box, my failover arpresolve problem went away. So apparently that setting interacts with the failover in a way that prevents the state-killing action from working properly.

Next job is to figure out a different way to kill VPN-bound traffic if the VPN is down... Googling that now.

Note: simply changing the terminal settings to send ^H instead of BKSP is not a universal fix.

For example, when I did this (iTerm2) I noticed that when ssh'ing to a new host and getting the prompt to accept/reject host keys, I can no longer backspace properly. Instead of deleting, it prints the literal ^H

32683b3b-8f19-4633-a540-f7628ecb76f9-image.png

@cool_corona said in killing existing (specific) fw states when rule change from disabled to enable:

d the dropdown in "schedule" is empty (always none).

So, what I'm looking for is that exactly not what I'm looking for :)

As mentioned, what I'm looking for is the ability to run a specific task when a rule is enabled or disabled. Not a schedule !

I you want a schedule, go under firewall-> schedule, create your schedule and then go back where you took your screenshot from and assign that schedule :)

That's part of the nature of conservative mode -- states will pile up more. If some client behavior changes and makes the clients open more states, then they'll hang out longer.

What you could do is keep the router itself on normal mode and setup custom state timeout rules to match the VoIP traffic which sets different state timeouts just for them, and perhaps only for VoIP/RTP traffic for example. Narrow down the longer state lifetimes as much as possible.

(bump) Someone?