Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] OpenVPN & Network Manager
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
mpoletiek
n00b
n00b


Joined: 18 Dec 2019
Posts: 3

PostPosted: Sat Jan 04, 2020 5:47 am    Post subject: [SOLVED] OpenVPN & Network Manager Reply with quote

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.

Code:

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.

Code:

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:

Code:

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;
Code:

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
Code:
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
Code:

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
Code:

# 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;
Code:

/etc/init.d/openvpn.client start


Here is what the connection looks like from the server:

Code:

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14922

PostPosted: Sat Jan 04, 2020 6:00 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mpoletiek
n00b
n00b


Joined: 18 Dec 2019
Posts: 3

PostPosted: Sat Jan 04, 2020 8:56 pm    Post subject: Reply with quote

Troubleshooting 101 right? :P

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

VPN works fine using either method now. :roll:

Thanks.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum