OpenVPN reconnect after main internet disconnection

[Rave]

Greetings!
Any help would be greatly appreciated!

The problem is that OpenVPN does not reconnects after internet main connection loss.
I use 3G/4G modem that creates PPP0 (rarely - PPP1) interface. Time to time it drops connection.
When modem reconnects it gets new IP of PPP client and new IP of PPP gateway - both straight from mobile netwok carrier.
TUN0 interface don't get dropped at all. Besides PPP0 there's only LO interface.
OpenVPN tries to reconnect but seems like it does not sees the new gateway's IP or re-created PPP interface:

Fri Jul 1 10:08:11 2016 us=522779 UDPv4 link local: [undef]
Fri Jul 1 10:08:11 2016 us=522798 UDPv4 link remote: [AF_INET]x.x.x.x:yyy
Fri Jul 1 10:09:11 2016 us=51982 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jul 1 10:09:11 2016 us=52066 TLS Error: TLS handshake failed
Fri Jul 1 10:09:11 2016 us=52195 TCP/UDP: Closing socket

Thing that helps is CLIENT's "sudo service openvpn restart".
To replicate problem I don't have to wait for a natural connection loss, I can just plug in and plug out USB modem.

I have OpenVPN installed on client from Ubuntu default repos. On server it's from EPEL repos.
Client - Ubuntu 16.04 (Desktop) - OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016

View OriginalCLIENT

client
remote x.x.x.x yyy
proto udp
dev tun
script-security 1
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key
dh /etc/openvpn/keys/dh2048.pem
tls-auth /etc/openvpn/keys/ta.key 1
cipher AES-256-CBC
ns-cert-type server
verb 4
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
resolv-retry infinite
nobind
log /var/log/o

Server - CentOS 6.8 (OpenVZ VPS server) - OpenVPN 2.3.11

View OriginalSERVER

port yyy
local x.x.x.x
proto udp
dev tun
topology subnet
server 10.8.0.0 255.255.255.0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh2048.pem
tls-auth /etc/openvpn/keys/ta.key 0
client-config-dir /etc/openvpn/ccd
cipher AES-256-CBC
user nobody
group nobody
verb 3
mute 20
max-clients 30
keepalive 10 120
tls-server
comp-lzo
persist-key
persist-tun
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "dhcp-option DNS 156.154.70.1"

[TinCanTech]

Try changing your server:

Code: Select all

keepalive 10 30

this may notice the disconnect more quickly.

Also, changing to --proto tcp may help (at the cost of some performance).

[Rave]

Thanks for the reply!
Looks like another serious bug in another serious software... Is it possible to fix it without solving this with workarounds?

Result of changing to keepalive 10 30 on both server and client:

Sat Jul 2 00:57:08 2016 us=886737 UDPv4 link local: [undef]
Sat Jul 2 00:57:08 2016 us=886757 UDPv4 link remote: [AF_INET]x.x.x.x:yyy
Sat Jul 2 00:57:38 2016 us=886211 [UNDEF] Inactivity timeout (--ping-restart), restarting
Sat Jul 2 00:57:38 2016 us=886373 TCP/UDP: Closing socket
Sat Jul 2 00:57:38 2016 us=886434 SIGUSR1[soft,ping-restart] received, process restarting
Sat Jul 2 00:57:38 2016 us=886461 Restart pause, 2 second(s)
Sat Jul 2 00:57:40 2016 us=886593 Re-using SSL/TLS context
Sat Jul 2 00:57:40 2016 us=886691 LZO compression initialized
Sat Jul 2 00:57:40 2016 us=886806 Control Channel MTU parms [ L:1558 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Sat Jul 2 00:57:40 2016 us=886862 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Jul 2 00:57:40 2016 us=886893 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
Sat Jul 2 00:57:40 2016 us=886927 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Sat Jul 2 00:57:40 2016 us=886943 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Sat Jul 2 00:57:40 2016 us=886974 Local Options hash (VER=V4): '9e7066d2'
Sat Jul 2 00:57:40 2016 us=886999 Expected Remote Options hash (VER=V4): '162b04de'
Sat Jul 2 00:57:40 2016 us=887019 UDPv4 link local: [undef]
Sat Jul 2 00:57:40 2016 us=887039 UDPv4 link remote: [AF_INET]x.x.x.x:yyy

Result of changing protocol to TCP:

Sat Jul 2 01:11:26 2016 us=503999 TCP: connect to [AF_INET]x.x.x.x:yyy failed, will try again in 5 seconds: Connection timed out
Sat Jul 2 01:11:41 2016 us=505711 TCP: connect to [AF_INET]x.x.x.x:yyy failed, will try again in 5 seconds: Connection timed out
Sat Jul 2 01:11:56 2016 us=507323 TCP: connect to [AF_INET]x.x.x.x:yyy failed, will try again in 5 seconds: Connection timed out
Sat Jul 2 01:12:11 2016 us=508768 TCP: connect to [AF_INET]x.x.x.x:yyy failed, will try again in 5 seconds: Connection timed out
Sat Jul 2 01:12:26 2016 us=510321 TCP: connect to [AF_INET]x.x.x.x:yyy failed, will try again in 5 seconds: Connection timed out

[fabatera]

I have exactly same problem. Could you realize what is going on?

[TinCanTech]

I have exactly same problem

Please post a detailed thread here:
viewforum.php?f=6

Please see the Forum rules (top of this page)

[fabatera]

Please post a detailed thread here:
viewforum.php?f=6

Done!
viewtopic.php?f=6&t=22325&p=64015#p64015

[lumono]

my solution is removing line of persist-tun