Reconnection issues because of hostname resolving

[jd890123 4]

I am using AirVPN's config generator to connect to for example the Switzerland servers on Linux using only openvpn.

 

This yields a config like this

client
dev tun
proto udp
remote ch.vpn.airdns.org 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
verb 3
explicit-exit-notify 5
rcvbuf 262144
sndbuf 262144

However sometimes my internet connection goes down for a very short time. This seems to break the vpn connection so openvpn needs to reconnect.

These messages are logged:

Jan  4 12:16:15 debian ovpn-AirVPN_Switzerland_UDP-443[1635]: [server] Inactivity timeout (--ping-restart), restarting
Jan  4 12:16:15 debian ovpn-AirVPN_Switzerland_UDP-443[1635]: SIGUSR1[soft,ping-restart] received, process restarting
Jan  4 12:16:15 debian ovpn-AirVPN_Switzerland_UDP-443[1635]: Restart pause, 2 second(s)
Jan  4 12:16:17 debian ovpn-AirVPN_Switzerland_UDP-443[1635]: Socket Buffers: R=[212992->425984] S=[212992->425984]
Jan  4 12:17:37 debian ovpn-AirVPN_Switzerland_UDP-443[1635]: RESOLVE: Cannot resolve host address: ch.vpn.airdns.org: Temporary failure in name resolution

The last message repeats around every 90 seconds and vpn connectivity is never established again.

Investigating this I found that when my system is in this state I cannot make any dns queries which is why the host address resolving fails.

But why can I not issue dns queries? I dont know much about openvpn (yet) but I suspect it keeps the tunnel open even though it is not connected which causes the dns requests to try and go through the tunnel which obviously fails resulting in vpn never reconnecting.

My other guess is I somehow fucked up my firewall settings which are supposed to ensure that internet traffic can only go through the tunnel.

My ufw rules:

Default: deny (incoming), deny (outgoing), disabled (routed)
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 8.8.4.4 53                 ALLOW OUT   Anywhere (out)
[ 2] 8.8.8.8 53                 ALLOW OUT   Anywhere (out)
[ 3] 46.19.137.114 443          ALLOW OUT   Anywhere (out)
[ 4] 91.214.169.68 443          ALLOW OUT   Anywhere (out)
[ 6] Anywhere                   ALLOW OUT   Anywhere on tun0 (out)
[ 7] 192.168.0.0/16             ALLOW OUT   Anywhere on eth0 (out)
[ 8] Anywhere on eth0           ALLOW IN    192.168.0.0/16

8.8.8.8 and 8.8.4.4 are the google dns servers. 46.19.137.114 and 91.214.169.68 are the switzerland air vpn servers. 192.168.0.1/16 is my local subnet.

When connected to the vpn, traceroute shows that dns requests correctly go through it, but the actual traceroute command fails with a strange error message when in the failing to reconnect state ('send probe: No buffer space available').

netstat -nr in failed state:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         vpnip           128.0.0.0       UG        0 0          0 tun0        #ip of tun0 interface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0        #home router
10.4.0.0        0.0.0.0         255.255.0.0     U         0 0          0 tun0
91.214.169.68   192.168.1.1     255.255.255.255 UGH       0 0          0 eth0        #airvpn server
128.0.0.0       vpnip           128.0.0.0       UG        0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

I dont know exactly how to read this yet but Im guessing the first two lines are the relevant ones and this means that the vpn currently has priority over my home network despite not being in a connected state.

 

 

Currently I am commenting out 'persist-tun' in the openvpn config file and it seems to reconnect correctly now. However Im not sure about the implications of that. Is it okay to comment that out? Why did this problem only occur for me and not anyone else trying to do the same thing?

[veps2i 4]

I also seem to have the same problems as of late and just commented the persist-tun out of the configuration. Thanks for the tip!

 

I have no idea what about the implications, it would be nice to hear about them from someone with more knowledge on the matter.

[Staff 10018]

I also seem to have the same problems as of late and just commented the persist-tun out of the configuration. Thanks for the tip!

 

I have no idea what about the implications, it would be nice to hear about them from someone with more knowledge on the matter.

 

Hello!

 

Nothing to be worried about. From the manual https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage

 

--persist-tun

Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts.

 

Kind regards