WireGuard client - restore WAN connectivity in failure case

Network > your interface WIREGUARD CONFIG > peers > edit (peers) > Route Allowed IPs (check option) and SAVE

WireGuard will route all traffic to it

I know this already.
But this is not the topic of this discussion.

In my opinion there's an issue with function restart interface.
In case the DNS servers offered by VPN provider, that are only reachable via VPN tunnel, are not reachable, it would not help to restart the interface because there's potentially a root cause on VPN provider side for this issue.
In exactly this scenario I need to ensure that any internet connection uses WAN, means I need to take WireGuard interface down.

tried this on your firewall, put the wan interface on all the others you always want the internet to work

  • prontonvpn (my wireguard)
  • vpn (my interface default vpn)

Firewall > YOUR WIREGUARD INTERFACE > edit > Allow forward from (add the interface and you want to always have the wan interface)

see

don't forget to check your wireguard interface (MASQUERADE and MSS clamping)

I don't understand this setup.
Why do you configure a vpn interface with forward from wan and protonvpn?
What is the use-case for this?

I don't route all my traffic to WireGuard, I just route one interface, called "vpn"

In this interface that you see, it uses WIreGuard by default on the connection, but if the connection drops it will use WAN by default

Also, this configuration is used to use the package (vpn-policy-routing) to route a device through wg0 or wan

I understood that interface vpn is like a "consolidation interface" for any outbound traffic.
This means there could be multiple WireGuard, OpenVPN, etc. interfaces.

However I don't understand how this works if WireGuard connection drops that WAN will take over?
Could you please share the relevant network configuration?

You seem to have correctly latched onto the concern I had, namely that just because traffic is redirected when interface goes down, this doesn't necessarily mean connectivity is restored if a peer stops responding.

The netifd solution indeed seems appropriate for setting up VPN as default with 'wan' as a failover, but I'm just not sure what happens when a peer stops responding.

If WireGuard peer stops responding won't the interface go down automatically anyway?

Else the title in:

is rather misleading, right?

I guess this could be the solution I'm looking for.

However, the "big" unknown is:
How does it recognize that VPN is down or not working?

I'm not sure if WireGuard interface goes down if peer stops responding.
But I can verify this because my VPN account validity ends on Saturday. After this date I cannot connect to VPN endpoint anymore.

whats VPN provider?

So "Route LAN to VPN with failover to WAN" is the next test.
If you want to test this implementation prior to the end of your account validity anniversary; you could force the issue by changing your account credentials from/on a mobile device, thus making the routers credentials obsolete. This would kill the peer, and the next logic would be the failover to WAN.

That's a hard turn to test but an idea non-the-less.

1 Like

Is my understanding correct that these settings (with route and rule) are not required?

Correct not required.

Details for my use case off topic

In the case of it being needed, as in my case for a VOIP device, I needed the setup for one IP on my subnet to use the IP/Table lookup and metric.

My router is always VPN via Wireguard, the VOIP device can not be encapsulated/tunneled.
This setup was recommended by @pavelgl and allowed me to move off the usage of VPN Policy-Based Routing + Web UI -- Discussion

1 Like

Although it's off topic, it's an interesting discussion.
Does this mean you have configured a route for a single IP to use WAN only, comparable to this example "Route DMZ to VPN and LAN to WAN"?

How did you implement this?
Did you define a subnet for VOIP device(s) with a dedicated interface, firewall config, etc.?

I've verified a setup with 2 subnets, DMZ and Guest, with the following rules:

  • Route DMZ to VPN with failover to WAN
  • Route Guest to WAN
uci set network.guest.ip4table="4"
uci set network.guest.ip6table="4"
uci set network.dmz.ip4table="3"
uci set network.dmz.ip6table="3"
uci set network.wan.ip4table="1"
uci set network.wan6.ip6table="1"
uci set network.wg0.ip4table="2"
uci set network.wg0.ip6table="2"
uci -q delete network.dmz_wan
uci set network.dmz_wan="rule"
uci set network.dmz_wan.in="dmz"
uci set network.dmz_wan.lookup="2"
uci set network.dmz_wan.priority="40000"
uci -q delete network.dmz_wan6
uci set network.dmz_wan6="rule6"
uci set network.dmz_wan6.in="dmz"
uci set network.dmz_wan6.lookup="2"
uci set network.dmz_wan6.priority="40000"
uci -q delete network.dmz_wg0
uci commit network
/etc/init.d/network restart

This results in following routing table:

root@eddie:~# ip route show table main
185.102.219.26 via 192.168.1.1 dev wan proto static 
192.168.9.0/29 dev lan5 proto kernel scope link src 192.168.9.1 
192.168.10.0/24 dev lan2 proto kernel scope link src 192.168.10.2 
192.168.96.0/19 via 192.168.9.1 dev lan5 proto static 
192.168.128.0/17 via 192.168.9.1 dev lan5 proto static 

And when I try to ping DNS only available via VPN tunnel directly from router, I have package loss:

root@eddie:~# ping -c 3 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=2 ttl=64 time=12.960 ms

--- 172.16.0.1 ping statistics ---
3 packets transmitted, 1 packets received, 66% packet loss
round-trip min/avg/max = 12.960/12.960/12.960 ms
root@eddie:~# ping -c 3 10.0.254.2
PING 10.0.254.2 (10.0.254.2): 56 data bytes
64 bytes from 10.0.254.2: seq=1 ttl=64 time=19.919 ms

--- 10.0.254.2 ping statistics ---
3 packets transmitted, 1 packets received, 66% packet loss
round-trip min/avg/max = 19.919/19.919/19.919 ms

This indicates to me that this setup is not working correctly.

Yes I did exactly the same for my televisions so that Netflix and Prime still work. @cmonty14 you can just add appropriate rules in LuCi for the source IPs to specify they are to go over 'wan'.

Those just need higher priority than the default to VPN. And underneath the default to VPN with lower priority you specify route to 'wan'. Well I think the netifd stuff sets that up already actually.

I didn't use the DMZ stuff - just the VPN with wan failover. And actually these days I think I just set it manually. Set up routing table for each interface and then rules to specify where everything goes.

BTW if you want to use CAKE in this context my script may be of interest:

This sets up single interface that combines flows in context of VPN pbr.

Let me summarize my findings based on default route VPN.

  1. If you want to use WAN in case of failure with VPN, you need to configure Dynamic connection and in addition you need to stop WireGuard interface ifdown wg0
  2. If you want to bypass VPN for a specific subnet (e.g. DMZ, Guest) you need to configure VPN Policy-Based Routing
  3. Using watchcat and restarting WireGuard interface or router could overcome a connection issue with VPN but only if the root cause is not with the VPN provider (endpoint).

What is this about?
Could you please share some more info?

I think there are multiple ways to set up a VPN with 'wan' failover, but I think the most elegant is the netifd approach linked above and/or manually setting up the appropriate rules in LuCi for your specific use case. That is, I favour the first option described here:

It's much lighter than the second.

What I meant about CAKE is in the context of sqm. If you want to apply sqm using CAKE in the context of VPN pbr there is a problem because you have a mixture of encrypted and unencrypted flows on 'wan'. There are unencrypted VPN flows on the VPN interface. And with CAKE you normally set it up on a single interface.

My solution creates an appropriate ifb interface with mixture of flows for download and relies on a special compatibility between CAKE and WireGuard for upload. In short it allows CAKE-based sqm to work on mixture of all encrypted and unencrypted flows to resolve bufferbloat issues on single internet connection carrying the mixture.

BTW the second pbr approach linked above doesn't support sqm. That's one reason I ditched it and went for the netifd approach and came up with my own sqm script to deal with this situation.