Resolution of dynDNS - Wireguard site-to-site

[chemlud]

Hi again!

Have a Wireguard End Point configured with a dynDNS address, no problem on first start of WG, connection up and running.

But if the IP underlying the dynDNS changes, WG apparently doesn't resolve the dynDNS address at all, the tunnel never (10 min or so) came back until I opened the respective End Point tab in the GUI and pressed "Save" (without changing everything). Subsequently the dynDNS was correctly resolved and the tunnel came up immediately.

So my question: Is there no mechanism to make WG resolve the dynDNS automatically if the handshake does not succeed?

[mimugmail]

No, you have to restart WireGuard since it resolves the name only on startup (I guess)

[mimugmail]

But when only one site has a dynamic IP you can also leave endpoint address empty and do fast keepalives.

[chemlud]

But when only one site has a dynamic IP you can also leave endpoint address empty and do fast keepalives.

How to do that?

Or is it easier to have a script restarting WG if no handshake?

In my opinion missing resolution on lacko fo handshake is a bug, or?

[mimugmail]

A lack of something isn't a bug
You can open a discussion on Wireguard mailing list how to better handle this.

You can set keepalives in endpoint config, just use 5 seconds or so, should be stable enough.

[chemlud]

If the connection of a VPN is lost due to change of IP of an endpoint, openVPN and IPsec would consider that a bug. Or OPNsense, maybe? ;-)

Are there any drawbacks of keeping the end point IP empty? :-)

[mimugmail]

Only If both sides are dynamic

[lfirewall1243]

Is that feature on the Roadmap for Wireguard?

[mimugmail]

No, on startup it trys to resolv the name and thats it.
Wireguard is not a daemon, there is no process for looking up a dns name

[hockey6611]

I hope its not too offensive to resurrect this thread. I found this topic after have the same issue with two dynamic opnsense endpoints for a site to site tunnel.

pfsense has implemented a solution to this with their do-over wireguard implementation. Hopefully opnsense would be willing to do something similar. Here is the developer discussing this feature and how it works: https://www.youtube.com/watch?v=kI3xoSGMRuU&start=566&end=907

Has anyone found any other solution for this? One of my dynamic endpoints is remote, so restarting the tunnel is inconvenient when the dynamic IP changes, and the tunnel drops.

[Greelan]

The solution is in the video - set up a cron job to run the wg-tools script. pfSense hasn’t created its own solution - they have just enabled this to be done via the GUI directly, rather than through a cron job. (The current pfSense “development” is just for a plugin that sits on top of the wg packages and provides the GUI frontend; the WG developers are doing all the hard work on actually developing WG, and particularly the kernel module, for FreeBSD.)

All that said, there is nothing to stop you raising a GitHub feature request in the OPNsense plugins repo to ask for this to be added to the OPNsense GUI too.

[hockey6611]

Thank you for the feedback and suggestion. I may raise a request for this in the GUI. However, I like to also try running a cron task for this as well. I'm stuck pretty early on. I cannot find where the wireguard-tools script reresolve-dns.sh would be installed in opnsense?

[Greelan]

Maybe it’s not, unless the git repo is cloned directly. Just cut and paste it yourself?

[hockey6611]

Thanks for the suggestion! I was trying not to complicate things too much. But I was able to get this working, here were my general steps for anyone finding this topic:

• Copied https://git.zx2c4.com/wireguard-tools/tree/contrib/reresolve-dns/reresolve-dns.sh to a new directory: /usr/local/manualwgtools/reresolve-dns.sh
• followed this guide to add a cron task: https://forum.opnsense.org/index.php?topic=2263.msg8504#msg8504
• Using command: bash /usr/local/manualwgtools/reresolve-dns.sh /usr/local/etc/wireguard/wg1.conf
• set cron task in GUI

[Greelan]

Nice. Be interested to hear how it goes

BTW, this post may be useful in terms of suggestions for script locations: https://forum.opnsense.org/index.php?topic=18865.msg86224#msg86224

Also, may be more robust to have the full path to bash in the command?

Still suggest you raise a GH request. Would obviously be simpler for this to be managed in the GUI, either per endpoint or as a general setting