Bug #4286


State killing on gateway change

Added by Jo S almost 7 years ago. Updated over 5 years ago.

Not a Bug
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:



I have a problem in a multi-wan configuration:

Link 1 (main) in tier1
Link 2 (backup) in tier2

The main link goes down, all connections are going to backup link, including VPN connections.
Then the main link goes up again, all traffic is going again to this one, but the VPN connections are still connected to the backup link, which is a wrong behavior (for me). When the main link is up, no traffic should pass to the backup link.

I unchecked the option "State Killing on Gateway Failure", as it says we have to uncheck it to enable the feature. But it does not seems to fix this.

Thank you

Actions #1

Updated by Phillip Davis almost 7 years ago

This seems more an OpenVPN failover issue. I just tested mine at home on 2.2-RELEASE - failed my main link, my OpenVPN client switched to the backup link. Put back the main link, my OpenVPN client switched to the main link (even though the backup link is still up). All good.
Look in /var/etc/openvpn/client1.conf (or client "n" .conf) as you fail the main link and bring it back. You should see a line like:
and the IP address there will switch to whatever WAN it is going out.

Actions #2

Updated by Jo S almost 7 years ago

Thank you for your answer, however I forgot to mention that I'm not using OpenVPN server on Pfsense, but on a remote dedicated server.
So the ESTABLISHED state seems to not be flushed on backup link when main link is back.

Actions #3

Updated by Phillip Davis almost 7 years ago

Ahh - well that is different to what I was thinking. Yes the failback of the OpenVPN traffic in that case will depend on the state that exists on the backup link being killed when the main link comes back up.
I have a feeling that "State Killing on Gateway Failure" only does something when a gateway goes down. In your failback case, it is a gateway up event for the main gateway. I will leave it for others to comment on that, and how your scenario could be made to work.

Actions #4

Updated by Marc 05 almost 7 years ago

Did you have this multiwan setup working previously with 2.1.5? Or has the issue existed since then?

Actions #5

Updated by Jo S almost 7 years ago

The problem was already here in the previous stable version.

Actions #6

Updated by Marc 05 almost 7 years ago

We're currently testing the same kind of set up with IPsec and it seems we have the same issue (on 2.1.4). This functionality seems pretty crucial to pfSense, so I doubt that it'd be bugged for so long. I think it's just something not configured correctly.

Actions #7

Updated by Marc 05 almost 7 years ago

The VPN on Site A has the "Stake killing on gateway change" feature enabled (box unchecked), and it did not restore our VPN service when falling back to WAN1. Resetting the firewall states on Site B (feature disabled; box checked) did seem to restore VPN functionality. So we'll have to try again when the feature is enabled on both ends of the VPN.

Sidenote: I don't see a post-edit feature on here.

Actions #8

Updated by Marc 05 almost 7 years ago

As I thought, it seems to be a miss-configuration on our part. However, further testing is necessary. Would you mind posting your firewall rules?

Actions #9

Updated by Jo S over 6 years ago

Here is a new test case in the latest 2.2.4 release:

- I start a "ping"
- Link ADSL is up, link 3G is up, both gateways in a "ADSL_3G" group with ADSL tier 1 and 3G tier 2.
- I go in Gateways, edit ADSL gateway, select "Mark Gateway as Down", and Apply.
- So now, all traffic should pass in the 3G link, since gateway ADSL is marked as down.
- the "ping" command started at the beginning is still showing that it goes to ADSL link (~30ms with ADSL, ~200ms with 3G)
- I stop the ping, relaunch it, still the same. A traceroute also shows it. ADSL is marked as down, but traffic still going to it for previous known states.
- now if I ping a "new" IP address, it goes through the 3G link.

It's not exactly the same test case of this open bug, but I suppose it's linked somehow.

Actions #10

Updated by Chris Buechler almost 6 years ago

  • Status changed from New to Not a Bug
  • Affected Version deleted (2.2)

it works as intended, it just doesn't wipe states after a gateway recovers as that's usually excessively disruptive.

Actions #11

Updated by Jo S almost 6 years ago

Ok then if it's not a bug, it's a feature request, "State killing on gateway recover".
Without this option, VPN connection state will never expire and will stay forever on the backup link...
Moreover backup link costs a lot more than main link when used and is generally slower than main link, so when the main link is back, the backup must not be used.

Actions #12

Updated by Jo S almost 6 years ago

I just saw you already opened this feature request 5 years ago
"the ability to optionally kill states to fail back once the original connection recovers"
it seems to be the option I (and others) need :)

Actions #13

Updated by James M over 5 years ago

I too need this feature and the platform is unuseable for reliable VoIP traffic with failover without it.
I have commented to the following pages to hopefully narrow down the issue.


Also available in: Atom PDF