Yesterday I installed Debian 9 and OpenVPN on a server at home and everything was working flawlessly (I followed this guide). However, this morning, OpenVPN was working (client side) and suddenly nothing was loading anymore. I tried reconnecting to the VPN and it worked for 5 or 10 minutes and then nothing.

I did a few researches and I checked the status of the OpenVPN server with the command systemctl status openvpn@server and I saw the message:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

Again, I looked up this error on internet but nothing solved the problem. In the mean time, 2 other errors came up:

TLS Error: local/remote TLS keys are out of sync

and

Authenticate/Decrypt packet error: cipher final failed

It seems obvious that this has something to do with TLS right? I have the file ta.key generated with openvpn --genkey --secret ta.key in both /etc/openvpn/ on the server and in the config folder on the client (windows).


I tried disabling ufw but it doesn't solve the problem so I doubt it is a firewall thing. Here is the result of ufw status anyway:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
1194/udp                   ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
1194/udp (v6)              ALLOW       Anywhere (v6)

Here's what I added to /etc/ufw/before.rules:

*nat
:POSTROUTING ACCEPT [0.0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

The server.conf (without comments):

port 1194
proto udp4
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 82.196.9.45"
push "dhcp-option DNS 89.46.223.237"

keepalive 10 120
tls-auth ta.key 0 # This file is secret
cipher AES-256-CBC
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

And finally the client.ovpn (without comments and certificates):

client
dev tun
proto udp4
remote [server-ip] 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

<ca>
-----BEGIN CERTIFICATE-----
(...)
-----END CERTIFICATE-----
</ca>

<cert>
Certificate:
    (...)
-----BEGIN CERTIFICATE-----
(...)
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
(...)
-----END PRIVATE KEY-----
</key>

Any suggestions are welcomed, thank you!

The TLS Authorization Keys in OpenVPN are pre-shared keys.

You must generate one key and copy that same key to the server and client.
Unless I've understood correctly, you've generated that key on both the server and the client (meaning that they are two different keys). So generate one key and copy it to both systems, then there should be no error that the local/remote keys are out of sync.

Moving on, it seems that this is not the issue in your case, it has been my misunderstanding that you have used that in the wrong way.

From an OpenVPN mailing list archive (emphasis mine):

This message can occur when running OpenVPN in UDP mode, as UDP is not connection-oriented, so there's no easy way for one side of the connection to know that the other side has gone down or restarted. This error will almost never occur when running in TCP mode, because TCP enforces solid client/server semantics and connection-reset when either side of the connection goes down.

Note: The following is a statement without concrete reference/data backing it up:

Taking into consideration that quote, and the fact that you've configured udp4 to be the protocol that OpenVPN is running over, it seems to me that it is a bad idea to use TLS along with UDP. TLS is meant to be a secure protocol, thus it needs a reliable connection, which UDP does not guarantee.

From RFC 5246 - TLS:

At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.

So TLS does require a reliable connection, thus UDP should not be used.
You can also read more about why in this answer in Security SE.

Simply switch from:

proto udp4

to:

proto tcp

In your OpenVPN configurations.

References (to read up on details):
OpenVPN - Use of tls-auth
OpenVPN Mailing List
OpenVPN HowTo - configuration
Security SE - Why does TLS require TCP?
RFC 5246 - The TLS Protocol
Wikipedia - UDP

  • I copied the ta.key from the server to the client, otherwise I couldn't connect at all – Rallph Sep 14 at 15:51
  • @Raphaël My misunderstanding then. I've updated my answer, hopefully it is more useful now :-) – Fanatique Sep 14 at 16:12
  • I also found this archive but didn't understand it that way, thank you for your explanation. Does it mean you can't have a secure connection using UDP? Thb I don't understand the utility of TLS here since the handshake is done using asymmetric encryption and I have the public key on my computer – Rallph Sep 14 at 16:57
  • @Raphaël it's almost impossible to have a secure connection over UDP. UDP is way too unreliable for that, you need a reliable protocol on which TLS has to work. It can work with UDP, but only for small periods of time, because of the losses that UDP has. Such secure connection should only be done over reliable protocols like TCP. Because of UDP's losses often even TLS handshakes will fail. – Fanatique Sep 14 at 17:55
  • I get it, thanks. I tried disabling TLS in config files (removing tls-auth ta.key 0 in both server and client file) but I still have the problem, same error message – Rallph Sep 14 at 20:48
up vote 0 down vote accepted

I reinstalled the server following this and everything is working flawlessly now

I guess it's because I didn't add key-direction in the config files (0 on server and 1 on client) because it's almost the only thing that has changed in the config

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.