I learnt something new today. Your setup is more complicated than necessary, both peers try to resolve and connect to each other. But that complication actually makes it possible for WireGuard to "punch" through a firewall/NAT setup and keep the mapping alive long enough for the other side to connect. In a way, both peers are yelling at each other to be able to connect.
So like a man in new orthopedic shoes, I stand corrected.
I would still argue that it is not the ideal way to set up since both peers need to be resolve-able through DDNS, and both peers need to constantly check whether the peer's DDNS has changed (which might be hard for free-roaming clients, if not downright impossible with mobile or desktop clients). Also, it will not work if one of the involved routers is masquerading.
I would probably still recommend declaring one side of the relationship a "server" and have the respective port forwards/firewall rules. But, yes, it is an option.
As to your other problem, I hope my answer wasn't as useless and ill-informed. You did manage to reinitialize your Wireguard connection without rebooting your routers, yes?
wireguard_watchdog is on test since 2 days, had issue with one gateway device early today, will observed for following 5 days and update you and the forum
#Script Start here and documented on purpose by ZOzo on 19/08/2018 #to reload 'network' and 'firewall' and the 'WireGuard' interface named 'wg0' here #to solve issue with WireGuard lost of connection following #IP changed on an endpoint host which is dynamically allocated by ISP #note that script commands below is for one endpoint only, which is LAST-Z.NET
#Then integrate the function in following script, #I forget where exactly but script was acquired online for another purpose #and here being used to help solve my current issue #As at today the wireguard_watchdog available at https://lists.zx2c4.com/pipermail/wireguard/2018-June/003000.html #is not working on two test router following past 2 days implementation, TP-Link Archer C2600 and WDR4300v1
#The KnownIP file location the command will create here is located in /etc #but can be relocated where ever you want with appropriate access permission #if you dont want to polute your /etc directory
#'ifdown wan' is pervasive, WireGuard being at kernel level and still being finalizing #there surely will be better known solution to this issue very soon #and myself still documenting the various issues, will come with a beter solution #Thank you Jason A. Donenfeld
knownIP="/etc/KnownIP"
touch $knownIP
actualip=$(ping -4c1 LAST-Z.NET | sed -nE 's/^PING[^(]+(([^)]+)).*/\1/p')
comparizon=$(cat $knownIP)
if [ "$actualip" != "$comparizon" ]
then echo "LAST-Z.NET ip has been updated!"
ifdown wg0
ifdown wan
/etc/init.d/network reload
/etc/init.d/firewall reload
ifup wan
ifup wg0
logger -s "LAST-Z.NET ip was updated! Were $comparizon is now $actualip"
rm -f $knownIP
echo $actualip >> $knownIP
else echo "ip still as previously known and was not changed"
break
fi
#Save this file somewhere on your openwrt router #execute 'chmod u+x' on it #Add it to your: LUCI > System > Schedule Task #to run every 5 or 10 minutes #with help here: https://crontab.guru #End of Script
Updated Illustration with missing info and watchdog script additions.
Confirm working, survive reboots, survive IP changes, survive power cuts, survive exroot cloning for other routers, survive reconfiguration of LAN ip, survive wg key reset and reupdated.
less pervasive watchdog script evolving for multiple peer setup,
working peers stays connected while updated ip of other peers are updated
will update here when confirm working on all routers in my possession, actually working right on some routers but not for some others
wireguard_watchdog is working perfectly fine, and what's more important, works within the OpenWrt UCI/ubus environment. If I had to hazard a guess as to why wireguard_watchdog would not work for you I'd say it's because of your "unusual" way to hop the firewall through bilateral UDP "holepunching". I still consider that a dirty hack to begin with.
Your cobbled together wireguard watchdog alternative only works on a single, hardcoded Wireguard interface, unnecessarily restarts the WAN interface, then restarts it again (by restarting network), then restarts the firewall (which has already been reloaded twice at this point). A dirty hack on top of a dirty hack. Sticky tape and chewing gum.
If all of this works for you, fine, more power to you. I'm not judging, I've certainly done my own fair share of solutions that "work for me". But please don't recommend your hacks to others who might look for a real, sustainable solution.
thx for your fair share.
I im not recommending what you consider my dirty chewing gum over post-it hack.
If im in the forum seeking solutions and sharing my solutions to my issues is because I am having trouble to get the available existing solutions to work with my setup and on my routers.
Not all routers are equal, just by going through the lines in the forum anyone will understand that.
Networking is so vast that theres no "one setup fit all".
If my sharing is causing harm to existing solutions, and causing harm to those who come up to the existing solutions. Then if there is an admin around please redflag me or just bann me from the forum.
Anyway if im not banned and if anyone is in such trouble as me with a similar basic and simple vpn setup as mine, they are welcome to ask any questions, I will help as far as I can.
Also if the available script: https://lists.zx2c4.com/pipermail/wireguard/2018-June/003000.html is not working for you for whatever reasons, a known working multiple peer watchdog script is also available, just ask if needed. Tested on various TP-Links, Netgear routers and Debian virtual machines.
True. But there is an "ideal way that works for most" and "a hacky way that works for a few in certain circumstances." You are advocating the latter.
That's overly dramatic. I've never encountered that to happen to anyone with good intentions, and certainly would not accuse you of the opposite.
Granted, your setup is not incredibly elaborate. I would even argue that Wireguard itself favors simplicity. But your whole setup is neither basic nor simple. One side of your setup is doing triple NAT duty, and the whole diagram reads more complicated than Donald Trump's healthcare plan.
Oh, did you copy that mailing list entry into a shell script verbatim? If so, of course it doesn't work, it has line breaks where there shouldn't be any. The actual script comes with the wireguard-tools package and then resides in /usr/bin/wireguard_watchdog ready to use.
I'm not trying to be mean, I really am not. Anyone is welcome to share and increase knowledge (and I learnt something over the course of this thread, so I certainly cannot argue that you are not doing that). All I am asking is that you please not sell band-aid solutions as best practices.
Wireguard choosing here is mainly due to the triple and quadruple NAT in the setups being configured.
watchdog not working on X routers will take too much time to document and solve on a per router basis and might require custom package builds and will be an additional burden for deployment, redeployment, and upgrade later on.
I am better with a more straight fwd basic configs watchdog settings which im sure will work across the various routers to be configured and will be easily troubleshoot by the various openwrt illiterate guyz who might come to troubleshoot issues later.
hopefully those words will help you remove the chewing gums on top of the sticky notes stuck on top of the dirty hack!
I am not sure if I get what you are saying, and whether you are arguing for or against my point. At any rate, the watchdog script (again, the one supplied with wireguard-tools, not a copy&paste job) really isn't very complicated to begin with. I believe it would be prudent to examine why it does not work, instead of knitting workarounds from scratch that ultimately only help one person for one specific case.
Here's an olive branch: If you, for whatever reason, can't do it yourself, let me help you insert some debug output and we can try to find the issue together.
no argue. neither for nor against. Im not saying that the watchdog does not work or is not good, It just does not work with the routers available here.
Seems to have work only on a 1043nd but for 2 WAN ip changes only.
To me = unreliable
When i will have better productive and less buzy time I will look into it. by then I wish your olive branch will be transformed into a bamboo tree
To any admin reading, please review the available wireguard_watchdog as important function is missing in it as it is actually: To check and counter verify the actual IP of endpoint host and resolve it!
No DNS flushing occuring and neither pinging outside to force resolve to the corect updated IP.
Now while looking at it I understand why it is not working
here an actual copy of what I have on my system @ 21/08/2018 @ 21h15GMT:
~# cat /usr/bin/wireguard_watchdog
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
#
# Copyright (C) 2018 Aleksandr V. Piskunov <aleksandr.v.piskunov@gmail.com>.
# Copyright (C) 2015-2018 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
#
# This watchdog script tries to re-resolve hostnames for inactive WireGuard peers.
# Use it for peers with a frequently changing dynamic IP.
# persistent_keepalive must be set, recommended value is 25 seconds.
#
# Run this script from cron every minute:
# echo '* * * * * /usr/bin/wireguard_watchdog' >> /etc/crontabs/root
. /lib/functions.sh
check_peer_activity() {
local cfg=$1
local iface=$2
local public_key
local endpoint_host
local endpoint_port
local persistent_keepalive
local last_handshake
local idle_seconds
config_get public_key "${cfg}" "public_key"
config_get endpoint_host "${cfg}" "endpoint_host"
config_get endpoint_port "${cfg}" "endpoint_port"
persistent_keepalive=`wg show ${iface} persistent-keepalive | grep ${public_key} | awk '{print $2}'`
# only process peers with endpoints and keepalive set
[ -z ${endpoint_host} ] && return 0;
[ -z ${persistent_keepalive} -o ${persistent_keepalive} = "off" ] && return 0;
# skip IP addresses
# check taken from packages/net/ddns-scripts/files/dynamic_dns_functions.sh
local IPV4_REGEX="[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}"
local IPV6_REGEX="\(\([0-9A-Fa-f]\{1,4\}:\)\{1,\}\)\(\([0-9A-Fa-f]\{1,4\}\)\{0,1\}\)\(\(:[0-9A-Fa-f]\{1,4\}\)\{1,\}\)"
local IPV4=$(echo ${endpoint_host} | grep -m 1 -o "$IPV4_REGEX$") # do not detect ip in 0.0.0.0.example.com
local IPV6=$(echo ${endpoint_host} | grep -m 1 -o "$IPV6_REGEX")
[ -n "${IPV4}" -o -n "${IPV6}" ] && return 0;
# re-resolve endpoint hostname if not responding for too long
last_handshake=`wg show ${iface} latest-handshakes | grep ${public_key} | awk '{print $2}'`
[ -z ${last_handshake} ] && return 0;
idle_seconds=$((`date +%s`-${last_handshake}))
[ ${idle_seconds} -lt 150 ] && return 0;
logger -t "wireguard_monitor" "${iface} endpoint ${endpoint_host}:${endpoint_port} is not responding for ${idle_seconds} seconds, trying to re-resolve hostname"
wg set ${iface} peer ${public_key} endpoint "${endpoint_host}:${endpoint_port}"
}
# query ubus for all active wireguard interfaces
wg_ifaces=`ubus -S call network.interface dump | jsonfilter -e '@.interface[@.up=true]' | jsonfilter -a -e '@[@.proto="wireguard"].interface' | tr "\n" " "`
# check every peer in every active wireguard interface
config_load network
for iface in $wg_ifaces; do
config_foreach check_peer_activity "wireguard_${iface}" "${iface}"
done
It doesn't have to. It doesn't rely on ping or DNS to check whether Wireguard needs to be restarted, instead it checks how far back the last successful handshake occurred. If it is more than 150 seconds in the past
wg set ${iface} peer ${public_key} endpoint "${endpoint_host}:${endpoint_port}"
it tells Wireguard to reconnect. Wireguard itself then freshly resolves the host.
yep depict all the lines with a more broad view you will understand.
How to know you are who you say you are.
I think no much users use wireguard on openwrt yet, since I asked for help I barely received any here.
Mostly all help acquired comes from elsewhere. Openwrt wiki + other forums and myself!
Thank you!
Yep im done
Just to note, only routers where the supplied watchdog works, the 1043 have an old pen exroot setup never swap since installed but system upgraded and working well.
as u said above "wireguard_watchdog is working perfectly fine"
I further look into it…
issues with current exroot setup with ddns opkg and various other files.
So the issue is on my side with other routers. Still cleaning some issues n replacing drives. But good so far.
My customs script working, when time allow I will provision solution to the various other dns issues I personally encounter since long and will post the script later on for the forum
