Route error other than openvpn server

[langioletto]

Hi all, I have a root command problem with openvpn 2.5

On debian-10.7.0 I have not installed NET-TOOLS, because in version 2.5 there is no need

This is the contents of my configuration file: /etc/openvpn/ccd/client4

ifconfig-push 192.168.101.18 192.168.101.17
push "route 192.168.101.0 255.255.255.0 192.168.1.253"

But the push route command returns the error: "Network is unreachable, Linux route add command failed"

the ip address 192.168.1.253 is active and is pinged by the openvpn client, also because it is on the same local network

I use this setup on other clients and it works fine, the other clients have NET-TOOLS installed

Can it still be needed with openvpn version 2.5?

I am attaching the boot log file

ip a

2: enp0s12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:14:fd:12:32:f0 brd ff:ff:ff:ff:ff:ff inet 192.168.1.200/24 brd 192.168.1.255 scope global enp0s12 valid_lft forever preferred_lft forever

​https://github.com/OpenVPN/openvpn/pull/147#issuecomment-765889213

This said:  are you trying to set up a route by means of "push route"
that is not actually going towards the tun interface?  This is slightly
unusual config, but it might hint at a bug in the sitnl layer.

That's right, I'm trying to set up a push route that doesn't go to the tun interface

I report below what is done on openvpn 2.4.9

openvpn --version
OpenVPN 2.4.9 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May  9 2020
library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=no enable_plugin_down_root=no enable_plugins=no enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_x509_alt_username=no with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

I report below what is done on openvpn 2.4.9

route

Tabella di routing IP del kernel
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 enp1s0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 enp1s0
192.168.2.0     192.168.1.20    255.255.255.0   UG    0      0        0 enp1s0
192.168.101.0   192.168.1.20    255.255.255.0   UG    0      0        0 enp1s0
192.168.101.0   192.168.101.59  255.255.255.0   UG    0      0        0 tun0
192.168.101.59  0.0.0.0         255.255.255.255 UH    0      0        0 tun0

The openvpn server is set as the default gateway

192.168.101.0   192.168.101.59  255.255.255.0   UG    0      0        0 tun0

This is right, But then I inside the file: /etc/openvpn/ccd/client57 I entered the route:

push "route 192.168.101.0 255.255.255.0 192.168.1.20"

and as you can see from the route command:

192.168.101.0   192.168.1.20    255.255.255.0   UG    0      0        0 enp1s0

This works, and I change the default gateway of the VPN tunnel

This works great, so I manage everything from the file /etc/openvpn/ccd/client*

Without intervening on the various clients, But with openvpn 2.5 I found the problem I exposed at the beginning of the ticket

I attach the log

[Gert Döring]

this, indeed, seems to be a shortcoming of sitnl.

(OTOH I wonder why people are doing this in the first place - setting up routes that have nothing to do with OpenVPN by means of OpenVPN... - but since this works with iproute2, it's a regression in sitnl)

[tct]

I must be missing the point here:

192.168.101.0   192.168.1.20    255.255.255.0   UG    0      0        0 enp1s0
192.168.101.0   192.168.101.59  255.255.255.0   UG    0      0        0 tun0

because the routing looks wrong to me.

[Gert Döring]

It's unlikely that can get this fixed before 2.5.2, but it should not be forgotten - so updating the milestone.

[Gert Döring]

Replying to tincantech:

I must be missing the point here:

192.168.101.0   192.168.1.20    255.255.255.0   UG    0      0        0 enp1s0
192.168.101.0   192.168.101.59  255.255.255.0   UG    0      0        0 tun0

because the routing looks wrong to me.

Indeed, this is a strange scenario. Having the same subnet on tun and ethernet is not well-defined and should be avoided ("where should packets for 192.168.101.2 be sent to?").

The sitnl code refuses to add routes for targets that are already there as connected route, and I think that this is the correct thing to do (actually, the kernel code refuses this) - but we need a proper error message. Antonio was already volunteered to fix this.