[Networkmanager] Wireguard and IPv6&IPv4 dual stack endpoint with roaming clients from IPv6&IPv4 → IPv4 only networks

[Thomas Haller]

On Wed, 2023-03-01 at 10:19 +0000, Samuel Le Thiec wrote:
> 
> Hello,
> 
> I'm facing a quite annoying problem with wireguard with
> NetworkManager.
> 
> After
> reading https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-netwo
> rkmanager/
> 
> > *Dynamically Resolving Endpoints*
> > In WireGuard, peers may have an endpoint configured but also
> > [roaming is built-in]
> > NetworkManager supports peer endpoints specified as DNS names: it
> > will resolve the
> > names before configuring the IP address in kernel. NetworkManager
> > resolves endpoint
> > names every 30 minutes or whenever the DNS configuration of the
> > host changes, in
> > order to pick up changes to the endpoint’s IP address.
> 
> I thought great! This is one good reason to let NetworkManager manage
> wireguard 
> instead of using plain wg toolkit.
> 
> My endpoint is a dualstacked IPv6/IPv4 specified by its name, e.g.:
> example.com. 7152 IN A 93.184.216.34
> example.com. 7149 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
> 
> → "Connecting" from a IPv4 only network or a dual stacked network
> works just fine!
> 
> → However, when switching from a IPv4&IPv6 network to a IPv4 only
> network, Network
> Manager does not seem to realize the endpoint is no longer reachable
> via IPv6. I 
> suspect this is because there is no DNS change and NM just assumes
> things should
> still be working.
> 
> When checking wg status(sudo wg show wg0), the endpoint is still
> pointing to the IPv6
> address.
> 
> $ sudo wg show wg0
> interface: wg0
>  public key: SSBrbm93IGkndHMgcHVibGljLCBidXQgaXQncyBhbHNvIGZ1bm55IT8K
>  private key: (hidden)
>  listening port: 55075
> 
> peer: VGhpcyBpcyBub3Q/IE9rLCBXb24ndCBpdCBkbyBhZ2Fpbgo=
>  endpoint: [2606:2800:220:1:248:1893:25c8:1946]:45333
>  allowed ips: 10.12.13.0/24, fdba:e3b1:1b22:42::/64
>  latest handshake: 1 minute, 40 seconds ago
>  transfer: 632 B received, 984 B sent
> 
> 
> As of now, I have to down&up the profile/connection so it starts
> working again.
> 
> Actually, I think the "DNS change" NM is monitoring is a DNS change
> in the client
> configuratoin (like new nameservers, and so on), and not a DNS change
> in the DNS
> Resource Records (example) as I initialy thought it was when reading
> the article.
> 
> And indeed, I am moving between Wifi networks which happened to
> "send" the same DNS
> settings (but one network is dual stacked and the other is not).
> 
> → Can NM detect this on its own? (the unreachability of an IPv6
> Endpoint over an
> IPv4 only network?)
> 
> Many thanks!
> 
> samuel

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1181

Indeed, this should work better. But it seems a difficult problem to
me. Which ultimately is caused by IETF's choice for IPv6 not being
backward compatible and the dual stack solution. But I digress.

NetworkManager probably can easily notice that something relevant might
have changed that warrants a re-evaluation of the endpoint.

But when evaluating which endpoint to use, how would NetworkManager
know which is the working one? Even the initial selection of the
endpoint is rather crude:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/a7405b0892ad329aa3f3c7e84138d6f30caf3806/src/core/devices/nm-device-wireguard.c#L782

Which gets worse, if DNS is resolved via the VPN, and (when the working
IP stack goes down) we might not even be able to re-resolve the DNS
name. The "solution" for that might be to remember the last working DNS
resolution and use that, unless we get a better one. What NM currently
does, is just not switching the endpoint. But the question still
stands, if it wanted to switch, which one would be the preferred one?


Patch welcome.


Thomas