NetBSD Problem Report #58016
From www@netbsd.org Sat Mar 9 12:26:34 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 310EA1A923C
for <gnats-bugs@gnats.NetBSD.org>; Sat, 9 Mar 2024 12:26:34 +0000 (UTC)
Message-Id: <20240309122632.6ED081A923F@mollari.NetBSD.org>
Date: Sat, 9 Mar 2024 12:26:32 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: wg-userspace(8) requires explicit route setup
X-Send-Pr-Version: www-1.0
>Number: 58016
>Category: bin
>Synopsis: wg-userspace(8) requires explicit route setup
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Mar 09 12:30:01 +0000 2024
>Last-Modified: Sun Mar 10 08:50:02 +0000 2024
>Originator: Taylor R Campbell
>Release: current, 10
>Organization:
The NotWG Configuration
>Environment:
>Description:
Setting up wg-userspace(8) with an IPv4 address seems to require creating an explicit route.
Setting up wg-userspace(8) with an IPv6 address ends up with the necessary route out of the box.
>How-To-Repeat:
Set up a wg(4) instance with wg-userspace(8), having both IPv4 and IPv6 addresses:
# (umask 0077; wg-keygen | tee wg.key | wg-keygen --pub >wg.pub)
# wg-userspace 0 create
# wg-userspace 0 wgconfig wg0 set private-key wg.key
# wg-userspace 0 wgconfig wg0 add peer mypeer "...pubkey..." --endpoint=192.0.2.86:51820 --allowed-ips=10.1.0.1/32,fd01::1/128
# wg-userspace 0 ifconfig wg0 inet 10.1.0.2/24
# wg-userspace 0 ifconfig wg0 inet6 fd01::2/64
# wg-userspace 0 ifconfig wg0 up
# wg-userspace 0 ifconfig wg0
wg0: flags=0x8041<UP,RUNNING,MULTICAST> mtu 1420
status: active
inet6 fe80::b431:bed4:662e:e17c%wg0/64 flags 0 scopeid 0x2
inet6 fd01::2/64 flags 0
inet 10.1.0.2/24 flags 0
# ifconfig tun0
tun0: flags=0x51<UP,POINTOPOINT,RUNNING> mtu 1500
status: active
inet6 fd01::2/64 -> flags 0
inet 10.1.0.2/24 -> flags 0
For some reason, packets destined for the wg IPv4 subnet are still routed by the default route:
# route -n get 10.1.0.1
route to: 10.1.0.1
destination: default
mask: default
gateway: 192.168.1.1
local addr: 192.168.1.123
interface: iwm0
flags: 0x843<UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 0 0
But packets destined for the wg IPv6 subnet are routed correctly out of the box through tun0:
# route -n get -inet6 fd01::1
route to: fd01::1
destination: fd01::
mask: ffff:ffff:ffff:ffff::
local addr: fd01::2
interface: tun0
flags: 0x141<UP,DONE,CONNECTED>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 0 0
Full routing table:
# route -n show -inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 192.168.1.1 UGS - - - iwm0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
127.0.1.0 lo0 UHl - - 33624 lo0
127.0.1.1 lo0 UHl - - 33624 lo0
127.0.1.2 lo0 UHl - - 33624 lo0
127.0.1.3 lo0 UHl - - 33624 lo0
192.168.1/24 link#3 UC - - - iwm0
192.168.1.123 link#3 UHl - - - lo0
192.168.1.1 xx:xx:xx:xx:xx:xx UHL - - - iwm0
# route -n show -inet6
Routing tables
Internet6:
Destination Gateway Flags Refs Use Mtu Interface
::/96 ::1 UGRS - - 33624 lo0
default fe80::xxxx:xxff:fexx:xxxx UGS - - 1500 iwm0
::1 lo0 UHl - - 33624 lo0
::127.0.0.0/104 ::1 UGRS - - 33624 lo0
::224.0.0.0/100 ::1 UGRS - - 33624 lo0
::255.0.0.0/104 ::1 UGRS - - 33624 lo0
::ffff:0.0.0.0/96 ::1 UGRS - - 33624 lo0
2001:db8::/32 ::1 UGRS - - 33624 lo0
2002::/24 ::1 UGRS - - 33624 lo0
2002:7f00::/24 ::1 UGRS - - 33624 lo0
2002:e000::/20 ::1 UGRS - - 33624 lo0
2002:ff00::/24 ::1 UGRS - - 33624 lo0
2xxx:xxxx:xxxx:xxxx::/64 link#3 UCS - - 1500 iwm0
2xxx:xxxx:xxxx:xxxx::123 link#3 UHl - - - lo0
2xxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx link#3 UHl - - - lo0
fd00::/64 link#3 UCS - - 1500 iwm0
fd00::123 link#3 UHl - - - lo0
fd00::xxxx:xxxx:xxxx:xxxx link#3 UHl - - - lo0
fd01::/64 fd01::2 UC - - - tun0
fd01::2 tun0 UHl - - - lo0
fe80::/10 ::1 UGRS - - 33624 lo0
fe80::%lo0/64 fe80::1 U - - - lo0
fe80::1 lo0 UHl - - - lo0
fe80::%iwm0/64 link#3 UC - - - iwm0
fe80::xxxx:xxxx:xxxx:xxxx link#3 UHl - - - lo0
ff01:2::/32 ::1 UC - - 33624 lo0
ff01:3::/32 link#3 UC - - - iwm0
ff02::%lo0/32 ::1 UC - - 33624 lo0
ff02::%iwm0/32 link#3 UC - - - iwm0
fe80::xxxx:xxff:fexx:xxxx xx:xx:xx:xx:xx:xx UHL - - - iwm0
>Fix:
Yes, please!
Unclear if this is really a wg-userspace(8) issue or a tun(4) issue.
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc:
Subject: Re: bin/58016: wg-userspace(8) requires explicit route setup
Date: Sat, 9 Mar 2024 12:44:28 +0000
If I just create an unopened tun(4) instance, the same thing happens,
so it's probably a tun(4) issue rather than a wg(4) or wg-userspace(8)
issue:
# ifconfig tun1 create
# ifconfig tun1 inet 10.2.0.2/24
# ifconfig tun1 inet6 fd02::2/64
# ifconfig tun1 up
# ifconfig tun1
tun1: flags=3D0x51<UP,POINTOPOINT,RUNNING> mtu 1500
status: down
inet6 fd02::2/64 -> flags 0x8<DETACHED>
inet 10.2.0.2/24 -> flags 0x4<DETACHED>
# route -n get -inet 10.2.0.1
route to: 10.2.0.1
destination: default
mask: default
gateway: 192.168.1.1
local addr: 192.168.1.123
interface: iwm0
flags: 0x843<UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu ex=
pire
0 0 0 0 0 0 0 =
0
# route -n get -inet6 fd02::1
route to: fd02::1
destination: fd02::
mask: ffff:ffff:ffff:ffff::
local addr: fd02::2
interface: tun1
flags: 0x141<UP,DONE,CONNECTED>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu ex=
pire
0 0 0 0 0 0 0 =
0
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc:
Subject: Re: bin/58016: wg-userspace(8) requires explicit route setup
Date: Sun, 10 Mar 2024 04:53:29 +0000
If I change wg-userspace(8) to do
ifmode =3D IFF_BROADCAST|IFF_MULTICAST;
if (ioctl(fd, TUNSIFMODE, &ifmode) =3D=3D -1) {
close(fd);
fd =3D -1;
}
when creating the tun(4) interface, then ifconfig(8) output looks like
this instead:
# ifconfig tun0
tun0: flags=3D0x8043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
status: active
inet6 fd01::2/64 flags 0
inet6 fe80::9afa:9bff:fe60:a0d2%tun0/64 flags 0 scopeid 0x4
inet 10.1.0.2/24 broadcast 10.1.0.255 flags 0
And both inet and inet6 routes work as expected on 10.1.0.0/24
addresses:
# route -n get -inet 10.1.0.1
route to: 10.1.0.1
destination: 10.1.0.0
mask: 255.255.255.0
local addr: 10.1.0.2
interface: tun0
flags: 0x41<UP,DONE>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu ex=
pire
0 0 0 0 0 0 0 =
0
# route -n get -inet6 fd01::1
route to: fd01::1
destination: fd01::
mask: ffff:ffff:ffff:ffff::
local addr: fd01::2
interface: tun0
flags: 0x141<UP,DONE,CONNECTED>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu ex=
pire
0 0 0 0 0 0 0 =
0
(Still unclear on why, in the default IFF_POINTOPOINT setting of
tun(4), an explicit route is needed only for IPv4 while the system
automagically adds the necessary route for IPv6.)
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/58016: wg-userspace(8) requires explicit route setup
Date: Sun, 10 Mar 2024 08:44:50 -0000 (UTC)
riastradh@NetBSD.org (Taylor R Campbell) writes:
>(Still unclear on why, in the default IFF_POINTOPOINT setting of
>tun(4), an explicit route is needed only for IPv4 while the system
>automagically adds the necessary route for IPv6.)
That is 4.4BSD-Lite2:
if (ifp->if_flags & IFF_BROADCAST) {
ia->ia_broadaddr.sin_addr.s_addr =
htonl(ia->ia_subnet | ~ia->ia_subnetmask);
ia->ia_netbroadcast.s_addr =
htonl(ia->ia_net | ~ ia->ia_netmask);
} else if (ifp->if_flags & IFF_LOOPBACK) {
ia->ia_ifa.ifa_dstaddr = ia->ia_ifa.ifa_addr;
flags |= RTF_HOST;
} else if (ifp->if_flags & IFF_POINTOPOINT) {
if (ia->ia_dstaddr.sin_family != AF_INET)
return (0);
flags |= RTF_HOST;
}
if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
ia->ia_flags |= IFA_ROUTE;
For POINTOPOINT interfaces, there is a host route to the peer,
and any network mask is ignored.
The notion of having multiple destinations on a POINTOPOINT
interface is also a strange one. The original use was for
a synchronous serial line, not a multi-target tunnel.
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home