I am having a rather strange issue with my OpenVPN configuration. I am connecting from Windows 7 with official latest OpenVPN client to my OpenVPN server (OpenVPN 2.1.4 i386-redhat-linux-gnu).

The problem is I am getting disconnected from my OpenVPN server exactly after 1 hour and I can't understand what directive/option is reponsible for this. Maybe it's a client issue? I have tried different Windows systems and Windows VPN clients. The Linux clients are working as expected with no disconnections.

Could you please help me to troublshoot this issue? I have tried reading books and googling and some people advise to play with keepalive and reneg-sec directives. But that does not seem to help.

OpenVPN server config

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 192.168.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.0.0.0 255.0.0.0"
client-config-dir ccd
route 192.168.51.0 255.255.255.0
keepalive 60 600
reneg-sec 5000
hand-window 15
tls-auth ta.key 0
comp-lzo
max-clients 50
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem
management localhost 11111
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
push "dhcp-option DNS 192.168.2.1"
push "dhcp-option DOMAIN example.com"
push "dhcp-option SEARCH example.com"

Server log (isn't the problem in reinit_src=1?)

Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
Oct  9 07:24:53 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS key negotiation failed to occur within 15 seconds (check your network connectivity)
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 [UNDEF] Inactivity timeout (--ping-restart), restarting
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 SIGUSR1[soft,ping-restart] received, client-instance restarting

Client log

RwrWRwRwRwRwTue Oct 09 07:26:39 2012 us=796000 TLS: soft reset sec=0 bytes=7405621/0 pkts=9459/0
Tue Oct 09 07:26:39 2012 us=600000 ERROR: could not read Auth username from stdin
Tue Oct 09 07:26:39 2012 us=600000 Exiting
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 192.168.2.1 MASK 255.255.255.255 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 10.0.0.0 MASK 255.0.0.0 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 Closing TUN/TAP interface

Thank you very much.

up vote 8 down vote accepted

The culprit seems to be your authentication configuration. You are using plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login which would require the client to supply a valid username/password combination to connect. Apparently, this is also required upon rekeying and your OpenVPN client seems unable to request the user name from stdin (ERROR: could not read Auth username from stdin).

As for the reason why raising reneg-sec in your server configuration does not help matters, this is because the parameter has to be specified in both - the server's and the client's config to be effectively raised above the default of 3600 seconds (which happens to cause the one hour - disconnect you are seeing).

So your options would be to

  • use an authentication method which does not require user input (certificates spring to mind)
  • troubleshoot why your client is unable to prompt for the user name / password combination after connection establishment
  • raise the rekeying period or disable rekeying entirely (which weakens your connection's security, so it surely is only an inferior workaround to your problem)
  • You are right, putting reneg-sec to the client.ovpn helped to resolve this issue. – Andrew Oct 10 '12 at 9:51

I experienced a similar effect when I added the 'auth-nocache' option to my client configuration. I use certificates AND a username + password combination to authenticate.

A few times I noticed in the connection logs that openvpn reported the following warning:

WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

So I thought I'll just add this option and see what happens. Well, the above warning does go away, but after an hour a dialog box popped up, asking me for my username and password.

I noticed that the above configuration by Andrew doesn't contain this option so I'm a little puzzled as to why it doesn't cache the password. Maybe this is because I'm using a newer version of openvpn or maybe it can be set on the server config to push this option to the client.

This was seen on: OpenVPN 2.2.1-8+deb7u2 with OpenVPN GUI v5 for Windows.

  • I have to generate a file using openvpn and then add the auth-nocache option. Now is working perfectly. File generated can be used as – crsuarezf Nov 24 '15 at 21:17
  • @ingcarlos Great to hear it's working for you. Happy vpn-ing. – captcha Nov 24 '15 at 22:01
  • +1 Absolutley right, I faced the same problem after adding no cache directive. – Mohammed Noureldin Nov 10 '16 at 0:23

you can try to reneg-sec 0 in your server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

it's quite simple really. Since OpenVPN tries to renegociate a new TLS Session every 3600 secs by default, you'd have to re-authenticate each time, using a new OTP. To avoid this kind of behaviour, it's just a matter of telling openvpn to never renegociate a TLS session and keep the existing one alive, if you combine keepalive directive and reneg-sec 0, you're going to have a stable connection, with no renegociation whatsoever.

  • 1
    Could you expand your answer a little? As mentioned in serverfault.com/help/how-to-answer, it helps make your answer more useful if you provide some context for the links. – iwaseatenbyagrue Mar 19 '17 at 9:51
  • 1
    It's quite simple really. Since OpenVPN tries to renegociate a new TLS Session every 3600 secs by default, you'd have to re-authenticate each time, using a new OTP. To avoid this kind of behaviour, it's just a matter of telling openvpn to never renegociate a TLS session and keep the existing one alive, if you combine keepalive directive and reneg-sec 0, you're going to have a stable connection, with no renegociation whatsoever. – Arnaud Mar 20 '17 at 11:02
  • thank you @Arnaud, could I be a pain and ask you to add that to your answer? I think it would help others to understand your solution. Either way, thank you for taking the time to explain. – iwaseatenbyagrue Mar 20 '17 at 11:21
  • no problemo :-) – Arnaud Mar 20 '17 at 14:25

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.