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: 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: Wed, 4 Jan 2023 12:01:45 +0100
Ryota Ozaki a écrit :
> 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: Wed, 4 Jan 2023 19:28:52 +0900
>
> On Wed, Jan 4, 2023 at 4:57 PM Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> >
> > On Wed, Jan 4, 2023 at 4:30 PM BERTRAND Jo=C3=ABl <joel.bertrand@systella=
> .fr> wrote:
> > >
> > > Ryota Ozaki a =C3=A9crit :
> > > > I've installed NetBSD 10 on Linux KVM and tested with them. The gue=
> st
> > > > is under NAT in my setup. OpenVPN is installed via pkg_add.
> > >
> > > I have seen this issue on my main server (that was installed wi=
> th 7.2
> > > if I remember and upgraded until 10_BETA) and on a fresh install in a V=
> M
> > > (KVM). I have built openvpn from pkgsrc.
> > >
> > > > netbsd10# uname -a
> > > > NetBSD netbsd10 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Sat Dec 31
> > > > 04:55:53 UTC 2022
> > > > mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC
> > > > amd64
> > > > netbsd10# pkg_info openvpn |head -1
> > > > Information for openvpn-2.5.7nb1:
> > >
> > > Mine is OpenVPN 2.5.8 (on both systems).
> > >
> > > > With the simple openvpn setups below, ping between the client and th=
> e serve=3D
> > > > r
> > > > works for me.
> > > >
> > > > [host]
> > > > openvpn --remote 192.168.122.11 --dev tun1 --ifconfig 10.4.0.1 10.4.=
> 0.2 --v=3D
> > > > erb 1
> > > >
> > > > [guest]
> > > > openvpn --remote 192.168.0.100 --dev tun1 --ifconfig 10.4.0.2 10.4.0=
> .1
> > > > --verb 1 --float --ping 10
> > > >
> > > > [ping from guest]
> > > > netbsd10# ping -n -c 1 10.4.0.1
> > > > PING 10.4.0.1 (10.4.0.1): 56 data bytes
> > > > 64 bytes from 10.4.0.1: icmp_seq=3D3D0 ttl=3D3D64 time=3D3D1.250718 =
> ms
> > > >
> > > > ----10.4.0.1 PING Statistics----
> > > > 1 packets transmitted, 1 packets received, 0.0% packet loss
> > > > round-trip min/avg/max/stddev =3D3D 1.250718/1.250718/1.250718/0.000=
> 000 ms
> > >
> > > Client configuration:
> > >
> > > rport 1194
> > > lport 1194
> > > proto udp
> > > dev tun (or dev tap)
> > > remote xxx.yyy.zzz.ttt
> > > float
> > > client
> > > tls-client
> > > remote-cert-tls server
> > > ca ...
> > > cert ...
> > > key ...
> > > comp-lzo adaptative
> > > verb 3
> > > keepalive 5 30
> > > passtos
> > >
> > > Note that
> > >
> > > > The difference of the results may come from differences between my a=
> nd your
> > > > environments. My NetBSD 10 is fresh and doesn't enable networking
> > > > services/daemons that affect the result other than openvpn.
> > >
> > > I can understand daemons can produce this issue, but in my VM, =
> I only
> > > have installed a system from official BETA 10.0 iso and only added open=
> vpn.
> >
> > ok, I'm trying to set up the same openvpn configuration as yours.
>
> I've set up and tested.
>
> The configurations of client/server are like those:
>
> [server]
>
> port 1194
> proto udp
> dev tun
>
> ca ca.crt
> cert servername.crt
> key servername.key
> dh none
>
> server 10.4.0.0 255.255.255.0
> keepalive 10 120
> tls-server
>
> verb 3
>
> [client]
>
> rport 1194
> lport 1194
> proto udp
> dev tun
> remote 192.168.0.100
> float
> client
> tls-client
> remote-cert-tls server
> ca ca.crt
> cert client1.crt
> key client1.key
> #comp-lzo adaptative
> verb 3
> keepalive 5 30
> passtos
>
>
> The configuration doesn't set up fixed IP addresses for client/server.
> so end-point addresses of tun interfaces are not symmetric.
>
> server: 10.4.0.1 -> 10.4.0.2
> client: 10.4.0.6 -> 10.4.0.5
>
> Anyway the client can ping to 10.4.0.1 and the server can ping to 10.4.0.6.
>
> ozaki-r
>
>
I suppose you try to configure OpenVPN between a guest running in a VM
and host. In my case, this configuration runs fine. But when server and
client are on different machines, VPN remains up but all trafics are
blocked. Please not that if I configure a LAN behind OpenVPN client
(with NAT), all systems on this LAN can ping server. And server can ping
this workstations through OpenVPN client!
I have seen this issue first time on my main server (legendre) with the
following configuration:
- bridge 0 (wm0/wm1): NAS [192.168.12.1/24]
- lagg0 (wm3/wm3): LAN [192.168.10.128/24]
- wm2: WAN
- tap0: OpenVPN client (server is accessible through wm2) [192.168.1.1/24]
legendre# ifconfig tap0
tap0: flags=0x8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
ec_enabled=0
address: f2:0b:a4:38:bb:42
status: no carrier
inet6 2001:7a8:a8ed:1::2/64 flags 0x8<DETACHED>
inet6 fe80::f00b:a4ff:fe38:bb42%tap0/64 flags 0x8<DETACHED>
scopeid 0x9
inet 192.168.1.2/24 broadcast 192.168.1.255 flags 0x4<DETACHED>
legendre# ifconfig lagg0
lagg0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=0x7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
capabilities=0x7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
capabilities=0x7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
enabled=0
ec_capabilities=0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
ec_enabled=0x2<VLAN_HWTAGGING>
laggproto loadbalance
laggport:
wm3 pri=32768 flags=0x1c<ACTIVE,COLLECTING,DISTRIBUTING>
wm4 pri=32768 flags=0x1c<ACTIVE,COLLECTING,DISTRIBUTING>
address: 68:05:ca:02:b2:59
status: active
inet6 fe80::6a05:caff:fe02:b259%lagg0/64 flags 0 scopeid 0x8
inet6 2001:7a8:a8ed:10::128/64 flags 0
inet 192.168.10.128/24 broadcast 192.168.10.255 flags 0
This OpenVPN client cannot ping OpenVPN server:
Rayleigh tap0 (OpenVPN server) address is 192.168.1.1. I will use
numerical address for rayleigh as DNS is broken (views are configured
and are only seen through tap0).
Please note:
- legendre (192.168.1.2): OpenVPN client
- rayleigh (192.168.1.1): OpenVPN server
- fermat (192.168.10.107): OpenVMS server on LAN
- hilbert (192.168.10.103): Linux server on LAN
legendre# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
^C
----192.168.1.1 PING Statistics----
3 packets transmitted, 0 packets received, 100.0% packet loss
legendre#
On LAN, I have several workstations. For example, hilbert. Hilbert can
ping 192.168.1.1:
hilbert:[~] > ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=55.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=53.4 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=53.4 ms
^C
OpenVPN server (rayleigh, address 192.168.1.1) can ping hilbert (Linux,
address 192.168.10.103 through tap0) or fermat (OpenVMS, address
192.168.10.107 through tap0) but not legendre (NetBSD 10 OpenVPN client,
address 192.168.1.2):
rayleigh:[~] > ping hilbert
PING hilbert.systella.fr (192.168.10.103) 56(84) bytes of data.
64 bytes from hilbert.systella.fr (192.168.10.103): icmp_seq=1 ttl=63
time=54.6 ms
64 bytes from hilbert.systella.fr (192.168.10.103): icmp_seq=2 ttl=63
time=51.6 ms
^C
rayleigh:[~] > ping fermat
PING fermat.systella.fr (192.168.10.107) 56(84) bytes of data.
64 bytes from fermat.systella.fr (192.168.10.107): icmp_seq=1 ttl=63
time=71.7 ms
^C
rayleigh:[~] > ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
^C
--- 192.168.1.2 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12054ms
More generally, OpenVPN server routes a IPv4 /28 public addresses
through tap0 to access to LAN server and all servers on LAN are
accessible from WAN through tap0.
Legendre (OpenVPN client) is the hilbert's default IPv4 route:
hilbert:[~] > /sbin/route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default legendre.systel 0.0.0.0 UG 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
hilbert:[~] >
On legendre, route are:
legendre# route show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu
Interface
default 192.168.15.20 UGS - - - wm2
dns.google 192.168.15.19 UGHS - - - wm2
dns.google 192.168.15.20 UGHS - - - wm2
79.170.216.0/28 192.168.1.1 UGS - - - tap0
91.196.180.225 192.168.1.1 UGHS - - - tap0
127/8 localhost UGRS - - 33624 lo0
localhost lo0 UHl - - 33624 lo0
www.nerim.com 192.168.15.20 UGHS - - - wm2
192.168.0/24 192.168.1.1 UGS - - - tap0
192.168.1/24 link#9 UC - - - tap0
192.168.1.2 link#9 UHl - - - lo0
192.168.2/24 192.168.1.1 UGS - - - tap0
192.168.10/24 link#8 UC - - - lagg0
192.168.10.128 link#8 UHl - - - lo0
192.168.12/24 link#1 UC - - - wm0
192.168.12.1 link#1 UHl - - - lo0
192.168.15/24 link#3 UC - - - wm2
legendre link#3 UHl - - - lo0
192.168.253/24 192.168.1.1 UGS - - - tap0
192.168.254/24 192.168.1.1 UGS - - - tap0
192.168.1.1 32:f3:6d:94:8c:9b UHL - - - tap0
192.168.10.102 38:2c:4a:70:14:d1 UHL - - - lagg0
192.168.10.103 d4:5d:64:b4:9a:3b UHL - - - lagg0
192.168.10.101 d8:cb:8a:35:21:95 UHL - - - lagg0
192.168.10.107 08:00:2b:7a:39:2e UHL - - - lagg0
192.168.10.104 b8:27:eb:a3:dd:a8 UHL - - - lagg0
192.168.10.250 88:75:56:07:d4:08 UHL - - - lagg0
192.168.10.253 34:db:fd:5d:1e:88 UHL - - - lagg0
192.168.15.20 60:a4:b7:73:c9:26 UHL - - - wm2
192.168.12.2 24:5e:be:3b:96:e9 UHL - - - wm0
192.168.12.3 24:5e:be:14:44:57 UHL - - - wm0
Thus, packets sent by hilbert are routed through tap0 by legendre to
192.168.1.1 and OpenVPN server answers as hilbert receives packets. I
have verified that tcpdump -i tap0 shows ping and pong packets. But
legendre itself cannot send packets through tap0.
Home |
Main Index |
Thread Index |
Old Index