Sometimes, due to a network issue, the connection drops, but he client thinks it is still connected. [code] tun0: flags=4305 mtu 1500 inet 192.168.6.6 netmask 255.255.255.255 destination 192.168.6.5 . . $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.6.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 eth0 128.0.0.0 192.168.6.5 128.0.0.0 UG 0 0 0 tun0 [/code] The server has no info about this client [code]$ sudo more openvpn-status.log OpenVPN CLIENT LIST Updated,Sat Mar 5 22:49:21 2016 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since client,x.x.x.x.:2733,715463,2373402,Sat Mar 5 18:53:38 2016 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref 192.168.6.14,client,x.x.x.x:2733,Sat Mar 5 22:49:20 2016 GLOBAL STATS Max bcast/mcast queue length,0 END [/code] The keepalive is default 10 120. Can you suggest where to look next? Thanks.

[quote="iobelix"]The keepalive is default 10 120. [/quote]The client will detect that is has dropped the connection after 120 seconds.[quote="iobelix"]Can you suggest where to look next? [/quote]Please see the [b][color=#A40000]Forum rules[/color][/b] (top of page)

--[b]persist-tun[/b] and --[b]persist-key[/b] are generally used on servers when dropping privileges .. not clients.

Thx again. We picked the client configs from the example over at [url]https://openvpn.net/index.php/open-source/documentation/howto.html#examples[/url] That said, is there any other way apart from removing the (persist-tun) tunnel interface to fix this scenario?

Stale Client Connection

iobelix

Sometimes, due to a network issue, the connection drops, but he client thinks it is still connected.


tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.6.6  netmask 255.255.255.255  destination 192.168.6.5
.
.

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.6.5     128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.100.1    0.0.0.0         UG        0 0          0 eth0
128.0.0.0       192.168.6.5     128.0.0.0       UG        0 0          0 tun0

The server has no info about this client

$ sudo more openvpn-status.log 
OpenVPN CLIENT LIST
Updated,Sat Mar  5 22:49:21 2016
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client,x.x.x.x.:2733,715463,2373402,Sat Mar  5 18:53:38 2016
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
192.168.6.14,client,x.x.x.x:2733,Sat Mar  5 22:49:20 2016
GLOBAL STATS
Max bcast/mcast queue length,0
END

The keepalive is default 10 120.

Can you suggest where to look next?
Thanks.

Traffic

iobelix wroteThe keepalive is default 10 120.

The client will detect that is has dropped the connection after 120 seconds.

iobelix wroteCan you suggest where to look next?

Please see the Forum rules (top of page)

iobelix

Thx for the info.

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 192.168.6.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.6.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
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
script-security 3 system

We came to know that the primary and secondary DNS is on a separate network. So when the underlying network comes back up, the VPN client tries to reach the VPN server using the Fully Qualified Domain Name and it fails

Mon Mar 7 15:37:53 2016 RESOLVE: Cannot resolve host address: foo.bar.com: Temporary failure in name resolution

So the tunnel interface is up but it cannot reach the VPN Server. (If can ping the VPN Server's IP. But if the VPN server's domain name is used, we cannot ping it.)

If I remove the

persist-tun

the tunnel interface goes down, thereby removing the default route from the routing table and then the tunnel is retried and it is back up.

Is this (removal of persist-tun) the only way for the situation when default DNS on a different network)?

Traffic

--persist-tun and --persist-key are generally used on servers when dropping privileges .. not clients.

iobelix

Thx again.

We picked the client configs from the example over at https://openvpn.net/index.php/open-source/documentation/howto.html#examples

That said, is there any other way apart from removing the (persist-tun) tunnel interface to fix this scenario?