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

[BERTRAND Joël <joel.bertrand%systella.fr@localhost>]

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.