Client dropping connection without error every few days

jacka

So I have an OpenVPN client (v11.9.0.0) running on a server 2008R2 box which connects to a server managed by a third party. Other users connecting to this remote server from windows 7/10 desktop machines function correctly.

I am unable to share my config file, as it is an automatically generated config containing our private encryption key. The disconnect always occurs after the following lines appear in the log after being connected from several hours to days.

Wed Jun 20 14:53:07 2018 VERIFY OK: depth=1, CN=OpenVPN CA
Wed Jun 20 14:53:07 2018 VERIFY OK: nsCertType=SERVER
Wed Jun 20 14:53:07 2018 VERIFY OK: depth=0, CN=OpenVPN Server
Wed Jun 20 14:53:08 2018 Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jun 20 14:53:08 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Wed Jun 20 14:53:08 2018 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jun 20 14:53:08 2018 Incoming Data Channel: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jun 20 14:53:08 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Wed Jun 20 14:53:08 2018 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jun 20 14:53:08 2018 Control Channel: TLSv1, cipher SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

After this the VPN disconnects, does not attempt to reconnect and there is nothing more written to the log until the client is restarted. Prior to this block of log lines the last entry to the log was at 8:50AM, when I last restarted the client. The previous entries simply detail the startup procedure of the VPN.

When the connection drops, the only way to get the VPN to connect is to kill the OpenVPN-GUI.exe, OpenVPN.exe and OpenVPNServ.exe processes, followed by restarting the virtual network adapter then restarting the client. Alternatively, rebooting the server also resolves the issue (temporarily). If these steps are done in the wrong order, or if you fail to perform a step, the VPN will not reconnect & wait for the TUN/TAP adapter to come up indefinitely.

This would not be such a problem if I could get the VPN to automatically reconnect. As the network adapter needs to be restarted for this to reconnect, I have created the following script task to restart everything;

rem This script is fired from Task Scheduler (using Custom Event filter) to check VPN connection and restart the VPN service.
rem  Checks if pinging an outside address can connect. If yes, do nothing, if no, restart the service.
ping -n 1 sanitized.ip.address.0 > testping.txt
findstr /r /c:"Reply from \d*.\d*.\d*.\d*.* bytes=\d*.*time[<=]\d*.* TTL=\d*" testping.txt
IF ERRORLEVEL 1 goto run
rem do nothing because address is pingable
goto finished
:run
rem Next section will kill & restart service/process and network adapter
netsh interface set interface "Local Area Connection 2" disabled
netsh interface set interface "Local Area Connection 2" enabled
timeout 5
taskkill.exe /F /IM openvpn-gui.exe
taskkill.exe /F /IM openvpn.exe
taskkill.exe /F /IM ovpntray.exe
net stop "OpenVPN Interactive Service"
	net start "OpenVPN Interactive Service"
timeout 1
start /b "" "C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect default.ovpn
:finished

Which checks the connection to the remote server, and performs the necessary actions to restart the connection. However, this only works if run manually as a logged in user, and does not do anything if ran by task scheduler. I imagine this is something to do with running openvpn-gui.exe as opposed to openvpn.exe, but I could not find a way to pass command line arguments to the openvpn.exe program. If I attempt to use openvpn.exe the script exits after rebooting the network adapters.

I'd like either a way to prevent these disconnects, a method to find the root cause of these disconnects, or a way to automatically reconnect the server following a disconnect. Any help is appreciated. If there is any other information I can give to help troubleshoot the issue please let me know and I will do my best to provide it.

Thanks,
Jack

TinCanTech

jacka wrote am unable to share my config file, as it is an automatically generated config containing our private encryption key

So use notepad to remove the keys .. or even use our [ oconf=server ] BBCode, which strips out key material automatically.

jacka

Right, opening it in notepad had everything on 1 line making it look like the file was just an RSA key.

Sanitized config below;

# Automatically generated OpenVPN client config file
# Generated on Fri Feb 2 10:27:56 2018 by awssrvvpn02
# Note: this config file contains inline private keys
# and therefore should be kept confidential!
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=username
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=username@host
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=True
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=4host:port
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
# OVPN_ACCESS_SERVER_ORGANIZATION=OpenVPN Technologies, Inc.
client
setenv SERVER_POLL_TIMEOUT 4
nobind
remote host 1194 udp
remote host 443 tcp
dev tun
dev-type tun
ns-cert-type server
reneg-sec 604800
sndbuf 100000
rcvbuf 100000
auth-user-pass "C:\\Tasks\\Auth.txt"
# NOTE: LZO commands are pushed by the Access Server at connect time.
# NOTE: The below line doesn't disable LZO.
comp-lzo no
verb 3
setenv PUSH_PEER_INFO

key-direction 1

TinCanTech

jacka wrote which connects to a server managed by a third party

You must contact the server administrator.

The Johan

I just wanted to add that if this is an OpenVPN Access Server, then you may be trying to use the OpenVPN Connect Client which is meant for a Windows client platform, on a Windows Server platform. While this may work it's not exactly a guarantee it will work. Are you using the open source client? If not use that instead, and load the client.ovpn file to c:\program files\openvpn\config

Another point is that I don't see AUTOLOGIN in this profile, although you may have accidentally anonymized that, which would seem to indicate that this profile is a user-locked profile, meaning you have to provide your credentials to connect. Such profiles by default are limited to sessions of 24 hours. While this can be adjusted, for a server, it makes so much more more sense to:

Use an autologin profile
Use open source OpenVPN client
Enable its background system service in services.msc so it starts the connection automatically.

Incidentally this doesn't require the server to be logged in to a console session for the VPN connection to work.

Good luck.

jacka

Thanks for the reply. Yes I'm using the open source client.

You are correct in assuming it's a user-locked profile instead of an AUTOLOGIN profile. I have proposed using an AUTOLOGIN profile, but as we do not have control over the server we not be able to generate one. The server owner believes it is more secure to use a username & password and change it once a month. It obviously isn't, as the creds are stored in plain-text and passed to the client. Shocking, I know, but that is their prerogative.

As this isn't possible, is there any other way to use a user-locked profile without the user being logged into a console session? As long as I can get this to automatically reconnect without issue any workaround is fine really. Currently the script doesn't work because there is no desktop for OpenVPN-gui to launch on when being loaded from a task scheduler script.

I'm sceptical as to if this is what's causing the disconnect issue however, as considering it won't reconnect without rebooting the virtual network adaptor or server itself the connection hangs indefinitely.

Thanks for the insight.

The Johan

If you use a user-locked profile and you have it set up to reference a text file for the user name and password, then it functions sort of like an autologin profile. There's still the session timeout dictated by the server side, and you have no way of knowing what that is set to. Default is 24 hours. You'll know when you get disconnect and the client tries to reconnect and offers the session token and it says that the session token expired. With the username/password present it should be able to then retry and get connected again with that.

You can enable the openvpn service in services.msc and it should pick up the profile in c:\program files\openvpn\config\ and try to start it then.

You may want to add some script or program that pings across the vpn tunnel and if it times out for a minute or two, to net stop openvpn / net start openvpn the system service to see if that clears it up. But if that isn't enough, then I'm not exactly sure what the problem can be.