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

NetBSD Home
NetBSD PR Database Search

(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.