NetBSD Problem Report #58156

From www@netbsd.org  Tue Apr 16 02:39:31 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C24781A9238
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 16 Apr 2024 02:39:31 +0000 (UTC)
Message-Id: <20240416023929.E85DB1A923A@mollari.NetBSD.org>
Date: Tue, 16 Apr 2024 02:39:29 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: wg(4) roaming endpoint gets stuck on private addresses
X-Send-Pr-Version: www-1.0

>Number:         58156
>Category:       kern
>Synopsis:       wg(4) roaming endpoint gets stuck on private addresses
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 16 02:40:01 +0000 2024
>Last-Modified:  Tue Apr 16 04:49:26 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10
>Organization:
The NotWG Foundation
>Environment:
>Description:
wg(4) maintains an endpoint address for each peer to which it will send outgoing packets.

For wg(4) to initiate a session with a peer, the endpoint address must be configured with `wgconfig wgN add peer ... --endpoint=<address> ...'.

Whenever wg(4) receives an authenticated packet from a peer, it generally updates the endpoint address to be the source address of that packet, in order to support seamless roaming.

wg(4) does this even if the endpoint has been explicitly configured, rather than inferred from the first packet sent by a peer initiating a session.

Suppose you want to configure a roaming laptop as a VPN client to use a VPN server at a fixed publicly routable IP address, say 192.0.2.42:

wgconfig wg0 add peer vpnserver <publickey> --endpoint=192.0.2.42:51820 --allowed-ips=10.0.0.0/24

Suppose the VPN server also acts as a router at 192.168.1.1 for a private NATted network 192.168.1.0/24, such as a home network, and you then connect the laptop to that private NATted network, where it gets the IP address 192.168.1.123.

The VPN server, which is also the router, will then send wg(4)-encapsulated packets to the VPN client, i.e., the roaming laptop, with a source address of 192.168.1.1 on this network, rather than its publicly routable address 192.0.2.42.  At that point, wg(4) on the laptop will dutifully update the endpoint address to 192.168.1.1, even though the user had explicitly configured 192.0.2.42.

Suppose you then move the roaming laptop to another network, where the VPN server is _not_ at 192.168.1.1.  The wg(4) session will fail until you delete the peer for the VPN server and re-add it with the endpoint address 192.0.2.42.
>How-To-Repeat:
see above
>Fix:
Yes, please!

- Maybe never override an explicitly configured endpoint address.
- Maybe avoid changing a publicly routable endpoint address to a private endpoint address.
- Maybe check for prior art, which I haven't done yet.

>Release-Note:

>Audit-Trail:
From: Kimmo Suominen <kim@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/58156: wg(4) roaming endpoint gets stuck on private
 addresses
Date: Tue, 16 Apr 2024 07:17:48 +0300

 On Tue, Apr 16, 2024 at 02:40:02AM +0000, campbell+netbsd@mumble.net wrote:
 > - Maybe never override an explicitly configured endpoint address.
 > - Maybe avoid changing a publicly routable endpoint address to a private endpoint address.
 > - Maybe check for prior art, which I haven't done yet.

 The configured endpoint address needs to be changed when both endpoints
 are using dynamic addresses.  I have such tunnels, and it is rare that
 they lose sight of one another.  A configured address is needed to
 initially bring up such a tunnel.

 I think the fix here would be some way to tell the VPN server to bind to
 a specific address, so that it won't send from other addresses.

 A workaround would be to run the VPN server on a single-homed system.
 This is how I terminate wg tunnels from roaming clients.

 I do also take advantage of the macOS client feature, where I can tell
 it to bring up the tunnel only when on WiFi except for specific SSIDs.
 This could also be used to work around the reported issue.

 Kind regards,
 + Kimmo

>Unformatted:

Home	PR Database Search