Check Wireguard tunnel

RouterOS Scripting
1

Hi,

I have this script that checks the connection of a wireguard tunnel between two sites.


:if ([/ping 192.168.88.1 interval=500ms count=10]<8) do={

    :local deviceName [/system/identity/get name]
    :local iFaceName "wg-sts"
    
    :log error "Wireguard: Tunnel with SiteB is down! Reconnecting...";

    # Reset wg-peer to SiteB
    /interface/wireguard/peers/disable [find interface=$iFaceName]
    :delay 5
    /interface/wireguard/peers/enable [find interface=$iFaceName]

    # Check connectivity after 60 seconds
    :delay 60
    :if ([/ping 192.168.88.1 interval=500ms count=5] = 5) do={
        :log info "Verified WireGuard connection to SiteB -> OK!"
    }    
}

In Scheduler I have a task to run every 1 minute, but I would like that if after 10 attempts (10 minutes) it could not connect to the other end, to try again after 60 minutes. Is there any way to do it?

Thanks as always.

2

Curious as to why you ping an internal WG address to see if connection is up??
Assuming this is a client router and the subnet is on the other router??

3

Because that subnet is only accessed through the wireguard tunnel. You could also put the IP of the other end of the tunnel, for example 172.17.50.2.

BR.

4

The newer /tool/netwatch might allow that logic with “On Test” script, you’d just check the last down time >10m in the script before restart.

5

Hi ammo, been seeing snippets of NEW Netwatch can you give a short breakdown of its new features, especially as it might help this thread!

6

I don’t quite understand how I could do it with Netwatch, could you give an example?

7

The thought behind netwatch with a “On Test”/on-test= script is that it runs after each netwatch test. So if the interval is 00:00:30, the “On Test” script runs every 30 seconds, just like a scheduled script. The “On Test” run regardless if the test is successful/failed, so the “On Test” script with interval= is almost same as schedule script.

Now important difference is you already have the results of the ping check available in the netwatch “On Test” script, without having to invoke /ping yourself in scheduler. Importantly, netwatch monitor has a “since” field that reflect the last status change, you can use that to determine if it’s been “too long” since last successful ping test, and then do the restart.

I don’t have time to write an example today. The annoying part is that “since” is actually a string, not a time, so you need convert the string from the “since” field. So you’ll need use one of @rextended snippets to convert the string in “since” field from netwatch (apr/20/2023 04:20:00) into “time”, then you can compare it with some “:if ($parsed-since-as-time < ([:timestamp] - 10m)) do={#restart WG}” in your “On Test” script to try the restart. Not saying better/worse – likely more flexible since netwatch let you define all “icmp” test parameters in netwatch, and then have you “On Test” do the restart if down “too long”.

Also “On Down” script might also do the restart of WG might be used too. Although you’d want the interval= to be at least 00:01:00 and/or set “start-delay=” to same.

The critical thing in all cases is to use the “icmp” test type in netwatch, not “simple”, as icmp one does a few pings, just like the schedule code above.