NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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: Ryota Ozaki <ozaki-r%netbsd.org@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: 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@localhost> 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.
 


Home | Main Index | Thread Index | Old Index