WireGuard not starting correctly after reboot

[hfvk]

There's also a DNS renew cron job for WireGuard to use... "Renew DNS for WireGuard on stale connections".

It's even more ironic than you might realise, because it is a Python rewrite of

https://github.com/WireGuard/wireguard-tools/tree/master/contrib/reresolve-dns

"Run this script from cron every thirty seconds or so, and it will ensure
that if, when using a dynamic DNS service, the DNS entry for a hosts
changes, the kernel will get the update to the DNS entry."

So the author of WireGuard recommends attempting to renew your DNS every 30 seconds.

You know why?

Because Kernel doesn't do DNS and all you do when configuring WireGuard (or any other tunnel using ifconfig) using a FQDN/hostname the tool will try to resolve it once and only the IP address is ever stored in the kernel, which makes it impossible for the kernel to renew the DNS.


Cheers,
Franco

In my case, this cron job has been enabled for a long time - and it was already enabled when I observed this change in behavior when upgraded from 25.7.11 to 26.1.3.

So, on 25.7.11:
"Renew DNS for WireGuard on stale connections" --> was enabled and run periodically
No issues when restarting firewall.

On 26.1.3:
"Renew DNS for WireGuard on stale connections" --> was enabled and run periodically
WireGuard did not start on reboot due to DNS resolve issues
--> delayed restart after reboot (60 seconds) --> WireGuard starts as expected.

I was happy enough to get it up and running with delayed restart after reboot so I didn't really investigate this further. However, noticed the change in the behavior although "Renew DNS for WireGuard on stale connections" has been enabled all the time.

[franco]

Ok fair so what happens when /usr/local/opnsense/scripts/wireguard/reresolve-dns.py is manually invoked without the workaround in place?


Cheers,
Franco

[hfvk]

Ok fair so what happens when /usr/local/opnsense/scripts/wireguard/reresolve-dns.py is manually invoked without the workaround in place?


Cheers,
Franco

I will put this on my TODO list for the next maintenance period. All systems are now running and everything is OK but I will investigate this with my test setup when preparing for the next round of updates etc. I will test this before applying any updates just to confirm that we have a clear reference point.

[hfvk]

Ok fair so what happens when /usr/local/opnsense/scripts/wireguard/reresolve-dns.py is manually invoked without the workaround in place?


Cheers,
Franco

OK, tested this now on OPNsense 26.1.6-amd64

Wireguard site-to-site setup.

Router A has router B configured as a peer and endpoint address is a FQDN.
Router B has router A configured as a peer and endpoint address is a FQDN.

"Renew DNS for WireGuard on stale connections" --> is enabled and run periodically
--> cron entry: enabled * * * * * "Renew DNS for WireGuard on stale connections"

Step 1: disabled the workaround on both site-to-site routers (A and B)
--> workaround was the delayed restart (60 second delay) of Wireguard after system bootup to ensure that DNS is working when tunnel is restarted.
--> site-to-site tunnel is working at this point

Step 2: restart router A
--> wireguard tunnel starts properly as router A boots up
--> note that router B has not been restarted

Step 3: restart router B
--> wireguard site-to-site tunnel won't start on router B due to DNS resolve issues (Name does not resolve).
--> site-to-site tunnel is down

Step 4: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router B
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 5: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router A
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 6: restart Wireguard S2S on router A
--> tunnel is still down

Step 7: restart Wireguard S2S on router B
--> tunnel comes up and traffic flows

Any ideas how to debug this further?

[hfvk]

Ok fair so what happens when /usr/local/opnsense/scripts/wireguard/reresolve-dns.py is manually invoked without the workaround in place?


Cheers,
Franco

OK, tested this now on OPNsense 26.1.6-amd64

Wireguard site-to-site setup.

Router A has router B configured as a peer and endpoint address is a FQDN.
Router B has router A configured as a peer and endpoint address is a FQDN.

"Renew DNS for WireGuard on stale connections" --> is enabled and run periodically
--> cron entry: enabled * * * * * "Renew DNS for WireGuard on stale connections"

Step 1: disabled the workaround on both site-to-site routers (A and B)
--> workaround was the delayed restart (60 second delay) of Wireguard after system bootup to ensure that DNS is working when tunnel is restarted.
--> site-to-site tunnel is working at this point

Step 2: restart router A
--> wireguard tunnel starts properly as router A boots up
--> note that router B has not been restarted

Step 3: restart router B
--> wireguard site-to-site tunnel won't start on router B due to DNS resolve issues (Name does not resolve).
--> site-to-site tunnel is down

Step 4: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router B
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 5: manually invoke /usr/local/opnsense/scripts/wireguard/reresolve-dns.py on router A
--> tunnel is still down
--> no feedback from CLI and no log entry in Wireguard log

Step 6: restart Wireguard S2S on router A
--> tunnel is still down

Step 7: restart Wireguard S2S on router B
--> tunnel comes up and traffic flows

Any ideas how to debug this further?

I just tested this on OPNsense 26.1.7-amd64 as well. The behavior is exactly the same. The only way to get the tunnel online after rourter B restart is either
1) setup a script to perform delayed tunnel restart on router B after startup or
2) manually restart the tunnel on router B