Flint 4 4.11 beta 3 VPN failover prevents switching configs

Router
1

Observed wierd behaviour/bug, diagnosed with the help of Claude. Could not get second VPN profile working on primary tunnel, it kept disconnecting straight away and reverting back to the other config. However once I disabled the other config and removed it from the primary tunnel in the dashboard, the troublesome config connected fine and maintains the connection. After using wgshow and logread in ssh terminals and some analysis from claude it identified that failover is for some reason kicking in. Claude’s rationale below…

This log answers it. WireGuard isn't failing. The router's own VPN failover script is switching you back, and it's reacting to the interface bounce caused by your switch.

These are the lines that matter, in order:

12:52:12  firewall: Reloading firewall due to ifdown of wgclient1
12:52:14  vpn-failover-trigger: action=schedule iface=wgclient1 reason=ifdown tunnel_id=4811 delay=0s
12:52:14  tunnel-switch.sh started ... acquired lock tunnel_id=4811
12:52:17  netifd: Interface 'wgclient1' is now up
12:52:17  firewall: Reloading firewall due to ifdown of wgclient1     <- bounced again
12:52:22  tunnel-switch.sh: interface wgclient1 still down after 8s, proceeding with failover
12:52:22  profiles_path=/etc/vpn_profiles.d/profile4811, total_profiles=2
12:52:22  Switching to client 2001 (index 2/2) on wgclient1
12:52:37  Tunnel switched successfully to 2001

  1. When you selected the new profile, the firmware took wgclient1 down to reconfigure it. That's normal.

  2. The GL.iNet failover hook (vpn-failover-trigger) treats any ifdown on that tunnel as a failure and starts tunnel-switch.sh immediately (delay=0s).

  3. The script waits 8 seconds and checks the interface. During that window wgclient1 came up at 12:52:17 but went down again almost immediately. Every network event on this firmware also triggers a full Wi-Fi reload (the reload_legacy / mtwifi_reload blocks every ~5 s) and a firewall reload, which keeps knocking the interface around. So at the 8-second check it saw "down".

  4. It then failed over to the next profile in the group. There are two profiles (total_profiles=2), and it picked client 2001, presumably your working config. That's the "revert".

4

Hi,

Thank you for reporting this issue and for providing the detailed analysis.

We have reproduced the issue internally and have forwarded it to our R&D team for further investigation and a fix.