cristian's picture

Hi

After months working fine turnkey failed.

I have done many things but i dont know how to start this increidble ovpn.

I have attached a txt with the errors.

 

hu Jan 31 20:52:50 2019 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Thu Jan 31 20:52:50 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan 31 20:52:50 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jan 31 20:52:50 2019 MANAGEMENT: >STATE:1548964370,RESOLVE,,,,,,
Thu Jan 31 20:52:50 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]MY IP
Thu Jan 31 20:52:50 2019 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Jan 31 20:52:50 2019 UDP link local: (not bound)
Thu Jan 31 20:52:50 2019 UDP link remote: [AF_INET]MY IP
Thu Jan 31 20:52:50 2019 MANAGEMENT: >STATE:1548964370,WAIT,,,,,,
Thu Jan 31 20:53:50 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jan 31 20:53:50 2019 TLS Error: TLS handshake failed
Thu Jan 31 20:53:50 2019 SIGUSR1[soft,tls-error] received, process restarting
Thu Jan 31 20:53:50 2019 MANAGEMENT: >STATE:1548964430,RECONNECTING,tls-error,,,,,
Thu Jan 31 20:53:50 2019 Restart pause, 5 second(s)

 

Help please :)

 

Forum: 
Jeremy Davis's picture

I wonder if this is related to another user's experience of the the default CRL expiring? It appears that the default CRL expiry is 30 days. As noted in the bug that I opened, 30 days is probably too short, so we should increase that...

Having said that, you noted it has been working for "months", so not sure if that is your issue? They also noted a syslog entry "VERIFY ERROR: depth=0, error=CRL has expired" which you don't seem to have (although not sure exactly where the output you've shared comes from specifically?), so that may be a red herring...

The only errors in the log output you have posted are:

Thu Jan 31 20:53:50 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jan 31 20:53:50 2019 TLS Error: TLS handshake failed

That is clearly a connection error of some sort (to do with TLS certificate perhaps? - i.e. above). Have you confirmed that the client is actually attempting the connection to OpenVPN? (It does mention "(check your network connectivity)").

Also whilst it does state "--ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.", that is NOT an error, it's a warning. Deprecated means that it will be removed in a future version (so should still work for now).

cristian's picture

Sorry its being working only 1 month.

I have done this:

cd /etc/openvpn/easy-rsa
source vars
openssl ca  -gencrl -keyfile keys/ca.key -cert keys/ca.crt  -out keys/crl.jail/crl.pem -config ./openssl.cnf

and nothing happens. Its everytime connecting but it fails.

ERROR:

Fri Feb 01 13:13:55 2019 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Fri Feb 01 13:13:55 2019 Windows version 6.1 (Windows 7) 64bit
Fri Feb 01 13:13:55 2019 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Fri Feb 01 13:13:55 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Feb 01 13:13:55 2019 Need hold release from management interface, waiting...
Fri Feb 01 13:13:55 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Feb 01 13:13:55 2019 MANAGEMENT: CMD 'state on'
Fri Feb 01 13:13:55 2019 MANAGEMENT: CMD 'log all on'
Fri Feb 01 13:13:55 2019 MANAGEMENT: CMD 'echo all on'
Fri Feb 01 13:13:55 2019 MANAGEMENT: CMD 'bytecount 5'
Fri Feb 01 13:13:55 2019 MANAGEMENT: CMD 'hold off'
Fri Feb 01 13:13:55 2019 MANAGEMENT: CMD 'hold release'
Fri Feb 01 13:13:55 2019 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Feb 01 13:13:55 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 01 13:13:55 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 01 13:13:55 2019 MANAGEMENT: >STATE:1549023235,RESOLVE,,,,,,
Fri Feb 01 13:13:55 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]MYIP:1194
Fri Feb 01 13:13:55 2019 Socket Buffers: R=[8192->8192] S=[64512->64512]
Fri Feb 01 13:13:55 2019 UDP link local: (not bound)
Fri Feb 01 13:13:55 2019 UDP link remote: [AF_INET]MYIP:1194
Fri Feb 01 13:13:55 2019 MANAGEMENT: >STATE:1549023235,WAIT,,,,,,
Fri Feb 01 13:14:55 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Feb 01 13:14:55 2019 TLS Error: TLS handshake failed
Fri Feb 01 13:14:55 2019 SIGUSR1[soft,tls-error] received, process restarting
Fri Feb 01 13:14:55 2019 MANAGEMENT: >STATE:1549023295,RECONNECTING,tls-error,,,,,
Fri Feb 01 13:14:55 2019 Restart pause, 5 second(s)

 

If I do a new certificate everuthing looks OK.

openvpn-addclient prueba prueba@tyryt.com

INFO: generated /etc/openvpn/easy-rsa/keys/prueb2a.ovpn
 

Jeremy Davis's picture

Did you change the value of default_crl_days in /etc/openvpn/easy-rsa/openssl.cnfbefore regenerating the certificate? Although actually I don't think that should matter. Even if you didn't update that value, regenerating a new certificate should give you 30 more days...

I'm not sure, but perhaps the OpenVPN service requires a restart to use the new certificate which you have generated? Although I'm still only guessing that your issue is related to the other one I linked to. Noting that it's only been working for a month does certainly make that seem more likely though.

Unfortunately, I don't currently have an OpenVPN server running so I can't immediately double-check the command you'll need to restart the OpenVPN service. But I would imagine that the service is named "openvpn", or perhaps "openvpn-something". One way you could go is try using tab-complete to guess the name, i.e. something like this:

service openvpn<tab><tab> restart

To see what options there are.

An alternate command that you can use on newer TurnKey servers (v14.0+) is systemctl. The format is slightly different, but it does pretty much the same thing:

systemctl restart openvpn<tab><tab>

Alternatively, just restarting your server will definitely restart all processes/services.

Also you note that you've tried regenerating a user config (.opvn file). Have you tried using that new config (after regenerating the CRL and restarting OpenVPN)? Perhaps that is also required? Sorry that I can't give you more specific and definite answers...

Add new comment