Re: kern/57155: OpenVPN (tap and tun) doesn't run as expected on 10.0_BETA

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

The following reply was made to PR kern/57155; it has been noted by GNATS.

From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= <joel.bertrand%systella.fr@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	netbsd-bugs%netbsd.org@localhost
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@localhost=
 >
 > > To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin@netb=
 sd.org,
 > >         netbsd-bugs%netbsd.org@localhost
 > > 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