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

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

On Sat, Jan 7, 2023 at 6:07 PM BERTRAND Joël <joel.bertrand%systella.fr@localhost> wrote:
>
> 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@localhost>
> > To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
> >         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 é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...

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 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 ?

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