Wireguard use Hostname in endpoint

jaisal · Tue Sep 15, 2020 1:45 pm

Hi,

Wireguard is works fine when used endpoint as IP but it doesn't accepting host name to use DDNS.

[admin@CLIENT1] /interface/wireguard> peers/set endpoint=host.name:12345
numbers: 1
Script Error: action cancelled

is there nay workaround for this ?

JaiS

emils · Tue Sep 15, 2020 2:05 pm

This feature will be added in the next beta release.

foorschtbar · Wed Oct 13, 2021 12:43 am

I tested (1yr later) the latest RC4 and it still not work

eworm · Sat Oct 16, 2021 12:33 am

For me it does work, but there's an issue: Looks like name resolution is tried only once, and peer is non-functional if it failed.

Reported as SUP-62097.

anav · Sat Oct 16, 2021 1:17 am

I use two MT routers behind main routers as wireguard server and peer responsibilities and a smart phone peer as well.
I use IP cloud for endpoint settings for both routers and for the endpoint peer setting in the smartphone.
All works great.

Sat Oct 16, 2021 12:01 pm

I see both behaviors and I do use DDNS-endpoints as well.
Sometimes it just works without further intervention (laptop and smartphone, always first time right).
Sometimes it doesn't for what could be the DNS resolution reason (already seen it on mAP and mAP Lite whereas SXT LTE seems to work just fine, it does take a bit more time to boot then those other devices, maybe that's why).
When it doesn't work, I need to toggle the peer status. And then it immediately kicks in gear.
Easily solved with a small netwatch script or manual button action but something which should be addressed anyhow.

dakky21 · Fri Oct 29, 2021 3:13 am

can you please share your "small netwatch script" ?

Fri Oct 29, 2021 6:46 am

can you please share your "small netwatch script" ?

Sure.
Very basic but does what it needs to do.
10.255.255.1 is the IP of the "server". When that's not visible, WG is down or not active yet.
And I know I shouldn't use peer numbers but there is only 1 peer on that device. Can't go wrong there.

/tool netwatch add down-script="/interface wireguard peers disable 0
    :delay 5
    /interface wireguard peers enable 0"
    host=10.255.255.1

dakky21 · Fri Oct 29, 2021 9:38 am

Thank you very much, I have a similar (or exact) setup - just one peer to one ddns host (server). When ddns host changes IP, the connection isn't re-established, hopefully this will help.

ErkDog · Sat Jan 01, 2022 12:33 am

I can confirm that as of today, after 7 was -officially- released this still was not fixed.

I had everything setup and was beating my head against the wall until I found this forum post.

I manually disabled, then re-enabled the peer on one side and BOOM bob's your uncle.

I guess the netwatch script is a work around. BUT there should be a "monitor IP" for the peer. And it should flip flop the peer if it starts timing out.

Thanks,
Matt

sinisa · Tue Jan 04, 2022 10:04 am

As much as I don't like that, but this behavior seems to be consistent with the way Wireguard works on other platforms and probably won't be "fixed" ever.

If IP on one end changes, WG automagically communicates with new IP as soon as one packet arrives from it.
So if you DDNS endpoint changes, and you have keep-alive on, communication will resume in max "keep-alive" seconds (I keep it at 10s).

In my experience, problem can "only" occur on startup, because WG interface (some times) starts before DNS resolution is working, and in that case WG should retry until it gets first answer from DNS.
Until then, netwatch is your best friend...

anav · Tue Jan 04, 2022 8:41 pm

can you please share your "small netwatch script" ?
Sure.
Very basic but does what it needs to do.
10.255.255.1 is the IP of the "server". When that's not visible, WG is down or not active yet.
And I know I shouldn't use peer numbers but there is only 1 peer on that device. Can't go wrong there.
Code: Select all
/tool netwatch add down-script="/interface wireguard peers disable 0
    :delay 5
    /interface wireguard peers enable 0"
    host=10.255.255.1

Is that on the SERVER router or on the PEER router (client device)?

Tue Jan 04, 2022 8:46 pm

Think about it ...
The SERVER usually has no problem with the DNS resolution. It's IP will be fixed.
The SERVER also has multiple peers connecting to it (that's why we called it a server even though it is also a peer).

So... my little brain twist is to be run on the peer side (but can equally be run on server side if you get the scripting right to disable the right peer)
The nice thing about WG is that only ONE of the sides needs to initiate the connection.
The other will follow.

anav · Tue Jan 04, 2022 8:51 pm

True dat, so you are saying the persistant keep alive setting I have on my peer device (router) set at 40 seconds which seems to keep things going quite nicely will fail eventually??

Tue Jan 04, 2022 9:11 pm

No, not saying that.

This is merely to kick things in gear after startup when initial resolve of ddns does not play nice.
It only checks once, at enabling of interface and peer. If at that moment dns does not work, you can wait a looong time.
Re-enabling peer solves this.

If you use IP as endpoint, no need for this.

DaveN · Wed Mar 23, 2022 5:13 am

FYI, The netwatch script didn't work for me. I've got two devices (hAp ac2 / hAp ac3), both configured to open a wireguard connection to the other device using mikrotik cloud DDNS names. The devices are a hundred km apart, connected to different ISPs.

When I updated the remote hAp ac3 from 7.1.3 to 7.1.5, the wireguard tunnel never came up (waited -30 min to see if it would eventually come up, but it did not). My legacy IPsec road warrior setup did work, so I was able to connect using it instead. After a manual reboot (to update the firmware) the wireguard tunnel did work.

A similar loss of connection occurred to me weeks ago when I updated from 7.1.2 to 7.1.3, which is when I configured the netwatch. I did not lose connection when I was testing the script by manual reboots, nor after an unplanned power outage - so maybe there is something "special" happening only with package update.

I suspect that with the the reboot triggered by package update, the netwatch script didn't run at all. By definition it only runs on a transition from host up to host down. If the wireguard host is down after an update/reboot, and stays down, maybe the script never runs, thus never resets the peer, which never rechecks the server IP address.

My plan is to change from netwatch to a scheduled script run every 10 min, so the peer will get reset for 5 sec every 10 min if it's down (instead of only once on a transition).

I also plan on keeping the Legacy IPsec road Warrior setup as an alternate way to access my remote device!

Wed Mar 23, 2022 8:46 am

For hap AC3 it's difficult to comment since you indicate config was not complete AND it started working after the last reboot.
I am well aware difference in firmware alone should not result in such a misbehavior but I prefer to keep package and firmware the same just to be on the safe side.
Was the same netwatch script present there ?

Can you post the config on that hap ac2 ?
Especially the part with WG-settings and netwatch script ?

Reboot is reboot, as far as I know. Could be an interesting thing if it turns out there is a difference (but how to mitigate then ??).

Having a backup plan is always a good call.

Hominidae · Wed Mar 23, 2022 9:08 am

When I updated the remote hAp ac3 from 7.1.3 to 7.1.5, the wireguard tunnel never came up (waited -30 min to see if it would eventually come up, but it did not).

I see the same, when my local IP. which is passed-trough from LTE (LHGG) changes. Resolution is to delete the existing conntrack entry to the remote/Server side and then toggle the local peer.
Of course, a reboot would delete that entry anyway.

Wed Mar 23, 2022 9:44 am

Ah, the other side ... good call !
Might indeed be that.

Wed Mar 23, 2022 10:09 am

Ah, the other side ... good call !
Might indeed be that.

Thinking this over ... this changing of 'client-IP' should be dealt with automatically by the WG-protocol, as last resort should toggling of peer status do the same thing ?
A reboot should not be needed.

So ... I 'd like to see the script being used within the context of the rest of the settings.

Hominidae · Wed Mar 23, 2022 2:01 pm

Thinking this over ... this changing of 'client-IP' should be dealt with automatically by the WG-protocol, as last resort should toggling of peer status do the same thing ?
A reboot should not be needed.

Agree with the reboot thing. But a Change of local WAN IP in my case does not toggle the conntrack entries for the wg interface going out to the (fixed) remote Server IP.
So the local WG interface is still using the existing connection, trying to reach the other side, even when peer toggled, as it seems.
I can see the traffik trying to go out (tx on peer)...only when the conntrack entry gets removed, the connection goes trough afterwards.

mozerd · Wed Mar 23, 2022 3:35 pm

The only built-in way for a WireGuard ("Peer" client) to detect a change to an endpoint’s IP address is if the endpoint proactively initiates a connection to the ("Peer" client) from its new IP address (which NAT or other firewall rules make impossible in a typical ("Peer" client)/("Peer" server scenario) — many found that you’d have to restart the ("Peer" client) in order to force it to look up the new IP. address of the ("Peer" server).

To solve this issue wireguard-tools have a script that solves this problem .... all that is needed is for MikroTik to make it available within Tik as Tik Speak .... perhaps that will be done in the future. The script {see below} can be fount here ... the script name is reresolve-dns.sh
-------------------------------------------------

#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
#
# Copyright (C) 2015-2020 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.

set -e
shopt -s nocasematch
shopt -s extglob
export LC_ALL=C

CONFIG_FILE="$1"
[[ $CONFIG_FILE =~ ^[a-zA-Z0-9_=+.-]{1,15}$ ]] && CONFIG_FILE="/etc/wireguard/$CONFIG_FILE.conf"
[[ $CONFIG_FILE =~ /?([a-zA-Z0-9_=+.-]{1,15})\.conf$ ]]
INTERFACE="${BASH_REMATCH[1]}"

process_peer() {
	[[ $PEER_SECTION -ne 1 || -z $PUBLIC_KEY || -z $ENDPOINT ]] && return 0
	[[ $(wg show "$INTERFACE" latest-handshakes) =~ ${PUBLIC_KEY//+/\\+}\	([0-9]+) ]] || return 0
	(( ($EPOCHSECONDS - ${BASH_REMATCH[1]}) > 135 )) || return 0
	wg set "$INTERFACE" peer "$PUBLIC_KEY" endpoint "$ENDPOINT"
	reset_peer_section
}

reset_peer_section() {
	PEER_SECTION=0
	PUBLIC_KEY=""
	ENDPOINT=""
}

reset_peer_section
while read -r line || [[ -n $line ]]; do
	stripped="${line%%\#*}"
	key="${stripped%%=*}"; key="${key##*([[:space:]])}"; key="${key%%*([[:space:]])}"
	value="${stripped#*=}"; value="${value##*([[:space:]])}"; value="${value%%*([[:space:]])}"
	[[ $key == "["* ]] && { process_peer; reset_peer_section; }
	[[ $key == "[Peer]" ]] && PEER_SECTION=1
	if [[ $PEER_SECTION -eq 1 ]]; then
		case "$key" in
		PublicKey) PUBLIC_KEY="$value"; continue ;;
		Endpoint) ENDPOINT="$value"; continue ;;
		esac
	fi
done < "$CONFIG_FILE"
process_peer

Wed Mar 23, 2022 3:53 pm

I don't see it that way.

We'll assume here the server has a fixed IP so that part does not change. In which case it is required to have keep-alive being sent from client peer to server peer.
The way I understood WG works, the keepalive send to the other side will at a certain point be coming from another IP when roaming or whatever reason.
That's the key for the receiving end to change its tables towards that other IP.
This should all be done transparently. No toggling of peer should be required.

anav · Wed Mar 23, 2022 4:23 pm

(1) Holvoetn I think mozerd is referring to the commonly known issue for the single case that the ENDPOINT is via mynetname or DYNDNS name.
Nothing else makes sense as you point out, if the endpoint is a static fixed IP, it doesnt matter what happens at the client device (change of IP, reboot etc....)
In this case the ability for the MT Device (client) to resolve the new IP address takes too long.
The keep alive attempts for some reason stop after not connecting after 1? 2? 3? iterations .................................

Thus the scripts noted here to "BUMP" the MT CLIENT device to relook at the wireguard connection. Note that these solutions are very close to the "procustodibus agent", described here
https://www.procustodibus.com/blog/2021 ... endpoints/

Sol/n 1 - Use the script (courtesy of gdanov) on the Remote (originating) end of the tunnel to detect when the endpoint IP address or subnet is not available. In other words 'when down'. The Local_IP refers to the server end of the connection and is any local IP reachable through the tunnel. If that IP is reachable through the tunnel then the tunnel is working!
...

:local wgcheckip Local_IP
:local endpointip xxxyyy.sn.mynetname.net
#:log info "wg check-ip $wgcheckip "
:if ([/ping $wgcheckip interval=1 count=5] =0) do={
  :log info "WG down $wgcheckip"
  /interface/wireguard/peers/disable [find endpoint-address=$endpointip];
  :delay 60
  /interface/wireguard/peers/enable [find endpoint-address=$endpointip];
  :log info "WG up again $wgcheckip"
}

...

Sol/n 2 - Easier method! (unknown author) Using the Netwatch Tool, using the "DOWN" tab, and the HOST IP is the Local IP ( Reachable subnet or IP address through the tunnel).
...

:delay 25
/interface wireguard peer disable 0
:delay 5
/interface wireguard peer enable 0
:log info "WGPeer toggled"

...

(2) However I think Mozerd is referring to a linux script either at the problem child site -- AT THE WG SERVER device or at the client side ????????????????????.
Run this script from cron every thirty seconds or so, and it will ensure
that if, when using a dynamic DNS service, the DNS entry for a hosts
changes, the kernel will get the update to the DNS entry

Since the WG server may know its public IP has changed and because of peer roaming it should have the latest peer client IP and port, it really should be the wireguard server that updates the client device, etc. I see the potential issue happening if both change near the same time, but we can discuss that later.
I see that the linked procustodibus article above comes to the same conclusion as myself....... bloody plagiarizers.......

The only built-in way for a WireGuard client to detect a change to an endpoint’s IP address is if the endpoint proactively initiates a connection to the client from its new IP address (which NAT or other firewall rules make impossible in a typical client-server scenario) — so normally you’d have to restart the client in order to force it to look up the new IP address of the server.
(Note: They solve the issue with their agent on the client side.)

HERE IS THE ANSWER ---- >

This is similar to the functionality of the reresolve-dns.sh script from the wireguard-tools source code repository, which you can manually install and run as a cron job on each client. With Pro Custodibus, however, this feature is automatically built into the agent, so you don’t have to install and configure a separate script to manage it.

mozerd · Wed Mar 23, 2022 4:36 pm

The WireGuard Tools script addresses the following scenario

When the WireGuard interface of the ("Peer" client) starts up, it will resolve the DNS record for myvpn.myddns.com, and select one of the IP addresses to use as its endpoint for the ("Peer" server). Let’s say it selects 1.2.3.4

In many CGNAT networks -- let’s say the WireGuard ("Peer" server) at 1.2.3.4 becomes unavailable, and your DNS servers remove it from their myvpn.myddns.com responses. Your ("Peer" client) will continue to try to access the WireGuard ("Peer" server) at 1.2.3.4 even though the DNS record for vmyvpn.myddns.com now only contains 13.10.199.6

Hope that explains it

anav · Wed Mar 23, 2022 4:42 pm

The WireGuard Tools script addresses the following scenario

When the WireGuard interface of the ("Peer" client) starts up, it will resolve the DNS record for myvpn.myddns.com, and select one of the IP addresses to use as its endpoint for the ("Peer" server). Let’s say it selects 1.2.3.4

In many CGNAT networks -- let’s say the WireGuard ("Peer" server) at 1.2.3.4 becomes unavailable, and your DNS servers remove it from their myvpn.myddns.com responses. Your ("Peer" client) will continue to try to access the WireGuard ("Peer" server) at 1.2.3.4 even though the DNS record for vmyvpn.myddns.com now only contains 13.10.199.6

Hope that explains it

You typed to soon look above for the answer!!! It is simply a script that runs on the client, similar to the procustodibus AGENT, and no different from the two scripts I pointed to above that are on the user article..........

anav · Wed Mar 23, 2022 4:46 pm

So in summary, this thread is simply a LInux script to
a. a problem we are already aware
b. that has solutions in MT scripts

But thanks Mozerd, I really enjoy looking at linux crap

Seriously perhaps there is something in the linux script worth pulling out and into the MT scripts??
I will let my Lover of Chocolate and Horses deal with that noise!!!

Sob · Thu Mar 24, 2022 12:34 am

Another script:

:foreach i in=[/interface/wireguard/peers/find where disabled=no endpoint-address~"[a-z]\$"] do={
  :if ([/interface/wireguard/peers/get $i last-handshake] > [:totime "5m"]) do={
    /interface/wireguard/peers/set $i endpoint-address=[/interface/wireguard/peers/get $i endpoint-address]
  }
}

It takes all enabled peers with endpoint-address ending with letter (which means it's non-empty and not numeric address) and last handshake older than 5 minutes ("5m" on second line), takes current hostname and sets it again as endpoint-address, which makes RouterOS resolve it again. It should be safe to run it unconditionally from scheduler.

DaveN · Thu Mar 24, 2022 5:32 am

@Sob - very elegant!

Here's a slightly improved script:

:foreach i in=[/interface/wireguard/peers/find where disabled=no endpoint-address~"[a-z]\$"] do={
  :local LastHandshake [/interface/wireguard/peers/get $i last-handshake]
  :if (([:tostr $LastHandshake] = "") or ($LastHandshake > [:totime "5m"])) do={
    /interface/wireguard/peers/set $i endpoint-address=[/interface/wireguard/peers/get $i endpoint-address]
  }
}

If the peer has never connected (or if the peer is disabled and reenabled while the endpoint is down), then the last-handshake is blank and the > 5m condition is false. This change will trigger the endpoint-address reset for blank last-handshake as well.

Thu Mar 24, 2022 5:57 am

Good stuff !
Going to play with this ...

anav · Thu Mar 24, 2022 11:33 pm

Interesting.......... and it sends all my money to Sob, just cant figure out where that part is in the script.

Will see if Mikrotik can add this as a checkbox option!

what do you mean safe to run unconditionally from scheduler??
Is there a time option of unconditionally??

Sob · Fri Mar 25, 2022 3:00 am

@DaveN: Ooops, good catch.

@anav: It doesn't. I like that idea, but even if it was somehow possible, I probably wouldn't be able to do it using RouterOS scripting, that thing doesn't like me. And yes, this should be built-in in some form. By "unconditionally from scheduler" I meant compared to other solutions. Like if you disable peer for five seconds, it will break tunnel for five seconds (although if it was linked to netwatch, it was already broken, so no big deal). But you can run this e.g. every minute, even without netwatch, and it shouldn't break any working tunnel.

treeboa · Sat Jun 04, 2022 7:14 pm

Wireguard is works fine when used endpoint as IP but it doesn't accepting host name to use DDNS.

Note (to self and to everyone that might run into the same issue): WebFig on RouterOS 7.2.3 (stable) will not accept FQDN (fully qualified domain name = host name) as endpoint. The input validation will still force you to use an IP address instead.

You have to use the terminal commands to set a FQDN, like in this example:

/interface/wireguard/peers
add allowed-address=10.1.101.0/24 endpoint-address=192.168.80.1 endpoint-port=13231 interface=wireguard1 \
public-key="v/oIzPyFm1FPHrqhytZgsKjU7mUToQHLrW+Tb5e601M="

Using this command will allow you to use a FQDN in place of an IP address.

Shahid · Wed Nov 30, 2022 6:16 pm

hostname issue is still not resolved
so i have created my own script which resolves the host name & puts the latest ip in peer's endpoint-address

:local ddnshost "host.mywire.org"
:local peerip [/interface wireguard peers get [find comment="home"] endpoint-address ];
:local hostip [:resolve $ddnshost];
#:log info "peer endpoint ip address is $peerip";
#:log info "resolved ip address is $hostip"
:if ($peerip != $hostip) do={
/interface wireguard peers set [find comment="home"] endpoint-address=$hostip;
:log warning "Wireguard Peer endpoint IP Updated to: $hostip old IP was $peerip";
} else={
#:log info "WG: no need to update";
}

anav · Wed Nov 30, 2022 7:50 pm

Is this a script you run on a schedule?

foorschtbar · Wed Nov 30, 2022 9:56 pm

Is this a script you run on a schedule?

Here is a „small“ guide: https://blog.spaps.de/mikrotik-routeros ... t-refresh/

Shahid · Thu Dec 01, 2022 12:50 pm

Is this a script you run on a schedule?

Yes i run it after 1 minute interval
here is the export

/system script
add dont-require-permissions=no name=wg owner=zone policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":lo\
    cal ddnshost \"host.mywire.org\"\r\
    \n:local peerip [/interface wireguard peers get [find comment=\"Office\"] en\
    dpoint-address ];\r\
    \n:local hostip [:resolve \$ddnshost];\r\
    \n#:log info \"peer endpoint address is \$peerip\";\r\
    \n#:log info \"resolved address is \$hostip\"\r\
    \n:if (\$peerip != \$hostip) do={\r\
    \n/interface wireguard peers set [find comment=\"Office\"] endpoint-address=\
    \$hostip;\r\
    \n:log warning \"Wireguard Peer endpoint IP Updated to: \$hostip old IP was \
    \$peerip\";\r\
    \n} else={\r\
    \n#:log info \"WG: no need to update\";\r\
    \n}"

& for Schedule


/system scheduler
add interval=1m name=wireguard on-event="/system/script/run wg" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-date=nov/12/2022 start-time=14:39:59

Chupaka · Thu Dec 01, 2022 1:08 pm

I like this one more: viewtopic.php?p=921026#p921026

Because you have FQDN in WG Peer, not only in a script, and you only update it when there's no connectivity. WG can automatically detect new peer IP if there are packets from new IP with the same signature, so you don't need to update the endpoint in that case.

aoakeley · Thu Dec 01, 2022 4:41 pm

Here is another one for you. It is a bit more brutal, but it is versatile as it does not rely on finding any comments, and you can put it on a router with a number of peers and it will just pick out the ones that need killing and restarting without affecting the ones that are OK.

It checks

if handshake >3min (no peer should ever have handshake more than 00:02:10)

It also checks if there are any peers with 0 tx or 0 rx (which sometimes happens after reboot, and if the peer has never started it will never get handshake >3min)

it disables any peer that meets the above two critera

THEN in addition looks up the ports in use by each peer, and clears any connections in the firewall (useful if traffic is trying to go out the wrong interface)

and finally logs a bit to the log file, only if it has found something to do (so you don't end up with log spam)

Then re-enables the peer


# Wireguard check script

#Declare variables
:local wgport
:local wgpeer

# Disable any peers that have last handshake > 3mins
/interface/wireguard/peers/set disabled=yes [find last-handshake > [:totime "3m"]]
# Disable any peers that have tx or rx 0 (sometimes happens after router restart) 
/interface/wireguard/peers/set disabled=yes [find rx=0 or tx=0]

:delay 2

# For any disabled peer get the port and clear any connections in the firewall
:foreach i in=[/interface/wireguard/peers find disabled=yes] do={
   :set wgport ([/interface/wireguard/peers get $i endpoint-port])

   :foreach j in=[/ip firewall connection find dst-address~":$wgport\$" protocol=udp] do={
   /ip firewall connection remove $j
: log info "** Wiregiuard Check Script ** firewall connections on port $wgport cleared"
   }

# and re-enable any disabled peers
/interface/wireguard/peers set $i disabled=no

# and let the log file know what has happened
:set wgpeer [/interface/wireguard/peers get $i interface]
:log info "** Wireguard Check Script ** wireguard peer $wgpeer restarted"

}

Chupaka · Thu Dec 01, 2022 5:49 pm

It IS brutal

Btw,

s/:$wgport/:$wgport\$" protocol="udp/

? So if port is 9090, no connections with port 90907 would be killed.

aoakeley · Thu Dec 01, 2022 6:27 pm

It IS brutal

Btw,
Code: Select all
s/:$wgport/:$wgport\$" protocol="udp/
? So if port is 9090, no connections with port 90907 would be killed.

Good spot. Thanks. I have edited my original post to save clogging up the thread with a new post.
I have about 50 devices running behind StarLink CGNAT with a second LTE interface. I have found I need to be brutal otherwise it does not always come back up.
I think sometimes the connection gets stuck on the wrong interface, and requires both disable/enable of the peer and clear the connection for it to start again.

anav · Thu Dec 01, 2022 9:18 pm

Just to confirm these scripts are meant for the client router side ( meaning client at the initial handshake ).

Will also ask the same question @aoakeley, is this script run on a schedule???
Also how does your router use the local variables......?
In other words your variables, it seems you do not assign them any values??? OR are they known variable names embedded
in MT OS, where the router will take wgpeer and wgport and figure out what is what on the config?

Tough time picking between Sob/Daves version and aoakeley's version LOL.

@chupaka, I have now far too many script variations on the wireguard article. if you have spare time, happen to be sitting on the white telephone with laptop, can you go to Para 6 and let me know which ones I can rid of, or which ones i should keep. TX!
viewtopic.php?p=906311#p906311

aoakeley · Fri Dec 02, 2022 2:41 am

Just to confirm these scripts are meant for the client router side ( meaning client at the initial handshake ).

If you have mikrotik at both ends you can run at both, It would help clear up any stale connection at either end. It wont touch any connection that is in good health.

Will also ask the same question @aoakeley, is this script run on a schedule???

Yes

Also how does your router use the local variables......?

The script sets wgpeer and wgport within the if statements. Look for the lines starting with ":set" within the if statements.
So it works like this
1.it detects a peer that is not working
2.it disables the peer
3. delays for 2 seconds (you can probably remove this)
4.then cycles through the "if" with

if peer is disabled find which peer it is and set the $wgpeer variable

use $wgpeer to find the port of that peer and set $wgport

use $wgport to clear the connection in the firewall

repeat for all disabled peers

5. Then enable the peers again

Tough time picking between Sob/Daves version and aoakeley's version LOL.

Mine is not really that different, except that it is a but more brutal in that it disables and re-enables the peer and clears the firewall connections.
And checks for peers with 0 tx or Rx, which I have seen happen after a router reboots and the peer does not come up. in this case the handshake time sits at 00:00:00 so any script that is looking for last-handshake > 3mins or whatever wont ever run and the peer will never establish.

I hope this helps.

Andy

Shahid · Fri Dec 02, 2022 7:40 am

So it works like this
1.it detects a peer that is not working
2.it disables the peer
3. delays for 2 seconds (you can probably remove this)
4.then cycles through the "if" with

if peer is disabled find which peer it is and set the $wgpeer variable

use $wgpeer to find the port of that peer and set $wgport

use $wgport to clear the connection in the firewall

repeat for all disabled peers
5. Then enable the peers again

So it is not affecting other disabled peers in anyway?
because someone might need to deliberately disable some peers for some reason.

Shahid · Fri Dec 02, 2022 6:28 pm

Here is another one for you. It is a bit more brutal, but it is versatile as it does not rely on finding any comments, and you can put it on a router with a number of peers and it will just pick out the ones that need killing and restarting without affecting the ones that are OK.

It checks
if handshake >3min (no peer should ever have handshake more than 00:02:10)

It also checks if there are any peers with 0 tx or 0 rx (which sometimes happens after reboot, and if the peer has never started it will never get handshake >3min)

it disables any peer that meets the above two critera

THEN in addition looks up the ports in use by each peer, and clears any connections in the firewall (useful if traffic is trying to go out the wrong interface)

and finally logs a bit to the log file, only if it has found something to do (so you don't end up with log spam)

Then re-enables the peer
Code: Select all
# Wireguard check script

#Declare variables
:local wgport
:local wgpeer

# Disable any peers that have last handshake > 3mins
/interface/wireguard/peers/set disabled=yes [find last-handshake > [:totime "3m"]]
# Disable any peers that have tx or rx 0 (sometimes happens after router restart) 
/interface/wireguard/peers/set disabled=yes [find rx=0 or tx=0]

:delay 2

# For any disabled peer get the port and clear any connections in the firewall
:foreach i in=[/interface/wireguard/peers find disabled=yes] do={
   :set wgport ([/interface/wireguard/peers get $i endpoint-port])

   :foreach j in=[/ip firewall connection find dst-address~":$wgport\$" protocol=udp] do={
   /ip firewall connection remove $j
: log info "** Wiregiuard Check Script ** firewall connections on port $wgport cleared"
   }

# and re-enable any disabled peers
/interface/wireguard/peers set $i disabled=no

# and let the log file know what has happened
:set wgpeer [/interface/wireguard/peers get $i interface]
:log info "** Wireguard Check Script ** wireguard peer $wgpeer restarted"

}

@aoakeley
It is not suitable where one want to disable one or more peers, you enable all of them.

/interface/wireguard/peers/set disabled=yes [find rx=0 or tx=0]

Condition matches already disabled interfaces too.

/interface/wireguard/peers set $i disabled=no

enables all interfaces

Conclusion: finding comment & editing only required fields is way better than yours.
Here is my script

anav · Fri Dec 02, 2022 8:42 pm

I note the terms >5min or >3min, seems like running the script every 10 minutes makes sense.....................
I prefer not to run scripts frequently if avoidable...........aka 1minute for example

Shahid · Fri Dec 02, 2022 8:59 pm

I note the terms >5min or >3min, seems like running the script every 10 minutes makes sense.....................
I prefer not to run scripts frequently if avoidable...........aka 1minute for example

Dear I am not asking you to use 1 minute
That depends on how crucial your wireguard connectivity is. In my case i cant wait 10 minutes for the peer to reconnect. Simple

aoakeley · Mon Dec 05, 2022 2:00 am

Conclusion: finding comment & editing only required fields is way better than yours.
Here is my script

Whatever dude.... it is not a competition. Relax.
Some stuff works better for some than others.

Shahid · Mon Dec 05, 2022 8:06 pm

Conclusion: finding comment & editing only required fields is way better than yours.
Here is my script

Whatever dude.... it is not a competition. Relax.
Some stuff works better for some than others.

Yup

Surely we all are here to share our knowledge & experience for better routing for everyone. Happy Routing
I agree with @Chupaka & I think this one is the masterpiece. Courtesy @Sob & @DaveN

:foreach i in=[/interface/wireguard/peers/find where disabled=no endpoint-address~"[a-z]\$"] do={
  :local LastHandshake [/interface/wireguard/peers/get $i last-handshake]
  :if (([:tostr $LastHandshake] = "") or ($LastHandshake > [:totime "5m"])) do={
    /interface/wireguard/peers/set $i endpoint-address=[/interface/wireguard/peers/get $i endpoint-address]
  }
}

DaveN · Mon Mar 06, 2023 9:07 am

I like this one more: viewtopic.php?p=921026#p921026

Because you have FQDN in WG Peer, not only in a script, and you only update it when there's no connectivity. WG can automatically detect new peer IP if there are packets from new IP with the same signature, so you don't need to update the endpoint in that case.

Here's the script I'm currently using. Since Wireguard is a quiet protocol, I made the script quiet as well. Wireguard is only reset if the last handshake was more than 5 minutes ago, and data has been transmitted. I'm not using a keep-alive, and I'm not Netwatching, so if Site A doesn't talk to Site B then, by design, the Wireguard handshake will not be re-done until data is sent. This can be hours or days in my use case.

:global Tx
/interface/wireguard/peers
:foreach i in=[find where disabled=no endpoint-address~"[a-z]\$"] do={
  :local LocalTx [get $i tx]
  :local LastHandshake [get $i last-handshake]
  :if (([:tostr $LastHandshake] = "") or (($LastHandshake > [:totime "5m"]) and ($Tx->[:tostr $i] != $LocalTx))) do={
    :local EndpointAddress [get $i endpoint-address]
    :log info ("WG $EndpointAddress down, LastHandshake $LastHandshake, LastTx " . $Tx->[:tostr $i] . ", CurrentTx $LocalTx")
    set $i endpoint-address=$EndpointAddress
  }
  :set ($Tx->[:tostr $i]) $LocalTx
}

For those who like to lock things down, the script policies required are read,write,policy,test.

I use the scheduler to run the script every 2 minutes - so 5 minutes minimum, 7 minutes maximum of downtime before a reset is attempted.
I based the ($LastHandshake > [:totime "5m"]) on the 180s max valid handshake time (Reject-After-Time), plus the 2 minute schedule. If data was transmitted in that interval, then it would have failed as the handshake is invalid (assuming the Wireshark code in Mikrotik was compiled with the same constants I found at wireguard.com).
The Wireguard pipe has not been down when I tried using it in the last 6~12 months - although I'm unable to force a DDNS IP address change at will to fully test it. I can confirm that the connection has restarted after power outages (both ends, usually not simultaneously, big thanks to Hydro-Quebec for their 'help' testing).

Mon Mar 06, 2023 10:20 am

Nice

Q: Why run it on a 2 minute schedule if nothing will happen in a 5 minute timeframe ?

Chupaka · Mon Mar 06, 2023 11:40 am

Because

I use the scheduler to run the script every 2 minutes - so 5 minutes minimum, 7 minutes maximum of downtime before a reset is attempted.

In worst case scenario, your script is run on 4:59 after last handshake (and does nothing), then on 6:59 and updates the endpoint IP address

Mon Mar 06, 2023 1:14 pm

Then (in my view) it would be more logical to use a 2 minute timeframe to do nothing.
Why not reacting for 5 minutes ?

DaveN · Tue Mar 07, 2023 5:59 am

It can't be a 2 minute timeframe to do nothing, but probably the 5 min could be reduced to 4 min (with the script scheduled every 2 minutes); or it could be set to 185s with the script scheduled every 65s.

This is my thought experiment determining these numbers:
Assume handshake is done and data sent at time t=0, and more data is sent just before 120s (but no handshake is done, nor expected because it is just before Rekey-After-Time).
The script runs every 2 minutes, worst case at t=119.999, t=239.999s. If it checks for no handshake+data in the last 239.998s (<4 min), then it would reset the endpoint at t=239.999s because there has been no handshake since t=0, but data sent at 120s. This I want to avoid as the endpoint is being reset even though the pipe is not down.
So, for this situation, the script needs to "do nothing" for Rekey-After-Time + script frequency, which is 4 minutes (with the script scheduled every 2 minutes).

Now lets say handshake is done and data sent at time t=0, and more data is sent just before 180s. In this situation a handshake request sent, but not responded to immediately. The existing encrypted pipe will be used for the data until t>180, at which point it will be invalidated.
I had based my 5 min on 180 sec of valid pipe and no need for a handshake for the data to go through (plus 2 min for the script to run), but realize now that a handshake request would be triggered in this last minute and even if the data is going over the existing pipe the handshake would be renewed (it's given Rekey-Timeout 5 seconds to respond), so a handshake would occur at t=185 maximum. This is the lower bound on the no handshake+data time and doesn't depend on the script timing.

So, the smallest time for the script to "do nothing" is 185 sec, and it needs to be scheduled every 65 seconds.

Thanks for making me take a closer look at this!

P.S. Check page 14 of https://www.wireguard.com/papers/wireguard.pdf for the timer constants in Wireguard.

anav · Tue Mar 14, 2023 11:59 pm

Yeah you guys lost me long ago.
Do you have a story that can be told that is easier to grasp.

The way I understood is that the peer initiates a connection (single handshake with the endpoint device) and the two communicating devices send traffic back and forth as required during a session.
When no traffic is being passed in either direction, the peers persistent-keep-alive, keeps the tunnel open.

In other words, one handshake and then continuous connectivity. Then there is no need for a handshake but it appears for new sessions there is some negotiation (perhaps a new temp key or something). In any case, need a story>.

DaveN · Tue Mar 28, 2023 5:31 am

It's all in the whitepaper https://www.wireguard.com/papers/wireguard.pdf - which is admittedly a pretty heavy read.

This is the way I understand it:
Either end initiates a connection, and the two communicating devices send traffic back and forth as required. There is no server and client, both ends are equal peers, and either end can initiate (or rekey) a connection.
When no traffic is being passed in either direction, the communication goes silent - unless an optional persistent-keep-alive is enabled which keeps communication open by periodically sending empty data packets.
The communication is triggered to be rekeyed (i.e. another handshake creating a new session) when a data packet is sent and the current session is older than 120 sec (or after 2^60 messages sent, whichever occurs first). During the rekeying, the original session remains valid and continues to be used.
The original session is invalidated and no longer usable when it is 180 seconds old (or 2^64 − 2^13 − 1 messages sent, whichever occurs first).

From the whitepaper

WireGuard keeps in memory the current secure session, the previous secure
session, and the next secure session for the case of an unconfirmed session. Every time a new secure session
is created, the existing one rotates into the “previous” slot, and the new one occupies the “current” slot, for
the initiator, and for the responder, the “next” slot is used interstitially until the handshake is confirmed.

There is also a passive-keepalive mentioned in the whitepaper. This is only sent when only one peer is sending data and there is no data being sent in the other direction. It allows the sending peer to know that the tunnel is still up. This is different from, and should not be confused with, the optional persistent-keep-alive.

From the whitepaper:

This passive keepalive is only sent when a peer has nothing to send, and is only sent in circumstances when
another peer is sending authenticated transport data messages to it. This means that when neither side is
exchanging transport data messages, the network link will be silent.
Because every transport data message sent warrants a reply of some kind—either an organic one generated
by the nature of the encapsulated packets or this keepalive message—we can determine if the secure session
is broken or disconnected

So, for me as an end user looking at the data available from my mikrotik routers, I know that the tunnel is down if my session is invalid (handshake >180 sec) and data has been sent after this time.
My modifications to @Sob's script was based on the thinking that since the script runs every two minutes and I'm comparing current Tx with previous Tx. If Tx changes then data was sent sometime in the last 2 minutes. Thus the handshake needs to be older than 5 minutes and Tx needs to have changed to meet the tunnel down condition (handshake >180 sec when data has been sent which could have been 2 minutes ago).

I then revised this thinking as described in my previous post and brought the time down to 4 min - which seems to be working on my devices so far.

Personally I do not enable the persistent keep-alive as both my peers are reachable directly from the internet (i.e. not behind a double NAT).
WireGuard is so light that it will only do the dns lookup of a FQDN specified peer once (i.e. at boot or when the mikrotik peer configuration is set).
If persistent-keep-alive is enabled, then the script is mostly unnecessary as a peer with a dynamic IP that changes will send or reply from it's new address and the other peer's WireGuard will update it's internal IP table and reply to the new address. Communication would only go down if both peers changed their addresses at the same time.
I use the script in order to trigger a DNS lookup if a peer address changes while the communication is silent, preferring to use CPU cycles running a script rather than using keepalive network traffic to constantly send empty data packets back and forth. I also use the script to work around what appears to be a mikrotik bug where WireGuard didn't work after boot (it seems like the dns lookup of the other peers FQDN was not working - maybe it's attempted before the dns server is reachable).

Rfulton · Wed Mar 29, 2023 2:21 pm

Same issue on restart.
Wireguard won't initiate unless disable and re-enable the peer.

Wed Mar 29, 2023 2:40 pm

Start on post 8, 28, 29 and further down.

Various solutions have been presented to circumvent this problem (until they finally solve it in ROS itself, where it should be solved)

anav · Wed Mar 29, 2023 2:52 pm

Start on post 8, 28, 29 and further down.

Various solutions have been presented to circumvent this problem (until they finally solve it in ROS itself, where it should be solved)

AMEN TO THAT BROTHER, I already put in a request and nothing, so the more people that do...............the better chance it will happen.

I will not even be mad if they do that one sooner than the critical improvement we are all waiting for...............
ZeroTrust Cloudlfare Tunnel in an options package for all devices ( MT is racists vs non ARM processors )

Wed Mar 29, 2023 3:00 pm

That last part is not entirely true. They enabled wifiwave2 package for mmips devices to be used as capsman controller

I am still trying to understand why zerotrust cloudflare (from a security point of view) is better then personal wireguard connections.
Zerotrust means for me I also don't trust anyone else to act as hub for my connections.

anav · Wed Mar 29, 2023 3:10 pm

Because, one doesnt have to expose ones's public IP on the internet to host servers........

THEREFORE ITS intrinsically more secure
IT avoids all the users with so many useless firewall traps to try to stop people hitting on servers etc.........
Clean, efficient and secure.
Effects I would say conservatively 85% of users on these forums have one sort of server or another.

An awesome way to share an NAS server with family etc......

Wed Mar 29, 2023 3:12 pm

Did I already say I don't trust anyone ?
I am not sharing my NAS with family.

anav · Wed Mar 29, 2023 3:15 pm

Your personal issues have nothing to do with MT functionality!

Seriously my condolences for the 'family situation', its easy to forget not everyone is so lucky.

DaveN · Thu Jun 15, 2023 8:53 pm

From 7.10 release notes:
) wireguard - retry "endpoint-address" DNS query on failed resolve

Who is online