Hi!
On RouterOS v7.1, I would like to make a script to report when there is a connection to the wireguard server (road-warrior).
Any ideas please?
Thanks.
Wireguard is what they call a stateless connection.
Only way to know it works is to see if you can reach ’ the other side’
There is a keep alive settings and you can see it in bleep on the graphs every xx seconds
It will update and shows the time pased since the last reconnect. It would be nicer if there was alive not alive status.
Now a routine has to be scripted that stores last two “last handshake” times and compares it to the current “last handshake” time. And then a reconnect will start counting from the start and comparing becomes a PITA.
You can adapt to this and then you will only know after three scans if a connection is really alive.
Examples:
scan one: 00:01:25, scan two: 00:00:05, scan three: 00:00:05 → not alive
scan one: 00:01:25, scan two: 00:00:05, scan three: 00:00:10 → alive
scan one: 00:01:25, scan two: 00:01:35, scan three: 00:00:10 → alive
scan one: 00:01:25, scan two: 00:01:35, scan three: 00:00:10, scan four: 00:00:10 → not alive
So use a sliding window of three, two historic and one current.
Use an array, so you can adapted easy to when multiple WG connections are used and it also provides an easy option to slide the Window.
I see what you say is complicated. Finally I have used a script that I call from Netwatch to the IP address of the other end of the road-warrior connection (mobile client).
Best regards.
How do you ensure that IP is not accessible through a other gateway? I assume then that the IP on the other end is private and so only ping-able through the WG connection.
I a VPN provider and don’t have then a IP that is unique at the other side of the WG connection. Netwatch exits on the OUT port and then I could force via mark routing (Mangle) it through one of the WG connections.
Thanks, it works. It would be nice if NetWatch could forced to use an exit port, instead of using ‘mark routing’ to archive that.
That would be the only logical way, yes. A private IP should not be able to pass a public channel.
My apologies but this is not really understandable …
So, I want Netwatch to ping 1.1.1.1 and because Netwatch exits through the default gateway, and WG is here not the default gateway, I have steer that ICMP packet so it goes through WG instead of the default gateway.
/ip firewall mangle
add action=mark-routing chain=output disabled=yes dst-address=1.1.1.1 new-routing-mark=wg-1 passthrough=no protocol=icmp
wg-1 Is one of the WG connections.
Wouldn’t this mean something is off with the routes ?
What’s otherwise the use of having a WG-tunnel and no default route to use it ?
I could be completely wrong and surely I am missing something then …
[funny mode: ON]
A packet from Tools is created in the processor and so not known in pre-routing. They are blank and so destined to run for the big golden gateway before it is stopped by the traffic warden (Mangle) that noticed it was stamped for 1.1.1.1 and that it was also a ICMP type of packet, and that one was on his list.
The packet then gets directed to an other exit (WG) where it gets a cloak of encryption and is warped to the other end of the tunnel. There it has to hand in the cloak, and then sees an other big golden gateway. The traffic warden there, let him run run and run and yells “don’t let the gateway hit you on the way out”!
This packet was not on his out-list but he noticed, when it returns that packet has to be cloaked and warped back through the same tunnel it came…at-least, according to his in-list. Let’s see if that packet manage to get back again running in a dangerous world, outside of the gateway.
[funny mode: OFF]
The WG tunnel goes itself through the default gateway but you will only see the outside of tunnel. On the inside packets are cloaked and warped from one side to other side.
If you have then more than one tunnel you have also specify which tunnel has to be used.
Such responses we need to see more 
Great stuff !
I know the tunnel itself goes through the default GW (obviously ! It’s the only way ultimately going out provided other exits are foreseen) but you need to specify a route for the ip-range which needs to enter that WG-tunnel, no ?
My destination IP range is 0.0.0.0/0 so I need to mark connections and route to determine if it should take one of the WG-tunnels. Connection marks make it easy to see from which tunnel, the packets returned.
If you are using WG from one router to an other for a private private tunnel then then you can route that on SRC or DST IP.
I also have a route for 0.0.0.0.
And for the range which needs to handje wg but at a lower distance so it gets preference.
No mangle needed in my case.
My config:
Netwatch:
/tool netwatch
add down-script="/system script run vpn-iphone-down" host=10.10.0.2 \
up-script="/system script run vpn-iphone-up" interval=60s timeout=1000ms
Script “vpn-iphone-down”:
# START Send Telegram Module
:local deviceName [/system identity get name]
:local client "iphone"
:local MessageText "\F0\9F\9F\A0 $deviceName: Wireguard VPN to $client is Down";
:local SendTelegramMessage [:parse [/system script get MyTGBotSendMessage source]];
$SendTelegramMessage MessageText=$MessageText;
# END Send Telegram Module
:log info "Wireguard: VPN to $client is Down"
Script “vpn-iphone-up”:
# START Send Telegram Module
:local deviceName [/system identity get name]
:local client "iphone"
:local MessageText "\F0\9F\9F\A2 $deviceName: Wireguard VPN to $client is UP";
:local SendTelegramMessage [:parse [/system script get MyTGBotSendMessage source]];
$SendTelegramMessage MessageText=$MessageText;
# END Send Telegram Module
:log info "Wireguard: VPN to $client is UP"
That’s it.
If you have many WireGuard VPN, it will be very cluttered with may scripte (2 fore each vpn).
So you can use $host in the script that will then show the IP of the monitored VPN server.
Here is my up down script that I use to monitor VPN. Just add one netwatch for each VPN to monitor.
add dont-require-permissions=yes name=WireGuard_down source=\
":log info message=\"vpn=wireguard status=down host=\$host\""
add dont-require-permissions=yes name=WireGuard_up source=\
":log info message=\"vpn=wireguard status=up host=\$host\""
Same could be used with Telegram. I do send it to Splunk.
Please, can you give me an example of what the script would be like?
Thank you very much for the advice
You could be interested in my script Notify on host up and down. It has a lot of advantages compared to using up-script and down-script…
Hi worm,
I notice you dont use “Dont Require Permissions” in your script but do require it to be scheduled??