Ошибки «TLS Error: TLS key negotiation failed to occur within 60 seconds» и «TLS handshake failed» (РЕШЕНО)
В процессе использования OpenVPN вы можете столкнуться с ситуацией, когда не удаётся подключиться к OpenVPN серверу без видимых причин. Например, в целом OpenVPN работает правильно и подключения происходят, но на определённых Интернет-провайдерах подключение не может выполнить успешное TLS рукопожатие.
Пример логов на стороне OpenVPN сервера:
2021-11-05 18:29:22 us=384206 MULTI: multi_create_instance called 2021-11-05 18:29:22 us=384302 176.59.38.132:56094 Re-using SSL/TLS context 2021-11-05 18:29:22 us=384395 176.59.38.132:56094 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2021-11-05 18:29:22 us=384424 176.59.38.132:56094 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2021-11-05 18:29:22 us=384568 176.59.38.132:56094 Control Channel MTU parms [ L:1621 D:1184 EF:66 EB:0 ET:0 EL:3 ] 2021-11-05 18:29:22 us=384605 176.59.38.132:56094 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ] 2021-11-05 18:29:22 us=384669 176.59.38.132:56094 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,keydir 0,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server' 2021-11-05 18:29:22 us=384700 176.59.38.132:56094 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,keydir 1,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client' 2021-11-05 18:29:22 us=384751 176.59.38.132:56094 TLS: Initial packet from [AF_INET]176.59.38.132:56094, sid=7b5f6347 776e80e1 2021-11-05 18:30:22 us=183787 176.59.38.132:56094 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2021-11-05 18:30:22 us=183887 176.59.38.132:56094 TLS Error: TLS handshake failed 2021-11-05 18:30:22 us=184085 176.59.38.132:56094 SIGUSR1[soft,tls-error] received, client-instance restarting
Пример логов на стороне OpenVPN клиента:
2021-11-05 18:30:21 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2021-11-05 18:30:21 TLS Error: TLS handshake failed 2021-11-05 18:30:21 SIGUSR1[soft,tls-error] received, process restarting 2021-11-05 18:30:21 Restart pause, 5 second(s)
Причиной такой ошибки может быть Интернет-провайдер, который определённым образом фильтрует трафик либо использует неудачно настроенный NAT.
Для исправления ошибки может оказаться достаточным выполнить одно из следующих действий:
- изменить порт OpenVPN сервера
- изменить используемый протокол с UDP на TCP
Смотрите также:
- Как использовать OpenVPN с протоколом TCP
- Инструкция по настройке сервера и клиента OpenVPN
- Продвинутое использование OpenVPN
TLS key negotiation failed error in OpenVPN – How to fix
As part of our Server Management Services, we assist our customers with several OpenVPN queries.
Today, let us see how our Support techs resolve this error.
How to resolve TLS key negotiation failed error in OpenVPN?
First and foremost, to diagnose problems with an OpenVPN server or client, it is helpful to look at the log files.
Locating the server log files
The log files are located in specific areas on your computer systems.
Log files are the place to check whenever you’re having any problems making a connection with an OpenVPN client program to the OpenVPN Access Server.
On the OpenVPN Access Server there is the server side log:
/var/log/openvpnas.log /var/log/openvpnas.node.log (in case of a failover setup)In the event that you are having problems with starting the Access Server or certain portions of it, for example the web services, then it may be useful to stop the Access Server service.
Then, move the log file aside, then start the Access Server service, and stop it again immediately.
This creates a new clean log file that contains the startup and shutdown sequence of the Access Server and no other extraneous information.
This makes analysis of the log file much easier.
To do so use these commands in order:
service openvpnas stop mv /var/log/openvpnas.log /var/log/openvpnas.log.old service openvpnas start service openvpnas stopYou can then grab the /var/log/openvpnas.log file for analysis and start the Access Server again:
service openvpnas startLocating the client log files
Log file location for the OpenVPN Connect Client for Windows:
C:\Program Files (x86)\OpenVPN Technologies\OpenVPN Client\etc\log\openvpn_(unique_name).logThe OpenVPN Connect Client for Mac:
/Library/Application Support/OpenVPN/log/openvpn_(unique_name).logTo get to the /Library folder, open Finder and in the menu at the top choose Go followed by Go to folder and then enter the path /Library to get into that directory.
You can then go to the correct folder and look up the log file.
Please also note that the OpenVPN Connect Client for Macintosh will have permissions set on the log file so that you cannot normally open it.
To bypass this, right click the log file and choose the Get info option in the menu.
Then at the bottom, under Sharing & Permissions, you will be able to use the yellow padlock icon to unlock the settings and to give everyone read access.
Then, you will be able to open the log file with a right click and selecting Open with and then choosing something like Text editor to view the contents of the log file.
TLS key negotiation failed error
Typical error will look as shown below:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
This particular error can have multiple different causes as it is a fairly generic error message.
A possible explanation is that the client program is old and supports only TLS 1.0, but the server is expecting TLS level 1.1 or higher.
To see if this is the case log on to the server and check the server side log file.
The chances are high that your client program is an older version, like version 2.2 or older, and that it doesn’t know how to handle a modern TLS minimum level requirement, when you see messages that look like this on the server side:
OpenSSL: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol’
TLS_ERROR: BIO read tls_read_plaintext error’
TLS Error: TLS object -> incoming plaintext read error’
TLS Error: TLS handshake failed’
SIGUSR1[soft,tls-error] received, client-instance restarting’
The solution to this particular problem is to upgrade the client software to the latest version.
Another possible explanation is that the settings regarding TLS minimum requirement level have been altered but the OpenVPN client is using an older copy of the connection profile which has incorrect instructions.
The settings on the client and the server must match for the connection to be successful.
In this situation installing a new copy of the configuration profile will solve the issue.
A complete uninstall, redownload, and reinstall of the OpenVPN Connect Client should take care of that for you.
And yet another possible explanation is that there is a blockage in place in a firewall or at the Internet service provider that is blocking or interfering with the TLS handshake in some way.
[Stuck in between? We’d be glad to assist you]
Conclusion
In short, today we saw steps followed by our Support Techs to resolve TLS key negotiation failed error in OpenVPN.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
1 Comment
witolino on 2023-03-04 at 06:45
It would be good to sniff packets a bit to verify what versions of TLS are in use by the client and the server. In many cases servers do not want to handshake to TLS v 1.0 anymore. The TLS 1.2 or 1.3 is an option to establish the session. Reply
Fix ‘TLS Error: TLS handshake failed’ on OpenVPN client
I am configuring OpenVPN 2.3.6-1 on my Arch Linux server in order to encrypt SMB traffic over the public Internet. When I test the setup on one of my Linux virtual machine clients, I get the error: TLS Error: TLS handshake failed . I quickly read (OpenVPN on OpenVZ TLS Error: TLS handshake failed (google suggested solutions not helping)) and tried to switch from the default UDP to TCP, but that only caused the client to repeatedly report that the connection timed out. I also tried disabling the cipher and TLS authentication, but that caused the server to fail with Assertion failed at crypto_openssl.c:523 . In both instances, the required changes were made to both the client and server configurations. I have been following the instructions at (https://wiki.archlinux.org/index.php/OpenVPN) to set up OpenVPN and the instructions at (https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts) to create the keys and certificates. The only deviations I have made from these instructions have been specifying my own computers’ names and their corresponding key/certificate file names. See also my original question about securing SMB traffic over the Internet: (Simple encryption for Samba shares) Can anybody explain how I can solve this issue? Details: Server: Arch Linux (up to date) connected directly to gateway via ethernet cable. No iptables. Client: Arch Linux (up to date) virtual machine on VirtualBox 4.3.28r100309 Windows 8.1 host, bridged network adapter. No iptables. Windows Firewall disabled. Gateway: Port forwarding for port 1194 enabled, no firewall restrictions. Here are the configuration files on the server and client, respectively. I created these according to the instructions on the Arch Wiki. /etc/openvpn/server.conf (Non-comment lines only):
port 1194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server-name.crt key /etc/openvpn/server-name.key dh /etc/openvpn/dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt keepalive 10 120 tls-auth /etc/openvpn/ta.key 0 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log verb 3 /etc/openvpn/client.conf (Non-comment lines only):
client dev tun proto udp remote [my public IP here] 1194 resolv-retry infinite nobind user nobody group nobody persist-key persist-tun ca /etc/openvpn/ca.crt cert /etc/openvpn/client-name.crt key /etc/openvpn/client-name.key remote-cert-tls server tls-auth /etc/openvpn/ta.key 1 comp-lzo verb 3 Here are the outputs of running openvpn on the machines with the above configurations. I started the server first, then the client. The output of openvpn /etc/openvpn/server.conf on the server:
Thu Jul 30 17:02:53 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 2 2014 Thu Jul 30 17:02:53 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09 Thu Jul 30 17:02:53 2015 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet. Thu Jul 30 17:02:53 2015 Diffie-Hellman initialized with 2048 bit key Thu Jul 30 17:02:53 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file Thu Jul 30 17:02:53 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Jul 30 17:02:53 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Jul 30 17:02:53 2015 Socket Buffers: R=[212992->131072] S=[212992->131072] Thu Jul 30 17:02:53 2015 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp5s0 HWADDR=##:##:##:##:##:## Thu Jul 30 17:02:53 2015 TUN/TAP device tun0 opened Thu Jul 30 17:02:53 2015 TUN/TAP TX queue length set to 100 Thu Jul 30 17:02:53 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Thu Jul 30 17:02:53 2015 /usr/bin/ip link set dev tun0 up mtu 1500 Thu Jul 30 17:02:53 2015 /usr/bin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2 Thu Jul 30 17:02:53 2015 /usr/bin/ip route add 10.8.0.0/24 via 10.8.0.2 Thu Jul 30 17:02:53 2015 GID set to nobody Thu Jul 30 17:02:53 2015 UID set to nobody Thu Jul 30 17:02:53 2015 UDPv4 link local (bound): [undef] Thu Jul 30 17:02:53 2015 UDPv4 link remote: [undef] Thu Jul 30 17:02:53 2015 MULTI: multi_init called, r=256 v=256 Thu Jul 30 17:02:53 2015 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0 Thu Jul 30 17:02:53 2015 IFCONFIG POOL LIST Thu Jul 30 17:02:53 2015 Initialization Sequence Completed The output of openvpn /etc/openvpn/client.conf on the client:
Thu Jul 30 21:03:02 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 2 2014 Thu Jul 30 21:03:02 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09 Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/client-name.key' is group or others accessible Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/ta.key' is group or others accessible Thu Jul 30 21:03:02 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file Thu Jul 30 21:03:02 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Jul 30 21:03:02 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Jul 30 21:03:02 2015 Socket Buffers: R=[212992->131072] S=[212992->131072] Thu Jul 30 21:03:02 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Thu Jul 30 21:03:02 2015 UDPv4 link local: [undef] Thu Jul 30 21:03:02 2015 UDPv4 link remote: [AF_INET][my public IP here]:1194 Thu Jul 30 21:04:02 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Jul 30 21:04:02 2015 TLS Error: TLS handshake failed Thu Jul 30 21:04:02 2015 SIGUSR1[soft,tls-error] received, process restarting Thu Jul 30 21:04:02 2015 Restart pause, 2 second(s) OpenVPN tls error: tls key negotiation failed to occur within 60 seconds
Если клиенту OpenVPN не подключиться к серверу или это подключение нестабильное, периодически прерывается, а в логе клиента есть ошибка » tls error: tls key negotiation failed to occur within 60 seconds «, то это может быть из-за проблем в соединении:
1) Подвис firewall на сервере (да, такое тоже бывает, connection tracker затупил или еще что, может, не отвисло какое-то соединение). Просто обновите применение правил на сервере.
2) На клиенте проблема с исходящими на порт OpenVPN (по-умолчанию, 1194/udp). Проверить firewall на клиенте.
3) На клиенте вообще проблема с сетью — перезагрузите клиентский компьютер (пусть клиент не жалуется, что у него, дескать, все работает, кроме. ).
4) Проверить корректность указания адреса сервера в конфиге клиента (директива remote )
5) Количество клиентов OpenVPN превысило указанное в директиве max-clients на сервере).
6) Роутер клиента подвисает, глючит провайдер клиента.
7) Глючит провайдер сервера OpenVPN. Поверять стабильность пингами, трассировками и др.
Авторизуйтесь для добавления комментариев!
Почтовый сервер Mikrotik VPN 3proxy Шифрование Squid Резервное копирование Защита почты Виртуальные машины Настройка сервера java kvm Групповые политики SELinux OpenVPN IPFW WDS Lightsquid Samba firewalld systemd Mobile libvirt Remote desktop WiFi Iptables NAT Postfix Dovecot Удаление данных Софт Безопасность Winbox User agent Хостинг Передача данных Онлайн сервисы Privacy LetsEncrypt VPN сервер Настройка прокси RRDTool sendmail Rsync Linux SSH Система Windows Синхронизация Облако fail2ban FreeBSD