(Solved) Regaining WiFi results in no OpenVPN

Pippin

Hi,

Installed dual boot W7/Mint 18.3

Problem:
Connected to WiFi
OpenVPN as a client works
Routes:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0             192.168.168.1   128.0.0.0           UG     0      0        0 tun0
0.0.0.0             192.168.168.1   0.0.0.0               UG     0      0        0 tun0
0.0.0.0             192.168.43.1     0.0.0.0               UG     600    0        0 wlp2s0
SE.RV.ER.IP        192.168.43.1     255.255.255.255 UGH   0      0        0 wlp2s0
128.0.0.0          192.168.168.1   128.0.0.0            UG     0      0        0 tun0
169.254.0.0       0.0.0.0              255.255.0.0        U      1000   0        0 wlp2s0
192.168.2.0       192.168.168.1   255.255.255.0     UG    0      0        0 tun0
192.168.25.0     192.168.168.1   255.255.255.0     UG    0      0        0 tun0
192.168.43.0     0.0.0.0              255.255.255.0     U      600    0        0 wlp2s0
192.168.51.0     192.168.168.1   255.255.255.0     UG    0      0        0 tun0

WiFi goes down
Routes on wlp2s0 get deleted:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0            192.168.168.1    128.0.0.0         UG    0      0        0 tun0
0.0.0.0            192.168.168.1    0.0.0.0             UG    0      0        0 tun0
128.0.0.0         192.168.168.1   128.0.0.0          UG    0      0        0 tun0
192.168.2.0      192.168.168.1   255.255.255.0   UG    0      0        0 tun0
192.168.25.0    192.168.168.1   255.255.255.0   UG    0      0        0 tun0
192.168.51.0    192.168.168.1   255.255.255.0   UG    0      0        0 tun0
192.168.168.0   0.0.0.0             255.255.255.0   U       0      0        0 tun0
192.168.178.0   192.168.168.1   255.255.255.0   UG    0      0        0 tun0

WiFi comes back
Routes being added again except the one to the OpenVPN server:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0           192.168.168.1   128.0.0.0          UG    0      0        0 tun0
0.0.0.0           192.168.168.1    0.0.0.0            UG     0      0        0 tun0
0.0.0.0           192.168.43.1     0.0.0.0              UG    600    0        0 wlp2s0
128.0.0.0        192.168.168.1   128.0.0.0          UG    0      0        0 tun0
169.254.0.0     0.0.0.0             255.255.0.0       U      1000   0        0 wlp2s0
192.168.2.0     192.168.168.1   255.255.255.0   UG     0      0        0 tun0
192.168.25.0    192.168.168.1   255.255.255.0   UG    0      0        0 tun0
192.168.43.0    0.0.0.0             255.255.255.0   U      600    0        0 wlp2s0
192.168.51.0    192.168.168.1   255.255.255.0   UG    0      0        0 tun0
192.168.168.0   0.0.0.0             255.255.255.0   U       0      0        0 tun0
192.168.178.0   192.168.168.1   255.255.255.0   UG    0      0        0 tun0

This route is set by the still running OpenVPN client which is unaware of wlp2s0 going down.

Someone knows how to solve this in a proper way?

Thanks.

TinCanTech

What .. no log ?

It looks like the VPN does not time out in an orderly fashion ..

Pippin

The logs, good point, sorry :mrgreen:

It looks like the VPN does not time out in an orderly fashion

Another good point, did not think of that.

The log spits recursive routing detected, which I think I understand now.
Will simulate this and post client log and config later.

Thanks.

Pippin

Following happens:

No WiFi (Android)
Start laptop
OpenVPN autostarts using systemd
Enable WiFi hotspot
Connection gets established
Everything is fine, showtime

Disable WiFi hotspot
Client log says:

Recursive routing detected, drop tun packet to [AF_INET]SE.RV.ER.IP

Of course server log says :

...........Inactivity timeout (--ping-restart), restarting
.........SIGUSR1[soft,ping-restart] received, client-instance restarting

Client doesn`t reconnect after enabling WiFi hotspot and writes

Recursive routing detected, drop tun packet to [AF_INET]SE.RV.ER.IP

continuously.

Server pushes (ccd):

PUSH: Received control message: 'PUSH_REPLY,sndbuf 524288,rcvbuf 524288,route-gateway 192.168.168.1,topology subnet,
ping 15,
ping-restart 90,
route 0.0.0.0 0.0.0.0,route 192.168.51.0 255.255.255.0,route 192.168.25.0 255.255.255.0,route 192.168.2.0 255.255.255.0,route 192.168.178.0 255.255.255.0,dhcp-option DNS 192.168.168.1,dhcp-option NTP 192.168.168.1,redirect-gateway def1,ifconfig 192.168.168.2 255.255.255.0'

Client config:

setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
down-pre

remote 1
remote 2
remote 3
remote 4
remote-random
resolv-retry 5
explicit-exit-notify 2

client
nobind
proto udp
dev tun
float
fast-io
comp-lzo

persist-tun
persist-key

I did not yet try --allow-recursive-routing.
W(C)ould the detection of recursive routing prevent restarting...?

Thanks.

Sidenote:
systemd starts the client with --nobind and --supress-timestamps
I like to control that myself.....so i removed it.

Pippin

Removing --persist-tun solved it.
Not completely clear to me why...

TinCanTech

Pippin wrote Removing --persist-tun solved it.

That would solve it 8-)

Pippin wrote Not completely clear to me why...

Because the connection has not timed out completely, --persist-tun keeps the tun device active even during ping time outs. (It is meant to be used when you drop privileges, usually on the server)

In your case it appears that the host route to your server created by --redirect-gateway def1 removed that route but not others. You could experiment further to confirm 😉

Recursive routing detected

Because encrypted packets to create the tunnel are going through the tunnel .. not what you want.

Pippin wrote I did not yet try --allow-recursive-routing.
W(C)ould the detection of recursive routing prevent restarting...?

No! and would probably have made the problem worse !

Pippin wrote systemd starts the client with --nobind and --supress-timestamps
I like to control that myself.....so i removed it.

That's ok.

One last thing, if you had followed this post, I could probably have helped sooner but i guess you wanted to solve it yourself :mrgreen:

Pippin

Yeah, that post someone never feels bored posting, slap me :mrgreen:

In W7 I never encountered this, so did not think about --persist-tun so quickly.
It came to me when posting the client config.

The route to the server gets deleted because it is on wlp2s0 since there is no connectivity I would think.
In other words, Linux`s networking vodoo simply deletes all routes on the interface that goes down.
Interface comes back up, routes are set, except the one set by OpenVPN.
Linux`s networking vodoo should remember the routes it previously has set and only delete those when interface goes down, but probably I`m think too simple :mrgreen:

About --allow-recursive-routing, would possibly create a loop.

Thanks.