Restart WireGuard client when fails

[GPSMapper]

need to catch an issue again and check the logs more carefully. Will give it a try.

@ZebMcKayhan
So, the script saved me some time for a first time today.
Syslog didn't show anyhting unusual. Disconnect happened between 4:00 and 4:10. The last syslog entry before the event was at 03:36

Apparently I need to increase message level from notice to debug to get more details around what's happening..

Nov 11 04:10:00 wgc-watchdog: Wireguard handshake failed - restarting wgc1
Nov 11 04:10:05 wgc-watchdog: Ping failed - restarting wgc1
Nov 11 04:10:05 rc_service: service 32588:notify_rc restart_wgc 1

 

[ZebMcKayhan]

@ZebMcKayhan
So, the script saved me some time for a first time today.
Syslog didn't show anyhting unusual. Disconnect happened between 4:00 and 4:10. The last syslog entry before the event was at 03:36

Apparently I need to increase message level from notice to debug to get more details around what's happening..

Alright, cool!

Atleast it shows that the tunnel is failing on a low level, not even handshake is working anymore. Like the kernel has trouble reaching the endpoint. Wonder if there have been some kind of WAN event going on. You wouldn't be running dual-wan or something?

Firewall rules are not really nessisary for this to work, so I'm thinking it may be a routing issue? Can't really think of anything obvious that would cause this though.

How did you formulate your vpndirector rules? Do you have any rules that applies for all sources (That may include router local services, like wg)?

Have you enabled the kill-switch?

 

[GPSMapper]

kill-switch = off
some rules apply to specific source IP on local subnet, some rules to all sources
I am not using dual-wan

 

[ZebMcKayhan]

kill-switch = off
some rules apply to specific source IP on local subnet, some rules to all sources
I am not using dual-wan

If you want to, you could add a

logger -t $(basename $0) $(ip route get 101.102.103.104)

Just before the "service restart...." command to get a log output of the route path for the wg tunnel before the restart happens. Replace the ip with your wgc1 endpoint ip.

It may provide some useful insight...

 

[ZebMcKayhan]

Apparently I need to increase message level from notice to debug to get more details around what's happening..

I did update the watchdog script so it produces 2 log files. 1 before the interface restarts and 1 after.

To help debugging, the script saves log files of WG output, Routing rules and routes (both main and policy table) as well as firewall Filter, Nat and mangle. Log files are created both before and after the restart so you may do a compare-by-content on these files and figure out what have changed.

The log files are placed in ram folder (/tmp/) so you don't need to worry about wearing down router flash if you end up with an interface restarting every 10min for a longer time.

If the tests fails and the interface is restarted, the script produces log files here:

/tmp/wgc-watcdog_wgc1_before.log

for system state before the interface was restarted. And here

/tmp/wgc-watcdog_wgc1_after.log

for system state after the interface was restarted. Comparing these files to each other and you could figure out what is changing.

Please note that the log files contains sensitive info, like your public ip and wg public keys. Do not post them publically without obfuscating them.

https://github.com/ZebMcKayhan/Asus-merlin-Wireguard-Watchdog