# [SOLVED] OpenVPN & Network Manager

## mpoletiek

Hello,

I need some help setting up an OpenVPN client on a Gentoo installation using Network Manager.

I've been able to get the client to connect and work as expected, but only for a short period of time before the client loses all connectivity and the OpenVPN service needs to be restarted. 

One other symptom of losing connectivity is also the loss of routes in the client's routing tables. Once connected, the client's routing tables appear as such.

```

Razer0 /etc/openvpn # route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0

default         192.168.1.1     0.0.0.0         UG    2003   0        0 wlp2s0

10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0

142.75.82.34.bc 192.168.1.1     255.255.255.255 UGH   0      0        0 wlp2s0

128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0

192.168.1.0     0.0.0.0         255.255.255.0   U     2003   0        0 wlp2s0

```

142.75.82.34.bc is the VPN. This rule is expected per 'push "redirect-gateway def1 bypass-dhcp"' being used on the server. At this point the VPN works great. However, this doesn't last forever.

Eventually the client loses connectivity and the logs start spewing the following.

```

Fri Jan  3 21:29:50 2020 us=962750 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:51 2020 us=411057 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:51 2020 us=858473 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:51 2020 us=986563 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:51 2020 us=986643 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:54 2020 us=432469 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:54 2020 us=749937 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:54 2020 us=841492 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:55 2020 us=59022 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:55 2020 us=633473 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:55 2020 us=891524 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:56 2020 us=685264 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:56 2020 us=692623 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:57 2020 us=619066 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:57 2020 us=619149 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:58 2020 us=118444 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:58 2020 us=130692 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:58 2020 us=323650 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:59 2020 us=666489 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:29:59 2020 us=758265 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:30:00 2020 us=934291 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

Fri Jan  3 21:30:04 2020 us=274736 Recursive routing detected, drop tun packet to [AF_INET]34.82.75.142:1194

```

checking the routing table shows:

```

Razer0 ~ # route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0

default         RT-AC66U-0280.n 0.0.0.0         UG    2003   0        0 wlp2s0

10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0

128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0

192.168.1.0     0.0.0.0         255.255.255.0   U     2003   0        0 wlp2s0

```

At this point the client loses all connectivity.

I can restore connection by running the following command;

```

Razer0 ~ # route add 34.82.75.142 gw 192.168.1.1 dev wlp2s0

Razer0 ~ # ping google.com

PING google.com (74.125.142.100) 56(84) bytes of data.

64 bytes from ie-in-f100.1e100.net (74.125.142.100): icmp_seq=1 ttl=51 time=28.6 ms

```

However, eventually the client will lose connectivity again and the process must be repeated. I can't figure out whats changing the routing table. I assume its Network Manager, but I have no idea where to begin there. 

Besides the recursive routing logs on the client, neither the client or the server reports anything out of the ordinary.

Ubuntu OpenVPN Server

uname -a

```
mpoletiek@vpn:~$ uname -a

Linux vpn.skylaski.com 5.3.0-1009-gcp #10-Ubuntu SMP Fri Nov 15 07:02:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

mpoletiek@vpn:~$ 

```

server.conf

```

port 1194

proto udp

dev tun

ca skylaski/ca.crt

cert skylaski/skylaski.crt

key skylaski/skylaski.key  

dh skylaski/dh.pem

topology subnet

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist /var/log/openvpn/ipp.txt

client-config-dir ccd

route 192.168.1.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 8.8.8.8"

push "dhcp-option DNS 8.8.4.4"

client-to-client

keepalive 10 120

tls-auth skylaski/ta.key 0 

max-clients 10

user nobody

group nogroup

persist-key

persist-tun

status /var/log/openvpn/openvpn-status.log

log-append  /var/log/openvpn/openvpn.log

verb 4

explicit-exit-notify 1

```

The Gentoo Client

client.conf

```

# specify client-side

client

# tun/tap device

dev tun0

# protocol, according to server

proto udp

# server address

remote vpn.skylaski.com 1194

# connection

#comp-lzo

resolv-retry 30

nobind

# persistent device and keys

persist-key

persist-tun

# keys settings

ca razer0/ca.crt

cert razer0/razer0.crt

key razer0/razer0.key

# optional tls-auth

tls-auth razer0/ta.key 1

# pull dns settings from the server

script-security 2

# These scripts are defaults within the service script. To specify custom scripts,

# use /etc/openvpn/${SVCNAME}- {up,down}.sh as suggested by the service script.

# If you use systemd, SVCNAME will not get set automatically.

# Add `setenv SVCNAME my_svc_name` to set it, where my_svc_name is determined by

# /etc/openvpn/client/my_svc_name.conf

up /etc/openvpn/up.sh

down /etc/openvpn/down.sh

# logging

log /etc/openvpn/openvpn.log

verb 4

```

I created /etc/init.d/openvpn.client using 'ln -s' and am starting the client via;

```

/etc/init.d/openvpn.client start

```

Here is what the connection looks like from the server:

```

Sat Jan  4 05:22:05 2020 us=738960 71.238.62.116:55503 [razer0] Peer Connection Initiated with [AF_INET]71.238.62.116:55503

Sat Jan  4 05:22:05 2020 us=739156 razer0/71.238.62.116:55503 OPTIONS IMPORT: reading client specific options from: ccd/razer0

Sat Jan  4 05:22:05 2020 us=739588 razer0/71.238.62.116:55503 MULTI_sva: pool returned IPv4=10.8.0.4, IPv6=(Not enabled)

Sat Jan  4 05:22:05 2020 us=739731 razer0/71.238.62.116:55503 MULTI: Learn: 10.8.0.4 -> razer0/71.238.62.116:55503

Sat Jan  4 05:22:05 2020 us=739802 razer0/71.238.62.116:55503 MULTI: primary virtual IP for razer0/71.238.62.116:55503: 10.8.0.4

Sat Jan  4 05:22:05 2020 us=739860 razer0/71.238.62.116:55503 MULTI: internal route 192.168.1.0/24 -> razer0/71.238.62.116:55503

Sat Jan  4 05:22:05 2020 us=739977 razer0/71.238.62.116:55503 MULTI: Learn: 192.168.1.0/24 -> razer0/71.238.62.116:55503

Sat Jan  4 05:22:06 2020 us=992481 razer0/71.238.62.116:55503 PUSH: Received control message: 'PUSH_REQUEST'

Sat Jan  4 05:22:06 2020 us=992768 razer0/71.238.62.116:55503 SENT CONTROL [razer0]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.4 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)

Sat Jan  4 05:22:06 2020 us=992938 razer0/71.238.62.116:55503 Data Channel: using negotiated cipher 'AES-256-GCM'

Sat Jan  4 05:22:06 2020 us=993025 razer0/71.238.62.116:55503 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ]

Sat Jan  4 05:22:06 2020 us=993178 razer0/71.238.62.116:55503 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Sat Jan  4 05:22:06 2020 us=993274 razer0/71.238.62.116:55503 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Sat Jan  4 05:22:09 2020 us=20611 razer0/71.238.62.116:55503 MULTI: Learn: 192.168.1.161 -> razer0/71.238.62.116:55503

```

Any additional insight as to why this is happening would be greatly appreciated!

Thanks for reading.

----------

## Hu

If you suspect NetworkManager, then I would suggest one of two courses of action:Enable debug logging on NetworkManager.  Start the whole sequence from the beginning, ideally by rebooting with debug logging already enabled.  Check the logs once VPN connectivity fails.Disable NetworkManager entirely.  Bring up the normal network manually so you know nothing will reconfigure it out from under you.  Start OpenVPN.  If connectivity doesn't fail within some time period, then your suspicion of NetworkManager (or one of its subsidiary processes) would seem to be correct.  This approach may not work if your network requires you to use DHCP and will drop you for not using it.

----------

## mpoletiek

Troubleshooting 101 right?   :Razz: 

For some reason I had /etc/init.d/net.wlp20 and NetworkManager running at the same time. 

VPN works fine using either method now.   :Rolling Eyes: 

Thanks.

----------

