Clients wont reconect after a server restart

BenB

Hi
I am having some strange issues with some openvpn clients that connect back to my openvpn server.

Everything has been working and there was no issues until i did a restart on the openvpn server. Some of the clients reconnected after a short time peroid (10 of them) but the others (around 15) still have not connected. The clients that reconnected are working perfectly. I have tried to do another restart after a few hours but this did not fix my issue. It looks like the same clients reconnected.

All the clients are out on external machines so i cant see the log files or what is happening but when i got one of the non connecting clients to do the client service restarted physically on one of the client machines it manage to connect back in with no issues.I had a look for a log file but it dose not go back far enough to catch where it lost connection with the server.

I have posted below my server config and client config but the issues i have is that some of the other clients are in remote locations where i cant get them to do a physical openvpn restart on the box. I was wondering if anyone had any ideas on why this would be happening? I need to be able to restart the server and have the clients reconnecting automatically

I dont have any logs on the server side that i can find and i cant add in a log file in the server config file as i dont want to restart the process as i think i may loose the clients that were physically restarted.

The server is runing on a ubuntu box with openvpn-2.1.0-1ubuntu1.1 i386
The clients are running centos 6.x with openvpn-2.3.2-2.el6.i686

The client config file:
# Are we the client or the server?
client
# Path to log file
status openvpn-status.log
# Use the same setting as you are using on the server.
dev tun
# Are we connecting to a TCP or UDP server?
proto udp
# The hostname/IP and port of the server.
remote xx.xx.xx.xx 1194
# Keep trying indefinitely to resolve the host name of the OpenVPN server.
resolv-retry infinite
# Most clients don't need to bind to a specific local port number.
nobind
# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup
# Try to preserve some state across restarts.
persist-key
persist-tun
# SSL/TLS parms.
ca /etc/openvpn/druid_titan_keys/ca.crt
cert /etc/openvpn/druid_titan_keys/umc2.crt # Insert your client
key /etc/openvpn/druid_titan_keys/umc2.key # key name here
# Enable compression on the VPN link.
comp-lzo
# Set log file verbosity.
verb 4

The server config file:

port 1194
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key  # This file should be kept secret
dh /etc/openvpn/server/dh1024.pem
server 10.8.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 169.254.0.0 255.255.0.0 10.8.1.1
route 10.31.2.1 255.255.255.255
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 3

maikcat

generally use

push "explicit-exit-notify 3"

on your server when you use udp,

also why on earth you are redirecting APIPA range over the vpn?

Michael.

BenB

Hi

Thanks for your reply.

If i use push "explicit-exit-notify 3" on the server to push this to the clients, dose this not get the client to notify the server if it disconnects and not if the server disconnects from the client? The problem i am having is that the server restarted and the clients have not either tried to reconnect or been able to reconnect.

In regards to APIPA, I only took over managing the company openvpn service so i have no idea. i didn't notice it until now. Il look in to it.

Thanks
Ben

maikcat

If i use push "explicit-exit-notify 3" on the server to push this to the clients, dose this not get the client to notify the server if it disconnects and not if the server disconnects from the client?

yes , its used for clients to notify the server that they were disconnected,
it was simply a suggestion for avoiding situations when client disconnects and
server thinks they still on...

All the clients are out on external machines so i cant see the log files or what is happening but when i got one of the non connecting clients to do the client service restarted physically on one of the client machines it manage to connect back in with no issues

your server config uses keepalive which normally pushes ping & ping-restart to clients,
additionally you could use keepalive to your client directive as well.

log files of the problematic clients would help...

Michael.

BenB

Ok Thanks, Il add the push "explicit-exit-notify 3" to the server config as you have recommended.

The logs of the remote machines i can not access at the moment unfortunately and the one machine i did get the service restarted on had a second openvpn client that was connecting to another server and getting a refused response so it filled the log file with junk. I did notice that that client was not consonantly trying to connect back to my server but i did not have the logs to back to the time of the server restart so i could not determine if it had just given up trying to connect back or if it had tried to connect back or if it had even noticed if the server had gone down during the server restart.

Could it be the case that the clients still think they are connected as the server would have only been down for a few seconds with a service restart? If i stopped the server for a hour or so would it kick the clients to notice the server is down and then try reconnecting? or will the clients ever notice if the server is down without the keepalive directive in the client config file?

Ben

Traffic

BenB wroteCould it be the case that the clients still think they are connected as the server would have only been down for a few seconds with a service restart?

First: computers don't think :lol:

However .. considering the length of time ... those client are no longer connected - See your server log.

Simple answer: Client OpenVPN is not running.

thhart

I have exactly the same problem after a server upgrade. Only clients which are manually restarted will be reconnected. Somehow the clients got in a strange transition stage when the server was offline because of several restarts. I also had to reconfigure the server, it denied connections in between. So I don't know if it was related to the misconfiguration or simply the upgrade of the server.

Please note instead of UDP I use TCP for the VPN. The server version is: 2.3.4-5

The server log itself does not contain anything about the missing client so these are not trying to connect any more.

I am convinced that there is a bug in the client connection state monitor.

Traffic

thhart wroteI am convinced that there is a bug

Act upon your conviction .. Start and New thread of your own and post the relevant details.