WireGuard not starting correctly after reboot

[cds]

Hi there,

since some time I noticed a strange behaviour:

On every reboot WireGuard does not start up correctly - even the log claims it does. None of the Tunnels are working. 100% reproducible.

When I then have to dis-activate and re-activate Wireguard once -> working stable until next reboot.

The WireGuard log does not give any clue, everything looks usual.

Any hints?

[Patrick M. Hausen]

Are you using WG to establish outbound tunnels from OPNsense or is OPNsense providing WG for other systens to "dial in"?

If the former, are you using host names (FQDNs) for the peers? Can you use IP addresses instead?

[cds]

It is configured both ways. Which ever side is first establishes the tunnel.

Using the IP for the clients is not an option sue to dynamic IPs.

[chemlud]

Have some WG tunnels on OPNsense, only one install, one tunnel does not come back after reboot since some weeks.

Mostly I have to obtain a fresh WAN IP to make this tunnel come back. Yesterday this tunnel went down at 14:08 without any obvious reason, Only wayto make it re-connect was to obtain a fresh IP for WAN.

Makes no sense at all. Devs will say: Wrong config, will break some day. But worked fine for years, have other tunnels configured same way, rock-solid and comming back after each and every reboot.

[cds]

Did some more testing:
changing from FDQN to IP does not change anything.

But I made one additional observation:

After reboot, I get log-entries like

/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </usr/bin/wg syncconf 'wg3' '/usr/local/etc/wireguard/wg3.conf'> returned exit code 1 and the output was "Name does not resolve: `xx.yyy.de:51820' Configuration parsing error"


I would be fine with a comment like "wrong config" if someone could tell me what is wrong all the sudden and how to correct ...

[FredFresh]

Can you confirm if for you it is the peer or the gateway that is marked offline?

[franco]

> Devs will say: Wrong config, will break some day.

No, but what we're saying is:

> "Name does not resolve: `xx.yyy.de:51820'

That's a DNS error. No dev can reasonable resolve xx.yyy.de for you.


Cheers,
Franco

[chemlud]

OK, x tunnels, all WG with DynDNS, of which x-1 come up normally after opnsense reboot, while 1 tunnel doesn't, restarting WG instance, dis-/enabling does nothing to bring the tunnel up, as does any operation you can imagine on the remote WG instance.

But obtaining a fresh WAN IP on opnsense brings up this tunnel.

All the tunnels up and running for 5+ years, problem started some weeks ago.

What to make out of this?

As written somewhere else: This very same tunnel went down at a random time of day recently, again only a fresh WAN IP could recover the tunnel. No other operation.

[franco]

You can try the support offering we have which fits this problem scope. Assuming everyone suffers from a low quality integration/implementation isn't helpful. It's also not how this integration/implementation is going to improve without constructing the actual problem in a way it makes sense with the code at hand.


Cheers,
Franco

[os914964619]

I started seeing the same exact issue as you that started happening on all my routers. Some regression was introduced in the previous release (26.1.6) or the one before that (26.1.5). I don't know which one it was because 26.1.5 didn't require a reboot so that could have been the culprit but I don't know because I didn't reboot. I only had to reboot after applying 26.1.6, and it started happening on all my routers after that reboot.

https://forum.opnsense.org/index.php?topic=51578.msg

Other people have reported it as well:

https://forum.opnsense.org/index.php?topic=50748.msg
https://forum.opnsense.org/index.php?topic=32232.msg

And if you do a search, there's many, many, more older posts with the same problem.

I'm not sure what changed in the last month or two, but I have never changed my configuration or had this issue up until I applied two updates and then rebooted.

So the issue is either a regression in 26.1.5 or 26.1.6

[franco]

All I can see from these reports is that DNS resolution isn't working when the tunnel is supposed to come up (if the message is actually the error to look into and not a cosmetic oddity as it could be restarted later anyway). A reboot is also the most likely point DNS resolution isn't up and running yet or is worst case routed through a tunnel that isn't up yet.


Cheers,
Franco