The value for keepalive is 20 seconds now. Unfortunately, this doesn't help.maybe setting the persistent keepalive value would help you if you have not already tried that.
Yes, I'm using DNS for the WireGuard endpoint.If for your endpoint you have a DNS instead of an IP addr and the DNS subsystem is not yet able to resolve that host by the time wireguard wants to connect, it will fail, wireguard doesn't retry resolving that DNS, you can script it though.
It's mentioned around the forum in a few places.
No, this procedure is for that tiny period in time at power-on where starting of the wireguard interface with a named endpoint would be right in the same timeframe where possibly DNS resolution is not yet functional. This does not apply, to my knowledge, when you use IP addresses as endpoint.So your script is for the client Device, to delay the initial wireguard connection?
Lets say I am a user on the client I open my browser and want to go out.
I will get no result during this delay correct.
When WireGuard is configured properly the issue described is not an issue .... Wireguard recommends that each Peer interface be assigned an IP Address --- THAT is the correct way and if that is done no issue .... so your WireGuard article should reflect that correct procedure otherwise a kludge has to be applied and there is no need for a kludge. OK its not a kludge but a add-in routine that is simply not necessary when WireGuard is properly configured.Sounds like an addition to the wireguard article needs to be worked in.
Oh mighty @mozerd aka `the one that can't read labels`, please test the mentioned scenario in the first post of this topic and in other places on the forum:When WireGuard is configured properly the issue described is not an issue ....
Thanks for answering the question,Someone needs to upgrade some searching skills ...
1- viewtopic.php?t=178930
2- viewtopic.php?t=166214
3- viewtopic.php?t=178341 (post 135)
4- viewtopic.php?t=178704&p=881220 (post 13 indicating it was solved but the issue slipped back in)
I'll stop here ...
In all fairness: I more or less knew which terms would give me the needed hitsThanks for answering the question,
Yes, that may be the case with my search skills )
Search query "wireguard peer not connected after reboot" gave me nothing, and for "wireguard peer" about the first five topics was irrelevant.
wireguard toggle peer site:forum.mikrotik.com
Ah, so you've googled it. I've used the forum's search.In all fairness: I more or less knew which terms would give me the needed hitsThanks for answering the question,
Yes, that may be the case with my search skills )
Search query "wireguard peer not connected after reboot" gave me nothing, and for "wireguard peer" about the first five topics was irrelevant.
Code: Select allwireguard toggle peer site:forum.mikrotik.com
Of course, dont you? Didnt you get the memo from GoogleAh, so you've googled it. I've used the forum's search.
In all fairness: I more or less knew which terms would give me the needed hits
Code: Select allwireguard toggle peer site:forum.mikrotik.com
: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."
}
It will retry on the next scheduler iteration in case one disable-enable cycle was not enough.Time delay ??
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.Time delay ??
#: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,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.Time delay ??
#: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"
}
:global myFunc [:parse [/system script get watch-WG-pp source]]
$myFunc wgcheckip=10.1.1.51 endpointip=xxxyyy.sn.mynetname.net
: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 ....@Znevna
Whereas you say it might be "default behavior" for the protocol, I see it as a bug on the integration in ROS.
The OS should take care to solve this issue for the user.
Confused...@holvoetn I also see it as a bug on the integration within ROS ....@Znevna
Whereas you say it might be "default behavior" for the protocol, I see it as a bug on the integration in ROS.
The OS should take care to solve this issue for the user.
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.Confused...
Didn't you claim some posts ago this issue was non existing when everything was properly configured ?
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.@mozerd: I don't know if you're ignoring @Znevna
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.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.@mozerd: I don't know if you're ignoring @Znevna
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.
Assuming 2 MikroTik Hosts: [2 Tik Routers] Peer 1 on Router 1 and Peer 2 on Router 2One 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.
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.
/interface/wireguard/peers set [find comment="mypeer"] endpoint-address=[get [find comment="mypeer"] endpoint-address]
I can fully agree that it's not up to the PROTOCOL to make sure DNS resolution is functional.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.
I'm not scripting expert. Originally tried with netwatch, nothing happened then reading the forum I saw other people do it with schedule because "netwatch has not enough rights".gdanov, I think netwatch will work without a schedule IF you check off the box that says "Dont Require Permissions" ??
yes, but your wording is bit confusing, so let me repeat: the local peer (one running the script) pings the remote peer's tunnel IP. 10.x.x.x is my wireguard sub-net.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 ???
I don't think that would work if you use it as one script. If you want one script (instead of script entry + second script that invokes it as function) it needs to look something like this:So the complete script would be
...Code: Select all: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" }
:local wgcheckip 10.1.1.51
: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"
finally it all makes sense I always give IPs to my WG peers. Had abs. never thought about going without an IP (well, duh, yes, obvious now).Sorry for the confusion but right back at ya! I didnt understand the below........
so let me repeat: the local peer (one running the script) pings the remote peer's tunnel IP.
10.xc.x.x is my wireguard sub-net.
Can I assume you mean the script on the client device that originates the initial connection (your MT router) , pings an IP address within the subnet you have assigned to the tunnel at the remote site - and thus the linux device has assigned an IP address of something like 10.1.1.1/24 network 10.1.1.0 to the tunnel??
Close?
What if on the Wireguard Setup at the linux end, has NO IP address was assigned to WG Interface ( I rarely do!).
Wouldnt it be good enough to simply ping any local address at the remote site, THRU the tunnel (assuming of course that all requiste wireguard settings and firewall rules allowed the traffic)