Ah, so you’ve googled it. I’ve used the forum’s search.
Of course, dont you? Didnt you get the memo from Google
"If you dont use Google as your search engine, we will release the incriminating photos, emails and text messages we have on your file, pfft and she/he isnt even that good looking "
As long as I cannot be sure what IPs are available on the other side of the WireGuard connection (it’s a VPN provider’s network) and one cannot specify an interface to use for the Netwatch, I’ve come up with this script for the Scheduler:
:local pingStatus [( [/ping address=8.8.8.8 count=1 interface="WireGuard Interface" as-value]->"status"=null)]
:if ($pingStatus = false) do={
/interface/wireguard/peers/disable 0
/interface/wireguard/peers/enable 0
/log/info message="WireGuard Interface Peer has been restarted."
}
Time delay ??
It will retry on the next scheduler iteration in case one disable-enable cycle was not enough.
I use 60 secs between disable/enable peer. Also below is my script. Such script is mandatory on at least one of the tunnel sides because WG does DNS resolution only once at start. While advertised to support “roaming” — IP change — I’ve found the tunnel goes stale every now & then with no attempt to re-connect whatsoever. This may be separate issue, IDK, but with dynamic IP + DNS some sort of script is absolute must.
#: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"
}
I am a horrible script reader,
It appears to say, Ping some variable called $wgcheckip five times and if the return of (one or all five times?) is zero
inform the admin that the endpoint is not available
and carry out a process to disable wg peer for 60 seconds and then re-nable peer
Then tell admin wg is back up.
Clearly I dont understand the bolded line very well, and on top of that how does the router know what $wgcheckip is ??
Most likely somewhere else in the script (or global variable) $wgcheckip will be defined as the IP address to check on the other side.
@anav well, you’ve understood it well. the two ip variables are the internal and the endpoint addresses. when I can’t ping the internal one, I disable/enable the peer record finding it by the external IP.
the script is executed via a schedule, as a function, like that:
:global myFunc [:parse [/system script get watch-WG-pp source]]
$myFunc wgcheckip=10.1.1.51 endpointip=xxxyyy.sn.mynetname.net
you need to do it in a schedule because (since some release) netwatch does not have the proper rights.
gdanov, I think netwatch will work without a schedule IF you check off the box that says “Dont Require Permissions” ??
Just to be clear, 10.1.1.51 being pinged from the remote client router is
you trying to ping a subnet address on the Server router through the tunnel ???
So the complete script would be
…
:global myFunc [:parse [/system script get watch-WG-pp source]]
$myFunc wgcheckip=10.1.1.51 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"
}
@holvoetn I also see it as a bug on the integration within ROS …
Confused…
Didn’t you claim some posts ago this issue was non existing when everything was properly configured ?
I and many of my clients have been using WireGuard for a number of years primarily with EdgeMax Routers and have not experienced this phenomenon… I recently [7.1.1] started to use WireGuard under ROS and have a few Tik clients utilizing that VPN with no issues reported. I have observed that a number of folks here are flagging this issue which is why I also believe that it’s an issue specific to Mikrotik.
fYI, I have rebooted my MikroTik a number of times and have not experienced the issue … I happen to believe that WireGuard works well when it’s rules are followed … in following the recommendation set out by WireGuard where each Peer virtual interfaces is assigned an IP address IP Roaming works as advertised … it has for me and my limited set of Tik clients.
Yes I am ignoring Znevna … if that person want to have a discourse with me Znevna can act with civility otherwise I have no interest.
I am aware of the processes expressed … I am only relaying my experiences utilizing WireGuard … and I continue to believe that many are not following WireGuard procedures …. Obviously some have a problem and I believe it’s got more to do with how MikroTik have incorporated WireGuard into RoS ….
A key point in all my dynamic tik implementations is …. Upon reboot my DDNS script fires soon after the IP is captured or if IP is lost due to whatever cause and is re-initialized the DDNS script fires again so my endpoints never are left hanging. I do not use Tik’S DDNS service cause it’s erratic. 
One doesn’t have to use DDNS for this issue to occur. It takes only DNS address as the Peer Endpoint value for the aforementioned issue to take place.
Assuming 2 MikroTik Hosts: [2 Tik Routers] Peer 1 on Router 1 and Peer 2 on Router 2
If there is no Internet on Router 2 Peer 2 Endpoint cannot communicate — that is obvious — and when the Internet becomes available again WireGuard should come up based on the the keepalive packet assuming that has been turned on appropriately … if WireGuard will not come up under that circumstance THEN its a MikroTik issue based on how it was integrated into RoS – so Yes I belive it to be a bug.
IMO @holvoetn nailed it by stating
It’s indeed a problem since the integration of WG into ROS7 when using DDNS and DNS resolving is not yet active when WG interface starts.
keepalives are sent to the current endpoint addr:port, if endpoint fails to resolve there is no current endpoint, there is no destination for that keepalive.
Current endpoint can also be populated if our peer somehow receives a valid packet from the other side (but if we are behind a natted IP this is less likely to happen).
Read the docs, spend some time on the wireguard official IRC channel, read the mail lists.
“works for me” means nothing otherwise.
Well, it looks like sort of bug or missing feature. If WG has hostname for peer’s endpoint and it fails to resolve, WG doesn’t try again (at least not quickly enough before I lost my patience waiting whether it will or not). And remote peer won’t help if they are in client-server relationship (this side is client), where server doesn’t know client’s endpoint beforehand.
It’s enough to re-set hostnames to make it try again (ugly code, I’m almost sure there’s better way how to achieve the same):
/interface/wireguard/peers set [find comment="mypeer"] endpoint-address=[get [find comment="mypeer"] endpoint-address]
But this should be built-in. System knows that hostname didn’t resolve, so it could try again automatically (after some reasonable delay).
This “feature” is not built in any WireGuard implementations, wireguard itself doesn’t handle that, alone. There is the re-resolv-dns script provided mentioned above and that’s it.