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