OpenVPN client fails to re-connect after internet connection re-established

[carrot_relative]

I'm running miniPC with Debian and shorewall on it + and OpenVPN client. All is running smoothly unless my isp modem loses connection. After the connection to the internet is re-established, the OpenVPN is not able to connect, unless I HW restart or run

Code: Select all

systemctl restart openvpn

This are the messages I'm getting when I pull network cable from the minipc and put it back

Code: Select all

kernel: [15984.234741] igb 0000:01:00.0 enp1s0: igb: enp1s0 NIC Link is Down
dhcpcd[489]: enp1s0: carrier lost
dhcpcd[489]: enp1s0: deleting address fe80::91f0:1a8a:5b0:b967
dhcpcd[489]: enp1s0: deleting route to 192.168.0.0/24
dhcpcd[489]: enp1s0: deleting default route via 192.168.0.1
kernel: [15990.843593] igb 0000:01:00.0 enp1s0: igb: enp1s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
dhcpcd[489]: enp1s0: carrier acquired
dhcpcd[489]: enp1s0: IAID 31:0b:c8:5e
dhcpcd[489]: enp1s0: adding address fe80::91f0:1a8a:5b0:b967
dhcpcd[489]: enp1s0: soliciting an IPv6 router
dhcpcd[489]: enp1s0: rebinding lease of 192.168.0.49
dhcpcd[489]: enp1s0: NAK: from 192.168.0.72
dhcpcd[489]: enp1s0: soliciting a DHCP lease
dhcpcd[489]: enp1s0: offered 192.168.0.49 from 192.168.0.1
dhcpcd[489]: enp1s0: probing address 192.168.0.49/24
dhcpcd[489]: enp1s0: leased 192.168.0.49 for 864000 seconds
dhcpcd[489]: enp1s0: adding route to 192.168.0.0/24
dhcpcd[489]: enp1s0: adding default route via 192.168.0.1

and then only getting this messages from openvpn

Code: Select all

ovpn-client[15057]: Socket Buffers: R=[212992->212992] S=[212992->212992]
ovpn-client[15057]: UDP link local: (not bound)
ovpn-client[15057]: UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
ovpn-client[15057]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
ovpn-client[15057]: TLS Error: TLS handshake failed
ovpn-client[15057]: SIGUSR1[soft,tls-error] received, process restarting
ovpn-client[15057]: Restart pause, 5 second(s)
ovpn-client[15057]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
ovpn-client[15057]: TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194

and my .conf

Code: Select all

client
dev tun
proto udp
remote xxx.xxx.xxx.xxx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Is there a way I could properly restart the OpenVPN service every time it's want to reconnect? I wasn't able to find anything meaningful, all information I have found are related to issues with making any connection at all.
Or this can be handled by some config change?

[TinCanTech]

Check the server log.

[carrot_relative]

Check the server log.

The only relevant message regarding the client is

Code: Select all

Sep  5 01:47:00 vm29266 openvpn[585]: client/xxx.xxx.xxx.xxx:1026 [client] Inactivity timeout (--ping-restart), restarting
Sep  5 01:47:00 vm29266 openvpn[585]: client/xxx.xxx.xxx.xxx:1026 SIGUSR1[soft,ping-restart] received, client-instance restarting

Basically what I can see is that the resolv.conf is being updated by the connection made by openvpn, but is not tore down when the connection is lost, only when the service is really stopped. That is kind of weird behaviour, as the new dns settings are coming from the connection, so one you expect they will be removed when the connection is lost.

[TinCanTech]

The two tiny snippets of log data, which you have posted, have nothing to do with each other.

[carrot_relative]

Yet they appeared at the same time and regarding the same IP address, which is a client.
Also there are no other messages in the syslog regarding the lost connection so there was nothing more to post.

[TinCanTech]

Then it is time for you to read this: viewtopic.php?t=22603

[ordex]

Basically what I can see is that the resolv.conf is being updated by the connection made by openvpn, but is not tore down when the connection is lost, only when the service is really stopped. That is kind of weird behaviour, as the new dns settings are coming from the connection, so one you expect they will be removed when the connection is lost.

That's likely (but not guaranteed) to be related to persist-tun. If not strictly needed you could remove it from your client config.