pfSense

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:
local 1.2.3.4
and the IP address there will switch to whatever WAN it is going out.

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.

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.

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

The problem was already here in the previous stable version.

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.

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.

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?

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

- I start a "ping 8.8.8.8"
- 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.

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.

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

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.
https://redmine.pfsense.org/issues/5090
https://redmine.pfsense.org/issues/855