Does OpenVPN change the persistent route?

martinsalo

Hello Forum,

I have my own Kill Switch configuration on debian linux.
1. Direct the default route towards an unused IP. (Nirvana IP)
2. Create a special persistent route that leads the way only for the OpenVPN Server IP through my internet access router.

When the OpenVPN client starts, it connects correctly with the OpenVPN server (Initialization Sequence Completed) but then the special persistent route leads towards the Nirvana IP like the default route! No internet access is possible. So I have to remove the route manually and recreate it to get the OpenVPN tunnel working. The special persistent route does not change if I use route-noexec in the client config file. Quick&Dirty I have used the route_up and route_down scripts in the .ovpn client file to set up the routes manually.

This error did not happen on Debian Linux 10.11 (and earlier versions). The installed OpenVPN version is: 2.4.7 x86_64-pc-linux-gnu
The newest Netinstall Debian (Version 11.2) installs OpenVPN 2.5.1 x86_64-pc-linux-gnu

Thanks

Martin

TinCanTech

If you are using --route-noexec then all bets are off.

openvpn_inc

Hi Martin,

If you would like help with this, please show us what you are seeing. Best place to start:

ip addr list
ip route list

... on both client and server; as well as complete server & client configurations.

My WAG at this point is that the blackhole/blocking route has a lower metric than the one set by openvpn.

regards, rob0

martinsalo

On my client VM, I have a default route towards an unused IP (192.168.1.77) and a persistent route that makes the OpenVPN server (33.44.55.66) accessible via my HW router (192.168.1.1). If the VPN breaks down no traffic leaks into the internet. Now I have created a new VM with the newest Debian netinstall ISO and after starting the OpenVPN client the persistent route also directs towards the unused IP. This behavior is new! The OpenVPN client shows me "Initialization Sequence Completed" but then I get the the "process restarting" messages. -> No internet access. If I remove the persistent route and recreate it with my HW router as target, the OpenVPN client reconnects and all works fine.

Why is the persistent route touched? On my old VM with Debian Version 10.11 and OpenVPN 2.4.7 the persistent route stays the way like is is configured in the /etc/network/interfaces.

######################### Client side (Debian 11.2, OpenVPN 2.5.1): ################################

root@XXX:~# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens45: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    altname enp2s1
    inet 192.168.1.247/24 brd 192.168.1.255 scope global ens45
       valid_lft forever preferred_lft forever
    inet6 xxxx::xxxx/64 scope link
       valid_lft forever preferred_lft forever

# If I start the VM, this is the output of "ip route"
root@XXX:~# ip route list
# The default route leads to an IP that is not taken. So this computer cannot reach the internet:
default via 192.168.1.77 dev ens45 onlink
# This is a persistent route that makes the VPN server IP be reachable via my HW router.
# From this machine only this Internet IP (33.44.55.66) can be reached!
33.44.55.66 via 192.168.1.1 dev ens45
192.168.1.0/24 dev ens45 proto kernel scope link src 192.168.1.247

# Now I start OpenVPN with my dirty solution
root@XXX:~# ip route list
default via 10.8.0.1 dev tun0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
# The OpenVPN router can still be reached via my HW router!
33.44.55.66 via 192.168.1.1 dev ens45
192.168.1.0/24 dev ens45 proto kernel scope link src 192.168.1.247

# If I remove my dirty solution and start the OpenVPN client, the persistent route points to the unused IP.
# OpenVPN returns "Initialization Sequence Completed" but then "SIGUSR1[soft,tls-error] received, process restarting"
root@XXX:~# ip route list
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.1.77 dev ens45 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
128.0.0.0/1 via 10.8.0.1 dev tun0
# Why is the persitent changed towards the 77?
33.44.55.66 via 192.168.1.77 dev ens45
192.168.1.0/24 dev ens45 proto kernel scope link src 192.168.1.247

# I use the same client.ovpn file (without the dirty solution of course) on my old VM with 
# Debian Version 10.11 and OpenVPN 2.4.7. The persitent route stays untouched after starting the VPN:
root@XXX:~# ip route list
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.1.77 dev ens45 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
128.0.0.0/1 via 10.8.0.1 dev tun0
33.44.55.66 via 192.168.1.1 dev ens45
192.168.1.0/24 dev ens45 proto kernel scope link src 192.168.1.245

client
dev tun
proto udp
remote 33.44.55.66 1049
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

REMARK: I added the following 4 lines (:=dirty solution) to correct the broken persistent route:
route-noexec
script-security 2
up /etc/update_routes_vpn_up.sh
down /etc/update_routes_vpn_dn.sh

REMARK: The up script replaces the default route and resets the persitent route and the dn script undos it.
REMARK: up script:
REMARK: ip route del default
REMARK: ip route add default via "$route_vpn_gateway" dev "$dev"
REMARK: ip route del 33.44.55.66/32
REMARK: ip route add 33.44.55.66/32 via 192.168.1.1 dev ens45

<ca>
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
XXX
-----END PRIVATE KEY-----
</key>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
XXX
-----END OpenVPN Static key V1-----
</tls-crypt>

######################### Server side (Debian 10.11, OpenVPN 2.4.7): ################################

root@XXX:~# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/void
    inet 127.0.0.1/32 scope host venet0
       valid_lft forever preferred_lft forever
    inet 10.10.xx.xx/32 brd 10.10.xx.xx scope global venet0:0
       valid_lft forever preferred_lft forever
    inet6 xxxx::xxxx/80 scope global
       valid_lft forever preferred_lft forever
    inet6 ::2/128 scope global
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 xxxx::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 xxxx::xxxx/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

root@XXX:~# ip route
default dev venet0 scope link
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1

local 10.10.xx.xx
port 1049
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
server-ipv6 xxxx::/64
push "redirect-gateway def1 ipv6 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify

TinCanTech

martinsalo wrote REMARK: I added the following 4 lines (:=dirty solution) to correct the broken persistent route:
route-noexec
script-security 2
up /etc/update_routes_vpn_up.sh
down /etc/update_routes_vpn_dn.sh
REMARK: The up script replaces the default route and resets the persitent route and the dn script undos it.
REMARK: up script:
REMARK: ip route del default
REMARK: ip route add default via "$route_vpn_gateway" dev "$dev"
REMARK: ip route del 33.44.55.66/32
REMARK: ip route add 33.44.55.66/32 via 192.168.1.1 dev ens45

This is exactly the same as: redirect-gateway def1 ..

martinsalo

redirect-gateway
redirect-gateway def1
redirect-gateway autolocal

It all leads to this route after starting openvpn with a none working internet connection:
33.44.55.66 via 192.168.1.77 dev ens45

My solution behind the REMARKS results into this route with a working internet connection:
33.44.55.66 via 192.168.1.1 dev ens45

It seems this new behavior is unknown. There is no elegant solution. So I have to create my own routes via script. Then it is like it is.

TinCanTech

Openvpn only works with correctly setup networks.

Because you have a fake default route, you must configure openvpn manually.