On Fri, Jan 5, 2024 at 10:45 AM Christof Hanke wrote:

as far as I remember reresolve-dns.sh was never part of the rpm. If you use the "PersistentKeepAlive" option, your tunnel should survive. If both IPs change simultaneously, then you need the re-resolve-script, I guess.

i checked the tunnel today and no traffic was passing through. I also checked the router logs when the broadbad on both sides has possibly changed its addresses, and it was like an hour or so apart, so it should have survived by re-establishing the still known valid side from one side or the other whichever side one would look into it from? too bad it didnt though or I have yet to understand how wg sets up the endpoint stuff exactly? my wg0.conf files has endpoint hostnames (dynamic dns provider) on both sides. a ddclient service (systemd) run on both ends, both leap 15.5 that gets updated to the newly changed public ipv4 within 5minutes or so upon ipv4 change. the tunnel still wasnt valid and working any more until I wg-quick down wg0 and wg-quick up wg0 on both sides of the tunnel, on both leap 15.5 machines. I somewhere once? read that the wg scripts and what not resolve the endpoint hostname exactly once into a then-valid ip address and use that as the actual config and network layer or so. But does it not update or amend or modify the actual ip address into the more-current ip address due to the flow of proper and security-authenticated packets still coming in from the still unchanged side of the wg tunnel? that was my understanding from consulting some discussions or documentations and theory in the past. apparently something is more complex or it doesnt actually work this way? i wish it would be simpler. I have not yet made use of systemd to create a service? for the wg0 stuff on both sides, I only use wg-quick just yet. how would I then use this script? also from yet another systemd service to be running it from? or via some simpler crontab or something? thanks for all the input and hints. ty

On 09.01.2024 20:10, cagsm wrote:

anyhow where would i put that script on an opensuse leap 15.5 actually to be able to run it as a service

It does not matter as long as you use the full pathname to this script in the service definition.

On Wed, Jan 10, 2024 at 11:01 AM cagsm wrote:

now I am trying to connect two networks site to site situation, but something about the routes stuff, is still not set up, and yast system settings about networking and route and its gui is confusing to me i have not yet come to terms with

learning the hard way or noob but progressing a bit every now and then, I figured, yast2 firewall stuff needs to assign a zone of type "trusted" to the wg0 interface on both site locations (on opensuse leap 15.5 boxes on both sides) otherwise it would pass some ping but no tcp connect. now I can connect from one side to the other so far, e.g. surfing a local printer webinterface (tcp/80) on the e.g. right side. the right side network has the leap 15.5 box there as default gateway so I guess that is a simple stuff. so far so good. i can not access the left side network from the right side though, except for pings so far, traceroutes, unfortunately the suse 15.5 box on the left side is not the default gatway there, but the actual default gateway on the left side LAN has the route (to the right side LAN network) set and pointing to the suse 15.5 box on the left side place. will see if I can deduct more from this current situation. ty.

On Tue, Jan 9, 2024 at 6:23 PM Andrei Borzenkov wrote:

It does not matter as long as you use the full pathname to this script in the service definition.

revisiting this issue, trying to really actually run such a reresolve sh script (bash), but i dont see the endpoint actually being updates through a call of the wg tool. I have checked by shutting down the wg service on the distant side of my situation here (having two places connecting each other via wg) and dynamicdns hostnames (fully qualified domain name in endpoint) i observe the dyndns hostname changing after re-triggering the internet connection on the distant side, updating. but sudo wg show still shows the old dynamic dns ip address on the endpoint output even after many minutes and after an hour still. i would like to debug this situation to detect whats really going on, also I even asked chatgpt (i am a noob :( ) to explain me exactly where and what statement in that bash file does the actual lookup for the domain name, as I find it hard to understand. chatgpt only hallucinates? about awk and host -t ... and getent ahosts host..... but I dont find all these expressions in this bash file from the contrib/reresolve of the wireguard project. unfortunately opensuse doesnt come with this pretty essential? contribution script to make this work for dynamically changing ip addresses on hostnames for endpoints. so: took this as raw:

https://github.com/WireGuard/wireguard-tools/blob/master/contrib/reresolve-d...

put this into e.g.

/usr/local/bin/share/doc/wireguard-tools/examples/reresolve-dns/

as a file, added root users executable flag (chmod) and acted accordingly to

https://techoverflow.net/2021/08/19/how-to-automatically-re-resolve-dns-in-w...

the manual way.... I have the .timer file and the .service file put into place

/etc/systemd/system/wg-reresolve-dns@.timer /etc/systemd/system/wg-reresolve-dns@.service

the timer becomes active I can check its state and it calls reguarily the .service file and it seems okay, journalctl shows entries (a lot) for the .timer and for the .service the config file for wireguard is wg0.conf all right in /etc/wireguard/ everything seems simple How would I debug this stuff to actually see how this wg set line gets called and what content of the hostname gets set?

https://github.com/WireGuard/wireguard-tools/blob/13f4ac4cb74b5a833fa7f825ba...

and more importantly I would like to understand where and how that bash script? or what part does actually resolve the dns name of my changing dyndns stuff any hints on how to narrow this? thank you so much for making me learn. would gladly have this contrib script in the official wireguard of opensuse leap? thanks!

On Fri, Apr 12, 2024 at 10:55 AM Andrei Borzenkov wrote:

You can always add set -x at the top and get a complete execution trace.

in the bash script?

...

...

https://github.com/WireGuard/wireguard-tools/blob/13f4ac4cb74b5a833fa7f825ba... and more importantly I would like to understand where and how that bash script? or what part does actually resolve the dns name of my changing dyndns stuff It does not. "wg set ... endpoint $ENDPONT" does DNS lookup on the $ENDPOINT value. Did you check what address

okay so that actual line with the variable $ENDPOINT then takes my dyndns hostname from the wg0.conf file and does then at the moment of that call do a dns lookup and thus then takes the then-current value and sets it as endpoint, right?

ping your.dns.name is using? Does it change when your address changes? Does it match what you see in "wg show" output?

no it doesnt match, as I have stated. I am logged into the one machine (opensuse, ssh) and i check there. the commands e.g. host and nslookup my-dyndns-hostname eventually changes within a few minutes after the machine on the far side has reestablished into the internet and updates (ddclient) the hostname. so the essential basic steps are all in place. I can also reach both places via ssh and their then current ip addresses obviously. these fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show, the old address of the other distant side, the old ip address of the dyndns hostname of the distant side, even though at the same time a resolve on the ssh/bash/terminal already shows that it can and does resolve the updated dyndns hostname properly and that this ip address has changed etc. I like waited for an hour in this situation just to be patient. then i issued a systemctl restart wg-quick@wg0.service (or so) and it immediately updates the resolved hostname in the endpoint (wg show) to the proper current updated dyndns hostname of the far side. no actual connection will be established, as I have stated above, I did shut down the far side (other machine) wg tunnel. when I then restart the wg service on the far side machine as well, the whole tunnel comes alive. thats how I try to diagnose and narrow things down. i want to get this re-resolve stuff working. apparently somethings amiss here on opensuse leap 15.5 thanks for helping.

On Fri, Apr 12, 2024 at 1:50 PM cagsm wrote:

fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show,

Was this tunnel ever active? Post wg show wg show latest-handshake

On Fri, Apr 12, 2024 at 1:19 PM Andrei Borzenkov wrote:

On Fri, Apr 12, 2024 at 2:15 PM Andrei Borzenkov wrote:

...

On Fri, Apr 12, 2024 at 1:50 PM cagsm wrote:

...

fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show, Was this tunnel ever active? Post

yes the tunnel as is works fine. I just want to make it more robust in case both sides both parties on their ISPs go down similarly to each other and fail to have current dyndns hostnames just yet before being able to continue receiving packets from the other side (and sending into nirvana) when both sides change ip addresses close in time.

...

wg show wg show latest-handshake Scratch it. The script is using $EPOCHSECONDS and it is not defined in Leap 15.5 bash. Use $(date +%s) instead

I guess i copied the most current version of that script as far as I have seen there is also a mention about epoch commit stuff at

https://git.zx2c4.com/wireguard-tools/log/?qt=grep&q=epoch

they did have you variation in that script before:

https://git.zx2c4.com/wireguard-tools/commit/?id=1fd95708391088742c139010cc6...

thanks a great deal. will try if this brings any progress. ty.