NetBSD Problem Report #57155
From joel.bertrand@systella.fr Tue Jan 3 12:34:01 2023
Return-Path: <joel.bertrand@systella.fr>
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 1748B1A9239
for <gnats-bugs@gnats.NetBSD.org>; Tue, 3 Jan 2023 12:34:01 +0000 (UTC)
Message-Id: <bb8b7fad-f65a-0979-c725-3c6e082e6394@systella.fr>
Date: Tue, 3 Jan 2023 13:33:45 +0100
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
Reply-To: joel.bertrand@systella.fr
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Subject: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
>Number: 57155
>Category: kern
>Synopsis: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 03 12:35:00 +0000 2023
>Last-Modified: Tue Jan 10 07:55:01 +0000 2023
>Originator: joel.bertrand@systella.fr
>Release: NetBSD 10.0_BETA
>Organization:
>Environment:
System: NetBSD legendre.systella.fr 10.0_BETA NetBSD 10.0_BETA (CUSTOM)
#3: Tue Dec 27 08:46:20 CET 2022
root@legendre.systella.fr:/usr/src/netbsd-10/obj/sys/arch/amd64/compile/CUSTOM
amd64
Architecture: x86_64
Machine: amd64
>Description:
Let consider an OpenVPN client (VPN interface could be tap0 or
tun0). This client is connected to an OpenVPN server through a physical
Ethernet adapter (in my case, wm0).
Client IP address : 192.168.1.2
Server IP address : 192.168.1.1
WAN-----192.168.1.1 (OpenVPN server, Linux)
|
WAN-----192.168.1.2 (OpenVPN client, NetBSD 10.0_BETA) 192.168.10.128---LAN
VPN connection is up but :
- OpenVPN server cannot ping client (192.168.1.2);
- OpenVPN client cannot ping server (192.168.1.1).
If I add a second Ethernet adapter in client (to connect a LAN)
and if I configure npf to nat IP behind client, all workstations on LAN
can ping OpenVPN server.
Same configuration ran fine with NetBSD-9.3 kernel (and all
kernels since -7).
tcpdump doesn't show packets. Kernel only seems to drop packets.
>How-To-Repeat:
Configure an OpenVPN client. I have tested with an OpenVPN UDP
configuration, but with tap and tun interface.
>Fix:
>Audit-Trail:
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: joel.bertrand@systella.fr
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Wed, 4 Jan 2023 16:10:19 +0900
On Tue, Jan 3, 2023 at 9:35 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella.f=
r> wrote:
>
> >Number: 57155
> >Category: kern
> >Synopsis: OpenVPN (tap and tun) doesn't run as expected on 10.0_BE=
TA
> >Confidential: no
> >Severity: critical
> >Priority: high
> >Responsible: kern-bug-people
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Tue Jan 03 12:35:00 +0000 2023
> >Originator: joel.bertrand@systella.fr
> >Release: NetBSD 10.0_BETA
> >Organization:
> >Environment:
> System: NetBSD legendre.systella.fr 10.0_BETA NetBSD 10.0_BETA (CUSTOM)
> #3: Tue Dec 27 08:46:20 CET 2022
> root@legendre.systella.fr:/usr/src/netbsd-10/obj/sys/arch/amd64/compile/C=
USTOM
> amd64
> Architecture: x86_64
> Machine: amd64
> >Description:
>
> Let consider an OpenVPN client (VPN interface could be tap0 or
> tun0). This client is connected to an OpenVPN server through a physical
> Ethernet adapter (in my case, wm0).
>
> Client IP address : 192.168.1.2
> Server IP address : 192.168.1.1
>
> WAN-----192.168.1.1 (OpenVPN server, Linux)
> |
> WAN-----192.168.1.2 (OpenVPN client, NetBSD 10.0_BETA) 192.168.10.128---L=
AN
>
> VPN connection is up but :
> - OpenVPN server cannot ping client (192.168.1.2);
> - OpenVPN client cannot ping server (192.168.1.1).
>
> If I add a second Ethernet adapter in client (to connect a LAN)
> and if I configure npf to nat IP behind client, all workstations on LAN
> can ping OpenVPN server.
>
> Same configuration ran fine with NetBSD-9.3 kernel (and all
> kernels since -7).
>
> tcpdump doesn't show packets. Kernel only seems to drop packets.
>
> >How-To-Repeat:
> Configure an OpenVPN client. I have tested with an OpenVPN UDP
> configuration, but with tap and tun interface.
> >Fix:
>
I've installed NetBSD 10 on Linux KVM and tested with them. The guest
is under NAT in my setup. OpenVPN is installed via pkg_add.
netbsd10# uname -a
NetBSD netbsd10 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Sat Dec 31
04:55:53 UTC 2022
mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
amd64
netbsd10# pkg_info openvpn |head -1
Information for openvpn-2.5.7nb1:
With the simple openvpn setups below, ping between the client and the serve=
r
works for me.
[host]
openvpn --remote 192.168.122.11 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --v=
erb 1
[guest]
openvpn --remote 192.168.0.100 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1
--verb 1 --float --ping 10
[ping from guest]
netbsd10# ping -n -c 1 10.4.0.1
PING 10.4.0.1 (10.4.0.1): 56 data bytes
64 bytes from 10.4.0.1: icmp_seq=3D0 ttl=3D64 time=3D1.250718 ms
----10.4.0.1 PING Statistics----
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev =3D 1.250718/1.250718/1.250718/0.000000 ms
The difference of the results may come from differences between my and your
environments. My NetBSD 10 is fresh and doesn't enable networking
services/daemons that affect the result other than openvpn.
ozaki-r
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Wed, 4 Jan 2023 08:29:53 +0100
Ryota Ozaki a écrit :
> I've installed NetBSD 10 on Linux KVM and tested with them. The guest
> is under NAT in my setup. OpenVPN is installed via pkg_add.
I have seen this issue on my main server (that was installed with 7.2
if I remember and upgraded until 10_BETA) and on a fresh install in a VM
(KVM). I have built openvpn from pkgsrc.
> netbsd10# uname -a
> NetBSD netbsd10 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Sat Dec 31
> 04:55:53 UTC 2022
> mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
> amd64
> netbsd10# pkg_info openvpn |head -1
> Information for openvpn-2.5.7nb1:
Mine is OpenVPN 2.5.8 (on both systems).
> With the simple openvpn setups below, ping between the client and the serve=
> r
> works for me.
>
> [host]
> openvpn --remote 192.168.122.11 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --v=
> erb 1
>
> [guest]
> openvpn --remote 192.168.0.100 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1
> --verb 1 --float --ping 10
>
> [ping from guest]
> netbsd10# ping -n -c 1 10.4.0.1
> PING 10.4.0.1 (10.4.0.1): 56 data bytes
> 64 bytes from 10.4.0.1: icmp_seq=3D0 ttl=3D64 time=3D1.250718 ms
>
> ----10.4.0.1 PING Statistics----
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev =3D 1.250718/1.250718/1.250718/0.000000 ms
Client configuration:
rport 1194
lport 1194
proto udp
dev tun (or dev tap)
remote xxx.yyy.zzz.ttt
float
client
tls-client
remote-cert-tls server
ca ...
cert ...
key ...
comp-lzo adaptative
verb 3
keepalive 5 30
passtos
Note that
> The difference of the results may come from differences between my and your
> environments. My NetBSD 10 is fresh and doesn't enable networking
> services/daemons that affect the result other than openvpn.
I can understand daemons can produce this issue, but in my VM, I only
have installed a system from official BETA 10.0 iso and only added openvpn.
Regards,
JKB
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Wed, 4 Jan 2023 16:57:36 +0900
On Wed, Jan 4, 2023 at 4:30 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella.f=
r> wrote:
>
> Ryota Ozaki a =C3=A9crit :
> > I've installed NetBSD 10 on Linux KVM and tested with them. The guest
> > is under NAT in my setup. OpenVPN is installed via pkg_add.
>
> I have seen this issue on my main server (that was installed with=
7.2
> if I remember and upgraded until 10_BETA) and on a fresh install in a VM
> (KVM). I have built openvpn from pkgsrc.
>
> > netbsd10# uname -a
> > NetBSD netbsd10 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Sat Dec 31
> > 04:55:53 UTC 2022
> > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > amd64
> > netbsd10# pkg_info openvpn |head -1
> > Information for openvpn-2.5.7nb1:
>
> Mine is OpenVPN 2.5.8 (on both systems).
>
> > With the simple openvpn setups below, ping between the client and the =
serve=3D
> > r
> > works for me.
> >
> > [host]
> > openvpn --remote 192.168.122.11 --dev tun1 --ifconfig 10.4.0.1 10.4.0.=
2 --v=3D
> > erb 1
> >
> > [guest]
> > openvpn --remote 192.168.0.100 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1
> > --verb 1 --float --ping 10
> >
> > [ping from guest]
> > netbsd10# ping -n -c 1 10.4.0.1
> > PING 10.4.0.1 (10.4.0.1): 56 data bytes
> > 64 bytes from 10.4.0.1: icmp_seq=3D3D0 ttl=3D3D64 time=3D3D1.250718 ms
> >
> > ----10.4.0.1 PING Statistics----
> > 1 packets transmitted, 1 packets received, 0.0% packet loss
> > round-trip min/avg/max/stddev =3D3D 1.250718/1.250718/1.250718/0.00000=
0 ms
>
> Client configuration:
>
> rport 1194
> lport 1194
> proto udp
> dev tun (or dev tap)
> remote xxx.yyy.zzz.ttt
> float
> client
> tls-client
> remote-cert-tls server
> ca ...
> cert ...
> key ...
> comp-lzo adaptative
> verb 3
> keepalive 5 30
> passtos
>
> Note that
>
> > The difference of the results may come from differences between my and=
your
> > environments. My NetBSD 10 is fresh and doesn't enable networking
> > services/daemons that affect the result other than openvpn.
>
> I can understand daemons can produce this issue, but in my VM, I =
only
> have installed a system from official BETA 10.0 iso and only added openvp=
n.
ok, I'm trying to set up the same openvpn configuration as yours.
ozaki-r
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Wed, 4 Jan 2023 10:45:10 +0100
I have tested your configuration between my VM (OpenVPN client) and
host that runs this VM (OpenVPN server).
Thus client and server run on the same physical workstation. Server in
host (Linux devuan/testing), client in KVM guest (NetBSD 10.0). I use
TCP to avoid NAT issue. Of course, I have checked that packets are not
blocked.
Server:
Root hilbert:[~] > openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2
--verb 10 --proto tcp-server
Client:
netbsd-test1# openvpn --remote 192.168.10.103 --dev tun1 --ifconfig
10.4.0.2 10.4.0.1 --verb 10 --float --ping 10 --proto tcp-client
I can ping server from client and client from server.
Now, I use another OpenVPN server, on a different host.
legendre# openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 10
--proto tcp-server
tcpdump -i wm0 -p port 1194 on client shows packets in both directions.
On legendre (NetBSD 10.0), tun1 is up and configured, but OpenVPN
client is not accessible:
legendre:[~] > ifconfig tun1
tun1: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
status: active
inet6 fe80::b696:91ff:fe92:776e%tun1/64 -> flags 0 scopeid 0xb
inet 10.4.0.1/32 -> 10.4.0.2 flags 0
legendre:[~] > ping 10.4.0.2
PING 10.4.0.2 (10.4.0.2): 56 data bytes
^C
----10.4.0.2 PING Statistics----
5 packets transmitted, 0 packets received, 100.0% packet loss
legendre:[~] > route show
Routing tables
...
10.4.0.1 tun1 UHl - - - lo0
10.4.0.2 10.4.0.1 UH - - - tun1
...
Regards,
JKB
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Wed, 4 Jan 2023 19:28:52 +0900
On Wed, Jan 4, 2023 at 4:57 PM Ryota Ozaki <ozaki-r@netbsd.org> wrote:
>
> On Wed, Jan 4, 2023 at 4:30 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella=
.fr> wrote:
> >
> > Ryota Ozaki a =C3=A9crit :
> > > I've installed NetBSD 10 on Linux KVM and tested with them. The gue=
st
> > > is under NAT in my setup. OpenVPN is installed via pkg_add.
> >
> > I have seen this issue on my main server (that was installed wi=
th 7.2
> > if I remember and upgraded until 10_BETA) and on a fresh install in a V=
M
> > (KVM). I have built openvpn from pkgsrc.
> >
> > > netbsd10# uname -a
> > > NetBSD netbsd10 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Sat Dec 31
> > > 04:55:53 UTC 2022
> > > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > > amd64
> > > netbsd10# pkg_info openvpn |head -1
> > > Information for openvpn-2.5.7nb1:
> >
> > Mine is OpenVPN 2.5.8 (on both systems).
> >
> > > With the simple openvpn setups below, ping between the client and th=
e serve=3D
> > > r
> > > works for me.
> > >
> > > [host]
> > > openvpn --remote 192.168.122.11 --dev tun1 --ifconfig 10.4.0.1 10.4.=
0.2 --v=3D
> > > erb 1
> > >
> > > [guest]
> > > openvpn --remote 192.168.0.100 --dev tun1 --ifconfig 10.4.0.2 10.4.0=
.1
> > > --verb 1 --float --ping 10
> > >
> > > [ping from guest]
> > > netbsd10# ping -n -c 1 10.4.0.1
> > > PING 10.4.0.1 (10.4.0.1): 56 data bytes
> > > 64 bytes from 10.4.0.1: icmp_seq=3D3D0 ttl=3D3D64 time=3D3D1.250718 =
ms
> > >
> > > ----10.4.0.1 PING Statistics----
> > > 1 packets transmitted, 1 packets received, 0.0% packet loss
> > > round-trip min/avg/max/stddev =3D3D 1.250718/1.250718/1.250718/0.000=
000 ms
> >
> > Client configuration:
> >
> > rport 1194
> > lport 1194
> > proto udp
> > dev tun (or dev tap)
> > remote xxx.yyy.zzz.ttt
> > float
> > client
> > tls-client
> > remote-cert-tls server
> > ca ...
> > cert ...
> > key ...
> > comp-lzo adaptative
> > verb 3
> > keepalive 5 30
> > passtos
> >
> > Note that
> >
> > > The difference of the results may come from differences between my a=
nd your
> > > environments. My NetBSD 10 is fresh and doesn't enable networking
> > > services/daemons that affect the result other than openvpn.
> >
> > I can understand daemons can produce this issue, but in my VM, =
I only
> > have installed a system from official BETA 10.0 iso and only added open=
vpn.
>
> ok, I'm trying to set up the same openvpn configuration as yours.
I've set up and tested.
The configurations of client/server are like those:
[server]
port 1194
proto udp
dev tun
ca ca.crt
cert servername.crt
key servername.key
dh none
server 10.4.0.0 255.255.255.0
keepalive 10 120
tls-server
verb 3
[client]
rport 1194
lport 1194
proto udp
dev tun
remote 192.168.0.100
float
client
tls-client
remote-cert-tls server
ca ca.crt
cert client1.crt
key client1.key
#comp-lzo adaptative
verb 3
keepalive 5 30
passtos
The configuration doesn't set up fixed IP addresses for client/server.
so end-point addresses of tun interfaces are not symmetric.
server: 10.4.0.1 -> 10.4.0.2
client: 10.4.0.6 -> 10.4.0.5
Anyway the client can ping to 10.4.0.1 and the server can ping to 10.4.0.6.
ozaki-r
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Wed, 4 Jan 2023 19:51:28 +0900
On Wed, Jan 4, 2023 at 6:45 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella.f=
r> wrote:
>
> I have tested your configuration between my VM (OpenVPN client) a=
nd
> host that runs this VM (OpenVPN server).
>
> Thus client and server run on the same physical workstation. Serv=
er in
> host (Linux devuan/testing), client in KVM guest (NetBSD 10.0). I use
> TCP to avoid NAT issue. Of course, I have checked that packets are not
> blocked.
>
> Server:
> Root hilbert:[~] > openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2
> --verb 10 --proto tcp-server
>
> Client:
> netbsd-test1# openvpn --remote 192.168.10.103 --dev tun1 --ifconfig
> 10.4.0.2 10.4.0.1 --verb 10 --float --ping 10 --proto tcp-client
>
> I can ping server from client and client from server.
Good. Thank you for testing.
>
> Now, I use another OpenVPN server, on a different host.
>
> legendre# openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 10
> --proto tcp-server
>
> tcpdump -i wm0 -p port 1194 on client shows packets in both direc=
tions.
>
> On legendre (NetBSD 10.0), tun1 is up and configured, but OpenVPN
> client is not accessible:
>
> legendre:[~] > ifconfig tun1
> tun1: flags=3D0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
> status: active
> inet6 fe80::b696:91ff:fe92:776e%tun1/64 -> flags 0 scopeid 0xb
> inet 10.4.0.1/32 -> 10.4.0.2 flags 0
> legendre:[~] > ping 10.4.0.2
> PING 10.4.0.2 (10.4.0.2): 56 data bytes
> ^C
> ----10.4.0.2 PING Statistics----
> 5 packets transmitted, 0 packets received, 100.0% packet loss
> legendre:[~] > route show
> Routing tables
> ...
> 10.4.0.1 tun1 UHl - - - lo0
> 10.4.0.2 10.4.0.1 UH - - - tun1
> ...
So packets are sent to a peer and dropped at tun1 (or somewhere)
on a peer, right? Could you show me the output of ifconfig -v tun1?
If packets are not dropped at tun1, we may be able to see packet drops
with netstat -s.
Anyway, I'll set up another machine tomorrow.
ozaki-r
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Wed, 4 Jan 2023 12:01:45 +0100
Ryota Ozaki a écrit :
> The following reply was made to PR kern/57155; it has been noted by GNATS.
>
> From: Ryota Ozaki <ozaki-r@netbsd.org>
> To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
> Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org
> Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
> Date: Wed, 4 Jan 2023 19:28:52 +0900
>
> On Wed, Jan 4, 2023 at 4:57 PM Ryota Ozaki <ozaki-r@netbsd.org> wrote:
> >
> > On Wed, Jan 4, 2023 at 4:30 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella=
> .fr> wrote:
> > >
> > > Ryota Ozaki a =C3=A9crit :
> > > > I've installed NetBSD 10 on Linux KVM and tested with them. The gue=
> st
> > > > is under NAT in my setup. OpenVPN is installed via pkg_add.
> > >
> > > I have seen this issue on my main server (that was installed wi=
> th 7.2
> > > if I remember and upgraded until 10_BETA) and on a fresh install in a V=
> M
> > > (KVM). I have built openvpn from pkgsrc.
> > >
> > > > netbsd10# uname -a
> > > > NetBSD netbsd10 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Sat Dec 31
> > > > 04:55:53 UTC 2022
> > > > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > > > amd64
> > > > netbsd10# pkg_info openvpn |head -1
> > > > Information for openvpn-2.5.7nb1:
> > >
> > > Mine is OpenVPN 2.5.8 (on both systems).
> > >
> > > > With the simple openvpn setups below, ping between the client and th=
> e serve=3D
> > > > r
> > > > works for me.
> > > >
> > > > [host]
> > > > openvpn --remote 192.168.122.11 --dev tun1 --ifconfig 10.4.0.1 10.4.=
> 0.2 --v=3D
> > > > erb 1
> > > >
> > > > [guest]
> > > > openvpn --remote 192.168.0.100 --dev tun1 --ifconfig 10.4.0.2 10.4.0=
> .1
> > > > --verb 1 --float --ping 10
> > > >
> > > > [ping from guest]
> > > > netbsd10# ping -n -c 1 10.4.0.1
> > > > PING 10.4.0.1 (10.4.0.1): 56 data bytes
> > > > 64 bytes from 10.4.0.1: icmp_seq=3D3D0 ttl=3D3D64 time=3D3D1.250718 =
> ms
> > > >
> > > > ----10.4.0.1 PING Statistics----
> > > > 1 packets transmitted, 1 packets received, 0.0% packet loss
> > > > round-trip min/avg/max/stddev =3D3D 1.250718/1.250718/1.250718/0.000=
> 000 ms
> > >
> > > Client configuration:
> > >
> > > rport 1194
> > > lport 1194
> > > proto udp
> > > dev tun (or dev tap)
> > > remote xxx.yyy.zzz.ttt
> > > float
> > > client
> > > tls-client
> > > remote-cert-tls server
> > > ca ...
> > > cert ...
> > > key ...
> > > comp-lzo adaptative
> > > verb 3
> > > keepalive 5 30
> > > passtos
> > >
> > > Note that
> > >
> > > > The difference of the results may come from differences between my a=
> nd your
> > > > environments. My NetBSD 10 is fresh and doesn't enable networking
> > > > services/daemons that affect the result other than openvpn.
> > >
> > > I can understand daemons can produce this issue, but in my VM, =
> I only
> > > have installed a system from official BETA 10.0 iso and only added open=
> vpn.
> >
> > ok, I'm trying to set up the same openvpn configuration as yours.
>
> I've set up and tested.
>
> The configurations of client/server are like those:
>
> [server]
>
> port 1194
> proto udp
> dev tun
>
> ca ca.crt
> cert servername.crt
> key servername.key
> dh none
>
> server 10.4.0.0 255.255.255.0
> keepalive 10 120
> tls-server
>
> verb 3
>
> [client]
>
> rport 1194
> lport 1194
> proto udp
> dev tun
> remote 192.168.0.100
> float
> client
> tls-client
> remote-cert-tls server
> ca ca.crt
> cert client1.crt
> key client1.key
> #comp-lzo adaptative
> verb 3
> keepalive 5 30
> passtos
>
>
> The configuration doesn't set up fixed IP addresses for client/server.
> so end-point addresses of tun interfaces are not symmetric.
>
> server: 10.4.0.1 -> 10.4.0.2
> client: 10.4.0.6 -> 10.4.0.5
>
> Anyway the client can ping to 10.4.0.1 and the server can ping to 10.4.0.6.
>
> ozaki-r
>
>
I suppose you try to configure OpenVPN between a guest running in a VM
and host. In my case, this configuration runs fine. But when server and
client are on different machines, VPN remains up but all trafics are
blocked. Please not that if I configure a LAN behind OpenVPN client
(with NAT), all systems on this LAN can ping server. And server can ping
this workstations through OpenVPN client!
I have seen this issue first time on my main server (legendre) with the
following configuration:
- bridge 0 (wm0/wm1): NAS [192.168.12.1/24]
- lagg0 (wm3/wm3): LAN [192.168.10.128/24]
- wm2: WAN
- tap0: OpenVPN client (server is accessible through wm2) [192.168.1.1/24]
legendre# ifconfig tap0
tap0: flags=0x8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
ec_enabled=0
address: f2:0b:a4:38:bb:42
status: no carrier
inet6 2001:7a8:a8ed:1::2/64 flags 0x8<DETACHED>
inet6 fe80::f00b:a4ff:fe38:bb42%tap0/64 flags 0x8<DETACHED>
scopeid 0x9
inet 192.168.1.2/24 broadcast 192.168.1.255 flags 0x4<DETACHED>
legendre# ifconfig lagg0
lagg0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=0x7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
capabilities=0x7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
capabilities=0x7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
enabled=0
ec_capabilities=0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
ec_enabled=0x2<VLAN_HWTAGGING>
laggproto loadbalance
laggport:
wm3 pri=32768 flags=0x1c<ACTIVE,COLLECTING,DISTRIBUTING>
wm4 pri=32768 flags=0x1c<ACTIVE,COLLECTING,DISTRIBUTING>
address: 68:05:ca:02:b2:59
status: active
inet6 fe80::6a05:caff:fe02:b259%lagg0/64 flags 0 scopeid 0x8
inet6 2001:7a8:a8ed:10::128/64 flags 0
inet 192.168.10.128/24 broadcast 192.168.10.255 flags 0
This OpenVPN client cannot ping OpenVPN server:
Rayleigh tap0 (OpenVPN server) address is 192.168.1.1. I will use
numerical address for rayleigh as DNS is broken (views are configured
and are only seen through tap0).
Please note:
- legendre (192.168.1.2): OpenVPN client
- rayleigh (192.168.1.1): OpenVPN server
- fermat (192.168.10.107): OpenVMS server on LAN
- hilbert (192.168.10.103): Linux server on LAN
legendre# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
^C
----192.168.1.1 PING Statistics----
3 packets transmitted, 0 packets received, 100.0% packet loss
legendre#
On LAN, I have several workstations. For example, hilbert. Hilbert can
ping 192.168.1.1:
hilbert:[~] > ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=55.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=53.4 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=53.4 ms
^C
OpenVPN server (rayleigh, address 192.168.1.1) can ping hilbert (Linux,
address 192.168.10.103 through tap0) or fermat (OpenVMS, address
192.168.10.107 through tap0) but not legendre (NetBSD 10 OpenVPN client,
address 192.168.1.2):
rayleigh:[~] > ping hilbert
PING hilbert.systella.fr (192.168.10.103) 56(84) bytes of data.
64 bytes from hilbert.systella.fr (192.168.10.103): icmp_seq=1 ttl=63
time=54.6 ms
64 bytes from hilbert.systella.fr (192.168.10.103): icmp_seq=2 ttl=63
time=51.6 ms
^C
rayleigh:[~] > ping fermat
PING fermat.systella.fr (192.168.10.107) 56(84) bytes of data.
64 bytes from fermat.systella.fr (192.168.10.107): icmp_seq=1 ttl=63
time=71.7 ms
^C
rayleigh:[~] > ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
^C
--- 192.168.1.2 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12054ms
More generally, OpenVPN server routes a IPv4 /28 public addresses
through tap0 to access to LAN server and all servers on LAN are
accessible from WAN through tap0.
Legendre (OpenVPN client) is the hilbert's default IPv4 route:
hilbert:[~] > /sbin/route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default legendre.systel 0.0.0.0 UG 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
hilbert:[~] >
On legendre, route are:
legendre# route show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu
Interface
default 192.168.15.20 UGS - - - wm2
dns.google 192.168.15.19 UGHS - - - wm2
dns.google 192.168.15.20 UGHS - - - wm2
79.170.216.0/28 192.168.1.1 UGS - - - tap0
91.196.180.225 192.168.1.1 UGHS - - - tap0
127/8 localhost UGRS - - 33624 lo0
localhost lo0 UHl - - 33624 lo0
www.nerim.com 192.168.15.20 UGHS - - - wm2
192.168.0/24 192.168.1.1 UGS - - - tap0
192.168.1/24 link#9 UC - - - tap0
192.168.1.2 link#9 UHl - - - lo0
192.168.2/24 192.168.1.1 UGS - - - tap0
192.168.10/24 link#8 UC - - - lagg0
192.168.10.128 link#8 UHl - - - lo0
192.168.12/24 link#1 UC - - - wm0
192.168.12.1 link#1 UHl - - - lo0
192.168.15/24 link#3 UC - - - wm2
legendre link#3 UHl - - - lo0
192.168.253/24 192.168.1.1 UGS - - - tap0
192.168.254/24 192.168.1.1 UGS - - - tap0
192.168.1.1 32:f3:6d:94:8c:9b UHL - - - tap0
192.168.10.102 38:2c:4a:70:14:d1 UHL - - - lagg0
192.168.10.103 d4:5d:64:b4:9a:3b UHL - - - lagg0
192.168.10.101 d8:cb:8a:35:21:95 UHL - - - lagg0
192.168.10.107 08:00:2b:7a:39:2e UHL - - - lagg0
192.168.10.104 b8:27:eb:a3:dd:a8 UHL - - - lagg0
192.168.10.250 88:75:56:07:d4:08 UHL - - - lagg0
192.168.10.253 34:db:fd:5d:1e:88 UHL - - - lagg0
192.168.15.20 60:a4:b7:73:c9:26 UHL - - - wm2
192.168.12.2 24:5e:be:3b:96:e9 UHL - - - wm0
192.168.12.3 24:5e:be:14:44:57 UHL - - - wm0
Thus, packets sent by hilbert are routed through tap0 by legendre to
192.168.1.1 and OpenVPN server answers as hilbert receives packets. I
have verified that tcpdump -i tap0 shows ping and pong packets. But
legendre itself cannot send packets through tap0.
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Wed, 4 Jan 2023 15:45:47 +0100
I have forgotten. If I reboots legendre with a customized NetBSD-9.3
kernel (GENERIC + ALTQ + ISCSI support), legendre can ping rayleigh
through VPN.
Thus, OpenVMS or firewall configuration are not faulty.
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: Ryota Ozaki <ozaki-r@netbsd.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Wed, 4 Jan 2023 16:58:19 +0100
Ryota Ozaki a écrit :
> On Wed, Jan 4, 2023 at 6:45 PM BERTRAND Joël <joel.bertrand@systella.fr> wrote:
>>
>> I have tested your configuration between my VM (OpenVPN client) and
>> host that runs this VM (OpenVPN server).
>>
>> Thus client and server run on the same physical workstation. Server in
>> host (Linux devuan/testing), client in KVM guest (NetBSD 10.0). I use
>> TCP to avoid NAT issue. Of course, I have checked that packets are not
>> blocked.
>>
>> Server:
>> Root hilbert:[~] > openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2
>> --verb 10 --proto tcp-server
>>
>> Client:
>> netbsd-test1# openvpn --remote 192.168.10.103 --dev tun1 --ifconfig
>> 10.4.0.2 10.4.0.1 --verb 10 --float --ping 10 --proto tcp-client
>>
>> I can ping server from client and client from server.
>
> Good. Thank you for testing.
You're welcome.
<snip>
>
> So packets are sent to a peer and dropped at tun1 (or somewhere)
> on a peer, right? Could you show me the output of ifconfig -v tun1?
I can, of course.
legendre# ifconfig -v tun1
tun1: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
status: active
input: 164 packets, 13728 bytes
output: 0 packets, 0 bytes
inet6 fe80::b696:91ff:fe92:776e%tun1/64 -> flags 0 scopeid 0xb
inet 10.4.0.1/32 -> 10.4.0.2 flags 0
#netbsd-test1# ifconfig -v tun1
tun1: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
status: active
input: 0 packets, 0 bytes
output: 164 packets, 14384 bytes
inet6 fe80::a8c4:9abe:2575:9256%tun1/64 -> flags 0 scopeid 0x3
inet 10.4.0.2/32 -> 10.4.0.1 flags 0
Running configuration is :
Server:
legendre# openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 10
--proto tcp-server
Client (netbsd in KVM)
netbsd-test1# openvpn --remote 192.168.10.128 --dev tun1 --ifconfig
10.4.0.2 10.4.0.1 --proto tcp-client --verb 10 --float --ping 10
tcpdump -p -i eth0 on host that runs KVM virtual machine shows traffic
on port 1194/TCP.
If I try to ping server, tcpdump shows :
16:38:44.006098 IP legendre.systella.fr.openvpn >
hilbert.systella.fr.40674: Flags [.], ack 1548, win 4480, options
[nop,nop,TS val 152 ecr 3389821985], length 0
16:38:44.811261 IP hilbert.systella.fr.40674 >
legendre.systella.fr.openvpn: Flags [P.], seq 1548:1634, ack 1, win 502,
options [nop,nop,TS val 3389822984 ecr 152], length 86
16:38:45.006086 IP legendre.systella.fr.openvpn >
hilbert.systella.fr.40674: Flags [.], ack 1634, win 4480, options
[nop,nop,TS val 154 ecr 3389822984], length 0
16:38:45.809397 IP hilbert.systella.fr.40674 >
legendre.systella.fr.openvpn: Flags [P.], seq 1634:1720, ack 1, win 502,
options [nop,nop,TS val 3389823982 ecr 154], length 86
16:38:46.006089 IP legendre.systella.fr.openvpn >
hilbert.systella.fr.40674: Flags [.], ack 1720, win 4480, options
[nop,nop,TS val 156 ecr 3389823982], length 0
These TCP transaction only show ping packet. OpenVPN server doesn't
answer (length 0 from legendre to hilbert).
If I check packets on legendre's tun1 interface, I have:
legendre# tcpdump -i tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type NULL (BSD loopback), capture size 262144 bytes
16:50:19.179199 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
0, length 64
16:50:20.192920 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
1, length 64
16:50:21.200582 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
2, length 64
16:50:22.199129 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
3, length 64
16:50:23.197255 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
4, length 64
16:50:24.204649 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
5, length 64
16:50:25.203051 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
6, length 64
16:50:26.201564 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
7, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
Thus legendre receives ping packets from VM and doesn't answer.
> If packets are not dropped at tun1, we may be able to see packet drops
> with netstat -s.
netstat -s | grep drop output is not affected by ping 10.4.0.1.
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Thu, 5 Jan 2023 12:14:08 +0900
On Thu, Jan 5, 2023 at 12:58 AM BERTRAND Jo=C3=ABl <joel.bertrand@systella.=
fr> wrote:
>
> Ryota Ozaki a =C3=A9crit :
> > On Wed, Jan 4, 2023 at 6:45 PM BERTRAND Jo=C3=ABl <joel.bertrand@systel=
la.fr> wrote:
> >>
> >> I have tested your configuration between my VM (OpenVPN client=
) and
> >> host that runs this VM (OpenVPN server).
> >>
> >> Thus client and server run on the same physical workstation. S=
erver in
> >> host (Linux devuan/testing), client in KVM guest (NetBSD 10.0). I use
> >> TCP to avoid NAT issue. Of course, I have checked that packets are not
> >> blocked.
> >>
> >> Server:
> >> Root hilbert:[~] > openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2
> >> --verb 10 --proto tcp-server
> >>
> >> Client:
> >> netbsd-test1# openvpn --remote 192.168.10.103 --dev tun1 --ifconfig
> >> 10.4.0.2 10.4.0.1 --verb 10 --float --ping 10 --proto tcp-client
> >>
> >> I can ping server from client and client from server.
> >
> > Good. Thank you for testing.
>
> You're welcome.
>
> <snip>
>
> >
> > So packets are sent to a peer and dropped at tun1 (or somewhere)
> > on a peer, right? Could you show me the output of ifconfig -v tun1?
>
> I can, of course.
>
> legendre# ifconfig -v tun1
> tun1: flags=3D0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
> status: active
> input: 164 packets, 13728 bytes
> output: 0 packets, 0 bytes
> inet6 fe80::b696:91ff:fe92:776e%tun1/64 -> flags 0 scopeid 0xb
> inet 10.4.0.1/32 -> 10.4.0.2 flags 0
>
> #netbsd-test1# ifconfig -v tun1
> tun1: flags=3D0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
> status: active
> input: 0 packets, 0 bytes
> output: 164 packets, 14384 bytes
> inet6 fe80::a8c4:9abe:2575:9256%tun1/64 -> flags 0 scopeid 0x3
> inet 10.4.0.2/32 -> 10.4.0.1 flags 0
>
> Running configuration is :
>
> Server:
> legendre# openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 10
> --proto tcp-server
>
> Client (netbsd in KVM)
> netbsd-test1# openvpn --remote 192.168.10.128 --dev tun1 --ifconfig
> 10.4.0.2 10.4.0.1 --proto tcp-client --verb 10 --float --ping 10
>
> tcpdump -p -i eth0 on host that runs KVM virtual machine shows tr=
affic
> on port 1194/TCP.
>
> If I try to ping server, tcpdump shows :
>
> 16:38:44.006098 IP legendre.systella.fr.openvpn >
> hilbert.systella.fr.40674: Flags [.], ack 1548, win 4480, options
> [nop,nop,TS val 152 ecr 3389821985], length 0
> 16:38:44.811261 IP hilbert.systella.fr.40674 >
> legendre.systella.fr.openvpn: Flags [P.], seq 1548:1634, ack 1, win 502,
> options [nop,nop,TS val 3389822984 ecr 152], length 86
> 16:38:45.006086 IP legendre.systella.fr.openvpn >
> hilbert.systella.fr.40674: Flags [.], ack 1634, win 4480, options
> [nop,nop,TS val 154 ecr 3389822984], length 0
> 16:38:45.809397 IP hilbert.systella.fr.40674 >
> legendre.systella.fr.openvpn: Flags [P.], seq 1634:1720, ack 1, win 502,
> options [nop,nop,TS val 3389823982 ecr 154], length 86
> 16:38:46.006089 IP legendre.systella.fr.openvpn >
> hilbert.systella.fr.40674: Flags [.], ack 1720, win 4480, options
> [nop,nop,TS val 156 ecr 3389823982], length 0
>
> These TCP transaction only show ping packet. OpenVPN server doesn=
't
> answer (length 0 from legendre to hilbert).
>
> If I check packets on legendre's tun1 interface, I have:
>
> legendre# tcpdump -i tun1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decod=
e
> listening on tun1, link-type NULL (BSD loopback), capture size 262144 byt=
es
> 16:50:19.179199 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 0, length 64
> 16:50:20.192920 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 1, length 64
> 16:50:21.200582 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 2, length 64
> 16:50:22.199129 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 3, length 64
> 16:50:23.197255 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 4, length 64
> 16:50:24.204649 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 5, length 64
> 16:50:25.203051 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 6, length 64
> 16:50:26.201564 IP 10.4.0.2 > 10.4.0.1: ICMP echo request, id 46198, seq
> 7, length 64
> ^C
> 8 packets captured
> 8 packets received by filter
> 0 packets dropped by kernel
>
> Thus legendre receives ping packets from VM and doesn't answer.
>
> > If packets are not dropped at tun1, we may be able to see packet drops
> > with netstat -s.
>
> netstat -s | grep drop output is not affected by ping 10.4.0.1.
Oh, sorry. You also need to grep with "discard" to see all packet drops.
Anyway thank you for the outputs and the explanation on the other reply.
I've got the situation.
I have one question. Does this issue happen with a vanilla kernel?
Or only with your custom kernel?
ozaki-r
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Thu, 5 Jan 2023 07:49:58 +0100
Ryota Ozaki a écrit :
> Oh, sorry. You also need to grep with "discard" to see all packet drops.
Main server:
legendre# netstat -s | grep discard
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 output packets discarded due to no route
0 output packets discarded due to reject route
0 packets discarded for bad interface
0 packets discarded for wrong TTL
0 packets discarded for bad checksum
0 packets discarded with a bad version
0 discarded because packet was too short
0 packets discarded for bad authentication
0 packets discarded for bad vhid
0 packets discarded because of a bad address list
276 output packets discarded due to no route
0 packets discarded due to too many headers
0 output packets discarded due to reject route
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
VM:
netbsd-test1# netstat -s | grep discard
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 output packets discarded due to no route
0 output packets discarded due to reject route
0 packets discarded for bad interface
0 packets discarded for wrong TTL
0 packets discarded for bad checksum
0 packets discarded with a bad version
0 discarded because packet was too short
0 packets discarded for bad authentication
0 packets discarded for bad vhid
0 packets discarded because of a bad address list
0 output packets discarded due to no route
0 packets discarded due to too many headers
0 output packets discarded due to reject route
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
> Anyway thank you for the outputs and the explanation on the other reply.
> I've got the situation.
>
> I have one question. Does this issue happen with a vanilla kernel?
> Or only with your custom kernel?
legendre runs with a customized kernel (GENERIC + altq + iscsi).
netbsd-test1 runs with a GENERIC kernel (from iso install image).
Regards,
JKB
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Thu, 5 Jan 2023 19:45:48 +0900
On Thu, Jan 5, 2023 at 3:50 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella.f=
r> wrote:
>
> Ryota Ozaki a =C3=A9crit :
> > Oh, sorry. You also need to grep with "discard" to see all packet drop=
s.
>
> Main server:
>
> legendre# netstat -s | grep discard
> 0 discarded for bad checksums
> 0 discarded for bad header offset fields
> 0 discarded because packet too short
> 0 output packets discarded due to no route
> 0 output packets discarded due to reject route
> 0 packets discarded for bad interface
> 0 packets discarded for wrong TTL
> 0 packets discarded for bad checksum
> 0 packets discarded with a bad version
> 0 discarded because packet was too short
> 0 packets discarded for bad authentication
> 0 packets discarded for bad vhid
> 0 packets discarded because of a bad address list
> 276 output packets discarded due to no route
> 0 packets discarded due to too many headers
> 0 output packets discarded due to reject route
> 0 discarded for bad checksums
> 0 discarded for bad header offset fields
> 0 discarded because packet too short
>
> VM:
>
> netbsd-test1# netstat -s | grep discard
> 0 discarded for bad checksums
> 0 discarded for bad header offset fields
> 0 discarded because packet too short
> 0 output packets discarded due to no route
> 0 output packets discarded due to reject route
> 0 packets discarded for bad interface
> 0 packets discarded for wrong TTL
> 0 packets discarded for bad checksum
> 0 packets discarded with a bad version
> 0 discarded because packet was too short
> 0 packets discarded for bad authentication
> 0 packets discarded for bad vhid
> 0 packets discarded because of a bad address list
> 0 output packets discarded due to no route
> 0 packets discarded due to too many headers
> 0 output packets discarded due to reject route
> 0 discarded for bad checksums
> 0 discarded for bad header offset fields
> 0 discarded because packet too short
Thanks.
"packets discarded due to no route" may be related to the issue,
but I'm not sure for now.
>
>
> > Anyway thank you for the outputs and the explanation on the other repl=
y.
> > I've got the situation.
> >
> > I have one question. Does this issue happen with a vanilla kernel?
> > Or only with your custom kernel?
>
> legendre runs with a customized kernel (GENERIC + altq + iscsi).
> netbsd-test1 runs with a GENERIC kernel (from iso install image).
I've tried a kernel with the same configuration. It seems to me that
ALTQ and iscsi are not related to the issue.
Anyway I've finally found a setup to reproduce the issue (or something).
At least it's a regression.
It's a tap version of your simple setup:
[server] openvpn --dev tap --ifconfig 10.4.0.1 255.255.255.0 --verb 1
--local 10.6.0.9 --proto tcp-server
[client] openvpn --remote 10.6.0.9 --dev tap --ifconfig 10.4.0.2
255.255.255.0 --proto tcp-client --verb 1 --float --ping 10
It works with NetBSD 9 & Linux, however, doesn't work with NetBSD 10 & Linu=
x
and NetBSD 10 & NetBSD 9.
I haven't reproduced the issue with tun but anyway I'm investigating the is=
sue
with the setup first.
Thanks,
ozaki-r
From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57155 CVS commit: src/sys/net
Date: Fri, 6 Jan 2023 01:54:23 +0000
Module Name: src
Committed By: ozaki-r
Date: Fri Jan 6 01:54:23 UTC 2023
Modified Files:
src/sys/net: if_tap.c
Log Message:
tap: link up an interface cloned from /dev/tap
Fix PR 57155 (partially)
To generate a diff of this commit:
cvs rdiff -u -r1.127 -r1.128 src/sys/net/if_tap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Fri, 6 Jan 2023 15:03:26 +0900
On Thu, Jan 5, 2023 at 7:45 PM Ryota Ozaki <ozaki-r@netbsd.org> wrote:
>
> On Thu, Jan 5, 2023 at 3:50 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella=
.fr> wrote:
> >
> > Ryota Ozaki a =C3=A9crit :
> > > Oh, sorry. You also need to grep with "discard" to see all packet dr=
ops.
> >
> > Main server:
> >
> > legendre# netstat -s | grep discard
> > 0 discarded for bad checksums
> > 0 discarded for bad header offset fields
> > 0 discarded because packet too short
> > 0 output packets discarded due to no route
> > 0 output packets discarded due to reject route
> > 0 packets discarded for bad interface
> > 0 packets discarded for wrong TTL
> > 0 packets discarded for bad checksum
> > 0 packets discarded with a bad version
> > 0 discarded because packet was too short
> > 0 packets discarded for bad authentication
> > 0 packets discarded for bad vhid
> > 0 packets discarded because of a bad address list
> > 276 output packets discarded due to no route
> > 0 packets discarded due to too many headers
> > 0 output packets discarded due to reject route
> > 0 discarded for bad checksums
> > 0 discarded for bad header offset fields
> > 0 discarded because packet too short
> >
> > VM:
> >
> > netbsd-test1# netstat -s | grep discard
> > 0 discarded for bad checksums
> > 0 discarded for bad header offset fields
> > 0 discarded because packet too short
> > 0 output packets discarded due to no route
> > 0 output packets discarded due to reject route
> > 0 packets discarded for bad interface
> > 0 packets discarded for wrong TTL
> > 0 packets discarded for bad checksum
> > 0 packets discarded with a bad version
> > 0 discarded because packet was too short
> > 0 packets discarded for bad authentication
> > 0 packets discarded for bad vhid
> > 0 packets discarded because of a bad address list
> > 0 output packets discarded due to no route
> > 0 packets discarded due to too many headers
> > 0 output packets discarded due to reject route
> > 0 discarded for bad checksums
> > 0 discarded for bad header offset fields
> > 0 discarded because packet too short
>
> Thanks.
>
> "packets discarded due to no route" may be related to the issue,
> but I'm not sure for now.
>
> >
> >
> > > Anyway thank you for the outputs and the explanation on the other re=
ply.
> > > I've got the situation.
> > >
> > > I have one question. Does this issue happen with a vanilla kernel?
> > > Or only with your custom kernel?
> >
> > legendre runs with a customized kernel (GENERIC + altq + iscsi)=
.
> > netbsd-test1 runs with a GENERIC kernel (from iso install image).
>
> I've tried a kernel with the same configuration. It seems to me that
> ALTQ and iscsi are not related to the issue.
>
> Anyway I've finally found a setup to reproduce the issue (or something).
> At least it's a regression.
>
> It's a tap version of your simple setup:
> [server] openvpn --dev tap --ifconfig 10.4.0.1 255.255.255.0 --verb 1
> --local 10.6.0.9 --proto tcp-server
> [client] openvpn --remote 10.6.0.9 --dev tap --ifconfig 10.4.0.2
> 255.255.255.0 --proto tcp-client --verb 1 --float --ping 10
>
> It works with NetBSD 9 & Linux, however, doesn't work with NetBSD 10 & Li=
nux
> and NetBSD 10 & NetBSD 9.
>
> I haven't reproduced the issue with tun but anyway I'm investigating the =
issue
> with the setup first.
I've fixed a regression of tap. Could you try the fix (if_tap.c,v 1.128)?
Thanks,
ozaki-r
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: Ryota Ozaki <ozaki-r@netbsd.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Fri, 6 Jan 2023 08:01:00 +0100
Ryota Ozaki a écrit :
> On Thu, Jan 5, 2023 at 7:45 PM Ryota Ozaki <ozaki-r@netbsd.org> wrote:
>
> I've fixed a regression of tap. Could you try the fix (if_tap.c,v 1.128)?
Thanks. I don't find this patch for -10.0. I suppose this patch is
against -current. I will try as soon as possible.
Regards,
JKB
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Fri, 6 Jan 2023 09:12:06 +0100
Tested.
Your patch fix issue with tap. Now, server on LAN can ping IPv6 servers
on WAN through OpenVPN/TAP link and OpenVPN client can ping OpenVPN server.
Regards,
JKB
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Fri, 6 Jan 2023 18:18:07 +0900
On Fri, Jan 6, 2023 at 5:12 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella.f=
r> wrote:
>
> Tested.
>
> Your patch fix issue with tap. Now, server on LAN can ping IPv6 s=
ervers
> on WAN through OpenVPN/TAP link and OpenVPN client can ping OpenVPN serve=
r.
Thanks!
The fix has been requested to pull up to the netbsd-10 branch. It will
be merged soon.
BTW the investigation of the issue of tun would take a little time as
I'm not successful
in reproducing the issue.
ozaki-r
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Fri, 6 Jan 2023 11:08:10 +0100
Ryota Ozaki a écrit :
> Thanks!
You're welcome.
> The fix has been requested to pull up to the netbsd-10 branch. It will
> be merged soon.
>
> BTW the investigation of the issue of tun would take a little time as
> I'm not successful
> in reproducing the issue.
Strange. In my configuration, tun and tap trigger the same issue...
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57155 CVS commit: [netbsd-10] src/sys/net
Date: Fri, 6 Jan 2023 13:54:58 +0000
Module Name: src
Committed By: martin
Date: Fri Jan 6 13:54:58 UTC 2023
Modified Files:
src/sys/net [netbsd-10]: if_tap.c
Log Message:
Pull up following revision(s) (requested by ozaki-r in ticket #38):
sys/net/if_tap.c: revision 1.128
tap: link up an interface cloned from /dev/tap
Fix PR 57155 (partially)
To generate a diff of this commit:
cvs rdiff -u -r1.127 -r1.127.4.1 src/sys/net/if_tap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Sat, 7 Jan 2023 10:07:01 +0100
BERTRAND Joël a écrit :
> The following reply was made to PR kern/57155; it has been noted by GNATS.
>
> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
> To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org
> Cc:
> Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
> 10.0_BETA
> Date: Fri, 6 Jan 2023 11:08:10 +0100
>
> Ryota Ozaki a écrit :
> > Thanks!
>
> You're welcome.
>
> > The fix has been requested to pull up to the netbsd-10 branch. It will
> > be merged soon.
> >
> > BTW the investigation of the issue of tun would take a little time as
> > I'm not successful
> > in reproducing the issue.
>
> Strange. In my configuration, tun and tap trigger the same issue...
I have a simple configuration that triggers this issue with tun interface.
Server : NetBSD 10.0 BETA
openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 1
Client (KVM guest that runs on a Linux workstation)
openvpn --remote 192.168.10.128 -dev tun1 --ifconfig 10.4.0.2 10.4.0.1
--verb 1 --float
netbsd-test1# ping 10.4.0.1
PING 10.4.0.1 (10.4.0.1): 56 data bytes
^C
----10.4.0.1 PING Statistics----
167 packets transmitted, 0 packets received, 100.0% packet loss
On both sides, tun1 are up:
tun1: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
status: active
inet6 fe80::a8c4:9abe:2575:9256%tun1/64 -> flags 0 scopeid 0x3
inet 10.4.0.2/32 -> 10.4.0.1 flags 0
tun1: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
status: active
inet6 fe80::b696:91ff:fe92:776e%tun1/64 -> flags 0 scopeid 0xb
inet 10.4.0.1/32 -> 10.4.0.2 flags 0
tcpdump doesn't show packet over tun1 interfaces and ping from server
returns:
legendre# ping 10.4.0.2
PING 10.4.0.2 (10.4.0.2): 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
Route shows a direct route between server and client:
Internet:
Destination Gateway Flags Refs Use Mtu
Interface
default 192.168.15.20 UGS - - - wm2
10.4.0.1 tun1 UHl - - - lo0
10.4.0.2 10.4.0.1 UH - - - tun1
Why is 10.4.0.2 unreachable ?
When I did this tests, my VM paniced:
netbsd-test1# tcpdump -i tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type NULL (BSD loopback), capture size 262144 bytes
09:37:36.390979 IP3
[ 45267.1600841] panic: /: bad dir ino 710294 at offset 0: null entry
[ 45267.1862048] cpu0: Begin traceback...
[ 45267.2093217] vpanic() at netbsd:vpanic+0x183
[ 45267.2093217] panic() at netbsd:panic+0x3c
[ 45267.2211092] ufs_lookup() at netbsd:ufs_lookup+0x483
[ 45267.2559776] VOP_LOOKUP() at netbsd:VOP_LOOKUP+0x44
[ 45267.2700992] lookup_once() at netbsd:lookup_once+0x1a6
[ 45267.3000843] namei_tryemulroot() at netbsd:namei_tryemulroot+0xb00
[ 45267.3261770] namei() at netbsd:namei+0x29
[ 45267.3301437] do_sys_statat() at netbsd:do_sys_statat+0x1db
[ 45267.3301437] sys___lstat50() at netbsd:sys___lstat50+0x25
[ 45267.3301437] syscall() at netbsd:syscall+0x196
[ 45267.3414466] --- syscall (number 441) ---
[ 45267.3414466] netbsd:syscall+0x196:
[ 45267.3414466] cpu0: End traceback...
[ 45267.3972324] dumping to dev 168,2 (offset=1983, size=260872):
[ 45267.3972324] dump 351 350 349 348 347 346 345 344 343 342 341 340
339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324
I will try to obtain more information about this panic. This VM has
slow disks as disks images are located on a NAS exported by NFSv3/TCP.
Best regards,
JKB
From: Martin Husemann <martin@duskware.de>
To: BERTRAND =?iso-8859-1?Q?Jo=EBl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on
10.0_BETA
Date: Sat, 7 Jan 2023 13:31:50 +0100
On Sat, Jan 07, 2023 at 10:07:01AM +0100, BERTRAND Joël wrote:
> [ 45267.1600841] panic: /: bad dir ino 710294 at offset 0: null entry
You need to boot that machine single user and do something like:
fsck -fy /
(leave out the y and deal with single issues manually if you are not sure
or there is very impotant not-backuped data on the file system).
Martin
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA
Date: Tue, 10 Jan 2023 16:50:33 +0900
On Sat, Jan 7, 2023 at 6:07 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella.f=
r> wrote:
>
> BERTRAND Jo=C3=ABl a =C3=A9crit :
> > The following reply was made to PR kern/57155; it has been noted by GNA=
TS.
> >
> > From: =3D?UTF-8?Q?BERTRAND_Jo=3Dc3=3Dabl?=3D <joel.bertrand@systella.fr=
>
> > To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netb=
sd.org,
> > netbsd-bugs@netbsd.org
> > Cc:
> > Subject: Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected =
on
> > 10.0_BETA
> > Date: Fri, 6 Jan 2023 11:08:10 +0100
> >
> > Ryota Ozaki a =C3=83=C2=A9crit=C3=82 :
> > > Thanks!
> >
> > You're welcome.
> >
> > > The fix has been requested to pull up to the netbsd-10 branch. It w=
ill
> > > be merged soon.
> > >
> > > BTW the investigation of the issue of tun would take a little time =
as
> > > I'm not successful
> > > in reproducing the issue.
> >
> > Strange. In my configuration, tun and tap trigger the same issue.=
..
openvpn with tap didn't work because tap's link wasn't up on creation.
It seems that tun doesn't have such a defeat, so tun needs some other fix.
>
> I have a simple configuration that triggers this issue with tun i=
nterface.
>
> Server : NetBSD 10.0 BETA
> openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 1
>
> Client (KVM guest that runs on a Linux workstation)
> openvpn --remote 192.168.10.128 -dev tun1 --ifconfig 10.4.0.2 10.4.0.1
> --verb 1 --float
>
> netbsd-test1# ping 10.4.0.1
> PING 10.4.0.1 (10.4.0.1): 56 data bytes
> ^C
> ----10.4.0.1 PING Statistics----
> 167 packets transmitted, 0 packets received, 100.0% packet loss
>
> On both sides, tun1 are up:
>
> tun1: flags=3D0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
> status: active
> inet6 fe80::a8c4:9abe:2575:9256%tun1/64 -> flags 0 scopeid 0x3
> inet 10.4.0.2/32 -> 10.4.0.1 flags 0
>
> tun1: flags=3D0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
> status: active
> inet6 fe80::b696:91ff:fe92:776e%tun1/64 -> flags 0 scopeid 0xb
> inet 10.4.0.1/32 -> 10.4.0.2 flags 0
>
> tcpdump doesn't show packet over tun1 interfaces and ping from se=
rver
> returns:
> legendre# ping 10.4.0.2
> PING 10.4.0.2 (10.4.0.2): 56 data bytes
> ping: sendto: Network is unreachable
> ping: sendto: Network is unreachable
> ping: sendto: Network is unreachable
> ping: sendto: Network is unreachable
>
> Route shows a direct route between server and client:
>
> Internet:
> Destination Gateway Flags Refs Use Mtu
> Interface
> default 192.168.15.20 UGS - - - wm2
> 10.4.0.1 tun1 UHl - - - lo0
> 10.4.0.2 10.4.0.1 UH - - - tun1
>
> Why is 10.4.0.2 unreachable ?
The error message is shown when ENETUNREACH is returned on sending
a packet. In this case normally "output packets discarded due to no route"
of netstat -s is increased. Do you see the increment?
If not, can you check if npf drops packets? npf is another candidate for
a packet blocker.
Thanks,
ozaki-r
(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-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.