will automatically result in failover to 'wan' if WireGuard peer is down. Admittedly I have not been able to test this because my peer is so reliable, but if I just manually stop the WireGuard interface then traffic gets rerouted through 'wan'.
I have verified Dynamic connection by taking WireGuard interface down (ifdown wg0).
The default route switches from (with wg0 up)
root@eddie:~# ip r
default dev wg0 proto static scope link
default via 192.168.1.1 dev wan proto static src 192.168.1.2 metric 100
185.102.219.26 via 192.168.1.1 dev wan proto static metric 100
192.168.1.0/24 dev wan proto static scope link metric 100
to (with wg0 down)
root@eddie:~# ip r
default via 192.168.1.1 dev wan proto static src 192.168.1.2 metric 100
185.102.219.26 via 192.168.1.1 dev wan proto static metric 100
192.168.1.0/24 dev wan proto static scope link metric 100
Right but as for the netifd failover described above does this mean connectivity will be restored if WireGuard peer stops responding? Since taking interface down is a bit synetic isn't it? Or does it take itself down if peer stops responding? E.g. failed handshake or something?
Actually I'm not looking for a solution that seperates networks (or network interfaces) logically to either use a VPN connection or ISP connection for internet traffic.
Instead I want the VPN connection to be used by any subnet provided by the router.
Only in case the VPN connection has a failure WAN should be used.
As written before, for the scenario that WireGuard interface is down, Dynamic connection works as expected.
Now I added a wg-watchdog script that checks if DNS servers, that are only reachable via VPN tunnel, respond. In case there's no response WireGuard interface will be stopped.
Here's the current version of wg-watchdog.sh script:
#!/bin/sh
## Ping IVPN DNS that can only be reached via the VPN tunnel.
## If no contact, put wg interface down.
wgInterface=wg0
tries=0
repeat=5
dns1=172.16.0.1
dns2=10.0.254.2
dns3=10.0.254.3
while [[ $tries -lt $repeat ]]; do
if /bin/ping -c 1 $dns1; then
logger -t "wg0" IVPNdns1 is reachable
exit 0
elif /bin/ping -c 1 $dns2; then
logger -t "wg0" IVPNdns2 is reachable
exit 0
elif /bin/ping -c 1 $dns3; then
logger -t "wg0" IVPNdns3 is reachable
exit 0
fi
logger -t "wg0" WireGuard failure
tries=$((tries+1))
done
logger -t "wg0" WireGuard failed, putting wg interface down
ifdown $wgInterface
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.
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?
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.
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.
