Wireguard issue(s)

[Dark-Sider]

Hi,

since wireguard made its way into opnsense it works ok-ish for however its "stability" is not comparable to OpenVPN. However I like the concept behind wireguard therefore I'm putting up with some issues and still using it.

Last week I had to restart my opnSense box (25.1.12) and me being away on a business trip, wireguard failed me (again) after the restart. I usually solve this issue by de- and reactivating my one and only wg0 instance via the webgui. After restarting wg0 everything works as it is supposed to.

Since the issue caught me cold (again) I did some forum reading and found interesting threads regarding wg and DNS, stale connections etc:
https://forum.opnsense.org/index.php?topic=49432.0
https://forum.opnsense.org/index.php?topic=37905.0
https://forum.opnsense.org/index.php?topic=42648.0

Honestly I didn't know about the quirks of wg and DNS resolve issues after your dynamic IP refreshes or wg only doing DNS queries once on startup and not refreshing it. One might argue that using a static ip would solve such problems, however static IPs on consumer lines are hard to get these days. Even IPv6 is dynamic with my ISP.

While I think wg's behaviour is a severe design oversight in the protocol / moudule (nothing related to opnsense though) I appreciate the effort that a cron job exists that somewhat is supposed to fix the issue.

I activated the cron-job to run */5 * * * * however my issue was not resolved. My mobile phone was not able to connect via IPv6 or IPv4 (both usually works) to my opnSense box. I did a packet capture on 51820 and the packets from phone arrived but no response was sent back.

I then noticed there is another cron-job called "restart wireguard service" I also did setup this job */7 * * * * however after waiting for 14 minutes my wireguard log still showed that the service was started last week - no other log entries.

While looking at the logs I found that the wg status page was quite empty, only showing wg0 with my local endpoint at port 33###. Didn't notice this first, but my wg setup uses only port 51820. Also no peers were shown at all on the status page.

I have 3 road warrior peers configured ("dial in only") being my phone, my laptop and a mobile gl_inet travel router. I also have a site2site connection configured to a remote network.

Only after I deactivate my Instance and reactivate it, all 4 peers will be listed on the status page. When the peers are listed the connections start working again.

My openSense runs virtualized (yes it could need a firmware update which I will do later) and is on a dial up connection at a German ISP (M-Net) using both IPv4 and IPv6 connectivity via pppoe. Luckily my ISP-connection is hyper-stable so reboots and disconnects thus ip-changes happen very rarely.

I still wonder why wg needs a kick in the... after my box boots up? And shouldn't that restart wg cron-job also fix my issue?

thanks,
Dark-Sider

[Monviech (Cedrik)]

If your connection via wireguard is inbound, it means that your devices resolve the DNS entry. On your OPNsense, I would not expect any hostname in the configuration, wireguard just binds to all interfaces (* 51820).

So I assume your clients resolve the wrong IP address and send packets to the wrong destination.

[meyergru]

Hi Fabian, I think the problem is the road warriors (as they do not notice the IP change of your server).

I wrote the stale connection job and of course, it only does half of the job...

Wireguard is inherently symmetrical, such that when a potential connection exist, both peers will send handhakes. If one side changes its IP, the other side will lose contact, but it can still try to reach the other side - this is normally true with a site-2-site connection, including new DNS resolution.

Thus, it is usually beneficial if one side (the server, so to speak) has a fixed IP, because it will always come up on that IP and can be reached regardless. The cron job fixes a lot of thing when both site-2-site partnes are behind dynamic IPs and both use the job. In that case, regardless of who is changing its IP, the other side will notice that the last handhake was older than 135 seconds and re-initiate the connection.

This can take a while, depending on how fast the DynDNS updates are and may be neccessary multiple times.


In your scenario, with a road warrior, the cron job on the "server" side does not help at all, because the road warrior peer has to initiate a new connection. If he fails to notice the stale connection, it will never restart and thus the DynDNS update will go unnoticed.

Luckily, for M-Net, there is a fix to that: They usually do not change their IPv6 prefix on reconnection, much unlike the IPv4. Thus, if you use IPv6 only or IPv6 and IPv4 in your DynDNS, it will effectively work as if you have a fixed IP(v6). In that case, your roadwarrior clients will regain contact within the same Wireguard session.

Call me any time if you have questions, you have my number!

[Bob.Dig]

For Android there is "WG Tunnel", that can cope with dynamic IPs. If your resolution is to restart WG on OPNsens though, you might have another problem und upgrading OPNsense is strongly advised to begin with.