pfSense

Hello Steven,

Do you have state killing on lower priority gateways selected under System --> Advanced --> Misc?

Hi Kris - Yes that setting is set as you asked. The Wireguard tunnel stays firmly gripped on the lower tier gateway when the higher priority tier restores, while other traffic correctly migrates.

I also see this behavior at my location here.

I can add linbks to other reports from reddit etc... I believe this really happens. Big problem when your backup WAN is on a metered link...

Tested on 25.11.1-RELEASE

I was able to reproduce this issue and as a workaround I added Floating Firewall rule:

Interfaces: Any
Direction: Out
Protocol: UDP
Destination: <WireGuard Server IP>
Destination Port: <WireGuard Port> (for example, 51820)
Gateway: <Failover Gateway group>

and in System->Advanced-> Miscellaneous I chose 'State Killing on Gateway Recovery: Kill all states for lower-priority gateways'.

After I added these settings, whenever WAN1 went down, WireGuard started using WAN2. When WAN1 came back up, WireGuard successfully switched back to WAN1.

As I understand it WireGuard sticks to the old address even after a more preferred route is available. To address this we could simply restart the service; doing so would affect all tunnels but perhaps that's better than sticking to the old address. As a test the following patch will restart the service after gateway recovery: ShowHide

diff --git a/src/usr/local/pkg/wireguard.xml b/src/usr/local/pkg/wireguard.xml
index ff2c1c0f5333e..ef01dfa0a8d3c 100644
--- a/src/usr/local/pkg/wireguard.xml
+++ b/src/usr/local/pkg/wireguard.xml
@@ -60,7 +60,7 @@
     </custom_php_pre_deinstall_command>
     <custom_php_resync_config_command>
         <![CDATA[
-        wg_resync();
+        wg_service_fpm_restart();
         ]]>
     </custom_php_resync_config_command>
 </packagegui>

Marcos M wrote in #note-8:

As I understand it WireGuard sticks to the old address even after a more preferred route is available. To address this we could simply restart the service; doing so would affect all tunnels but perhaps that's better than sticking to the old address. As a test the following patch will restart the service after gateway recovery: {{collapse
[...]
}}

For me this would minimally be acceptable. Obviously seamless gateway transition would be preferred.
I'll test this patch - that you.

I get this error:

PHP ERROR: Type: 1, File: /usr/local/pkg/wireguard/includes/wg_service.inc, Line: 194, Message: Uncaught Error: Call to undefined function cli_set_process_title() in /usr/local/pkg/wireguard/includes/wg_service.inc:194
Stack trace:
#0 /usr/local/pkg/wireguard/includes/wg_service.inc(113): wg_service_cli_start()
#1 /etc/inc/pkg-utils.inc(734) : eval()'d code(1): wg_service_cli_restart()
#2 /etc/inc/pkg-utils.inc(734): eval()
#3 /etc/rc.start_packages(66): sync_package()
#4 {main}
thrown @ 2026-05-06 13:56:14

Did I do it right?

There was an error with the old patch, I updated my previous post with a new version.

Marcos M wrote in #note-11:

New patch "works". I.e. it does kick WG off the backup interface - but there seems to be a lot of resets occurring, the disruption is worse than I expected.

A better solution would have WG transition seamlessly between interfaces. Obviously.

Will continue testing to see if I can locate the source of the unexpected disruptions. But THANK YOU for making this patch. I have already invested a lot of time in trying to fix this issue and none of the workarounds have been 100%.