Have 2 Wireguard clients on Tunnel 1 in vpn dashboard, arranged as per priority. When client 1 fails its goes to client 2. Works fine. But even when client 1 server is up, it still sticks to client 2. Not going back to priority client 1.
Hi
Do you mean the switching logic between VPN profiles within a Tunnel?
If so, then this is the expected behavior. The current failover logic within a Tunnel works as follows:
-
When the currently active profile fails, the router switches to the next profile in the list, wrapping back to the first profile after the last one.
-
The router will try each profile at most once during a failover cycle. If none of the profiles can be connected successfully, it will then decide whether to fall back to the local WAN connection based on the Tunnel Kill Switch and All Other Traffic policy settings.
-
The router only monitors the status of the currently active profile. It does not periodically check whether previously failed profiles have become available again and try to come back.
So, for example, if a Tunnel contains three profiles:
-
When the router detects that the currently active Profile 1 has failed, it will attempt to switch to Profile 2.
-
If Profile 2 connects successfully, it will remain on Profile 2.
- If Profile 2 later fails, it will then attempt to switch to Profile 3.
-
If Profile 2 fails to connect, it will then try Profile 3.
-
If Profile 3 fails to connect, it will then decide whether to fall back to the local WAN connection based on the Tunnel Kill Switch and All Other Traffic policy settings.
-
Likewise, if the currently active profile is Profile 2, the failover sequence will be:
Profile 2 → Profile 3 → Profile 1 → WAN (or block all traffic)
Thanks for the reply, it will be great if we have the facility to revert to priority 1 profile ASAP. In my case profile 1 has higher speeds than the other.
Is there any way to get profile 1 connected automatically when it’s up? rather sticking with much lesser speed priority profile 2 ?
As a standard user, would like to have that option in stable gl-inet firmware.
At the moment, there is unfortunately no solution other than manually restarting the tunnel.
We will discuss with the product manager whether this functionality can be added in a future release.
That said, the likelihood may not be very high. Properly checking the availability of each VPN profile would require creating a corresponding interface for every profile, performing periodic connectivity tests, and then tearing those interfaces down again. This could consume a significant amount of system resources, especially when there are multiple profiles configured.