WireGuard client - restore WAN connectivity in failure case

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 via dev wan proto static dev lan5 proto kernel scope link src dev lan2 proto kernel scope link src via dev lan5 proto static via 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
PING ( 56 data bytes
64 bytes from seq=2 ttl=64 time=12.960 ms

--- 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
PING ( 56 data bytes
64 bytes from seq=1 ttl=64 time=19.919 ms

--- 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.