Wireguard problem with resolving peer

Hi
I have a wireguard connection set up to a NAS at my brothers house. He has a FritzBox with a dynamic DNS with myfritz.net. This works well so far.

But his ISP disconnects him once per day in the early morning hours and assigns him a new IP-address.

The wireguard in OpenWrt resolves the IP only of the peer when the interface comes up, ... so after at least one day the connection is broken and I need to reconnect the interface manually.
Is there a way to work around this? Maybe with a cron based restart of the interface?

Dynamic IP addresses

Many users report having to restart WireGuard whenever a dynamic IP changes, as it only resolves hostnames on startup. To force WireGuard to re-resolve dynamic DNS Endpoint hostnames more often, you may want to use a PostUp hook to restart Wireguard every few minutes or hours.

1 Like

There is a "wireguard-watchdog" script exactly for that purpose. It is part of wireguard-tools, usage is described in the commit message.

Called via a cronjob (documentation recommends every minute) it checks all wireguard connections for their last handshake, and if it is more than 150 seconds in the past, re-initializes the respective connection ... which also includes a new lookup. (And I can personally attest that it works perfectly.)

While this would work, it is a rather blunt instrument, interrupting all Wireguard connections even if they are perfectly fine and currently transferring data. "Every few minutes" is an especially curious suggestion that would result in one never being able to hold a download for more than a few minutes.

5 Likes

Per past excellent advice from @takimata, I added this to my scheduled tasks, in order to solve the same issue you're having:

*/15 * * * * /usr/bin/wireguard_watchdog

This will resolve the hostname of the endpoint - every 15 minutes.

The watchdog script is extremely lightweight, it just checks the 'last handshake' values of the output of wg show. There's no real reason to restrict it to every 15 minutes and wait that long for the connection to come back, every minute really is fine and creates no perceivable overhead.

4 Likes

I go for the watchdog script. Thank you.

I really would like to have this with an option in the wireguard luci interface. :wink:

Also: whenever the peer gets a new IP (and when I restart the interface), this IP is added to the routes ...

This get's me growing list. It seems the wireguard is not only adding the allowed addresses but alos the resolved peer address to routes table. Is this neccessary?

Yes, otherwise the router would use the VPN to reach the endpoint IP (chicken-or-the-egg problem). It must have a route to use the unencrypted WAN.

But doesn't this only apply if the peer address is part of the routed networks, e.g. if 0.0.0.0 is routed? If I have only two networks in 192.168.xx in allowed ips, the route to the peer address shouldn't be neccessary? Or am I missing something?

You're missing something. The router always needs to know the route to the other VPN endpoint, regardless if one (/32), or 4 billion (i.e. 0.0.0.0/0) other IPs reside there.

Ok

that did not work ... I get this in my System Log:

Thu Jul 18 16:30:00 2019 cron.info crond[1853]: USER root pid 6384 cmd /usr/bin/wireguard_watchdog

every 15 minutes, but no update on the remote address of the peer (and no entry in the routing table).
I still have to restart the interface manually ...

Again, 15 minutes is excessive, you can/should run it every minute. If you run wireguard_watchdog every 15 minutes, math suggests that you could in extreme cases wait more than 17 minutes until the watchdog can actually react.

Do you have persistent_keepalive set, to the recommended value of 25 seconds?

What does wg show say about latest handshake after the remote address changes? The peers should say something like this:

  latest handshake: 1 minute, 16 seconds ago
  persistent keepalive: every 25 seconds

A healthy connection should never go beyond 2 minutes and some spare change on the latest handshake. wireguard_watchdog should, when it runs, recreate all connections exceeding 150 seconds.

Ok, so the persistent_keep_alive migth be the problem.
As I need the connection only once a week for the offsite backup, it would be absolutely sufficiant to have it connecting on this time (and it connects automatically if needed and peer ip is known).
No way to update the peer ip without having the connection always on?

Wireguard doesn't have a concept of "always on." Remove the keep alive time on both ends to make it an "on demand" connection.

Yes, I know that. And that's how the connection to my brother network has been set up.

The problem is, that the resolving of the changed peer ip with the watchdog script seems to need the keep alive .. (as far as I understood).

So I can' t have both: resolving peer ip changes and not having always on connection.
Correct?

If you want wireguard_watchdog to work, correct. Just a quick note, though: A WireGuard connection with regular handshakes (as you call it, "always on") just uses a few kilobytes a day. Unless (and probably even if) you are using a '90s modem dialup line it really does not have any sort of impact to have it "always on."

3 Likes