openvpn TLS Error: TLS handshake failed
Я настроил два сервера с openvpn, решил проблемы с iptables и drop. Один из серверов так же выступает клиентом второго и подключается к второму серверу.
1. Сервера выдают разные пулы адресов, работают на разных портах. 2. Со своего ПК я подключаюсь к обоим без проблем. т.е. конфиги клиентов рабочие. В syslog я получаю следующее:
Sun Mar 22 17:06:53 2020 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 9 2019 Sun Mar 22 17:06:53 2020 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Sun Mar 22 17:06:53 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Mar 22 17:06:53 2020 Control Channel Authentication: tls-auth using INLINE static key file Sun Mar 22 17:06:53 2020 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Sun Mar 22 17:06:53 2020 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Sun Mar 22 17:06:53 2020 Socket Buffers: R=[212992->212992] S=[212992->212992] Sun Mar 22 17:06:53 2020 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Sun Mar 22 17:06:53 2020 UDPv4 link local: [undef] Sun Mar 22 17:06:53 2020 UDPv4 link remote: [AF_INET]91.122.221.112:1194 Sun Mar 22 17:07:53 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sun Mar 22 17:07:53 2020 TLS Error: TLS handshake failed Sun Mar 22 17:07:53 2020 SIGUSR1[soft,tls-error] received, process restarting Sun Mar 22 17:07:53 2020 Restart pause, 2 second(s) Sun Mar 22 17:07:55 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sun Mar 22 17:07:55 2020 Socket Buffers: R=[212992->212992] S=[212992->212992] Sun Mar 22 17:07:55 2020 UDPv4 link local: [undef] Sun Mar 22 17:07:55 2020 UDPv4 link remote: [AF_INET]**.***.***.112:1194 В логах сервера, примерно то же самое.
Документация говорит, что появление такой проблемы типично в следующих Случаях
Разница между моим ПК и сервером(выступающим в роли клиента) только в том, что во втором работает ovpn server. Со своего ПК я подключаюсь, с сервера(выступающим в роли клиента) не могу.
На сервере(выступающим в роли клиента) открыты порты 1194 и 1195. На сервере(выступающим в роли клиента) более низкая версия openssl. Подскажите куда копать.
andrey7690
22.03.20 16:51:08 MSK
На сервере(выступающим в роли клиента) более низкая версия openssl.
это необходимость или прихоть?
anonymous
( 22.03.20 18:05:56 MSK )
«Отсюда и до обеда» .
Вам в вашей предыдущей теме уже писали
1. Полные пути до всех ключей/сертов/отдельный лог(log-append) чтобы не путаться.
2. Повысить логирование параметр verb 11
3. Запустить openvpn —config /path/config-name
А потом смотреть на выхлопы. Но прежде чем спрашивать, стоит и самому разобраться со своей сетью. Вы так и не осилили нарисовать схему сети. И при этом просите какой-то помощи. Извините телепаты из нас так себе.
anc ★★★★★
( 22.03.20 18:18:29 MSK )
Последнее исправление: anc 22.03.20 18:29:21 MSK (всего исправлений: 2)
Ответ на: комментарий от anonymous 22.03.20 18:05:56 MSK
Это констатация факта. Я не знаю может ли это послужить причиной проблемы.
andrey7690
( 22.03.20 18:19:14 MSK ) автор топика
ты явно попутал стороны рпраметра tls-auth
Anoxemian ★★★★★
( 22.03.20 18:21:41 MSK )
Ответ на: комментарий от Anoxemian 22.03.20 18:21:41 MSK
добавлю: трансопрт между серверами таки сделай на ipsec или wireguard. так у стенда будет лучше кпд.
Anoxemian ★★★★★
( 22.03.20 18:22:33 MSK )
Ответ на: комментарий от Anoxemian 22.03.20 18:22:33 MSK
добавлю: трансопрт между серверами таки сделай на ipsec или wireguard
Вы хотите вызвать разрыв мозга у ТС ? Посмотрите соседнюю тему от него. 🙂
anc ★★★★★
( 22.03.20 18:28:09 MSK )
Ответ на: комментарий от anc 22.03.20 18:28:09 MSK
Я искренне приношу извинения за тот сумбур который вам пришлось вынести из прошлой темы, что такое ipsec, gre я знаю и даже настраивал когда то давно, по кпд мне не принципиально, нужно всеuj несколько sql запросов в день.
andrey7690
( 22.03.20 18:43:24 MSK ) автор топика
Ответ на: комментарий от andrey7690 22.03.20 18:43:24 MSK
Уж простите, но последний пост в вашей предыдущей теме, так же является полной глупостью. Так же там я написал откуда копать нужно, но вы не последовали совету. И не последовали советам других. А продолжаете как писал анон «тыкать».
Ещё раз предлагаю просто спокойно сесть и расписать всё на схеме для себя самого. Тогда станет без разницы хоть ovpn, хоть ipsec, хоть wireguard, хоть tinc и т.д. Разница будет только в настройках. А вот тут мы вам с случае если не получаеться, постараемся помочь.
anc ★★★★★
( 22.03.20 18:55:38 MSK )
Последнее исправление: anc 22.03.20 18:57:47 MSK (всего исправлений: 1)
Ответ на: комментарий от anc 22.03.20 18:18:29 MSK
Сервер(выступает исключительно сервером ovpn)
Цикличный кусок лога:
Sun Mar 22 18:34:09 2020 us=212659 SCHEDULE: schedule_find_least wakeup=[Sun Mar 22 18:34:11 2020 us=135843] pri=267344810 Sun Mar 22 18:34:09 2020 us=212680 PO_CTL rwflags=0x0001 ev=8 arg=0x55c47669e168 Sun Mar 22 18:34:09 2020 us=212701 PO_CTL rwflags=0x0001 ev=7 arg=0x55c47669e068 Sun Mar 22 18:34:09 2020 us=212725 I/O WAIT TR|Tw|SR|Sw [1/136498] Sun Mar 22 18:34:10 2020 us=349899 event_wait returned 0 Sun Mar 22 18:34:10 2020 us=349946 I/O WAIT status=0x0020 Sun Mar 22 18:34:10 2020 us=350421 MULTI: REAP range 240 -> 256 Sun Mar 22 18:34:10 2020 us=350453 **.***.**.**:44533 TIMER: coarse timer wakeup 1 seconds Sun Mar 22 18:34:10 2020 us=350492 **.***.**.**:44533 TLS: tls_multi_process: i=0 state=S_PRE_START, mysid=3ed7a5da 75f3b067, stored-sid=7d49fd1b 15882a54, stored-ip=[AF_INET]**.***.**.**:445$ Sun Mar 22 18:34:10 2020 us=350516 **.***.**.**:44533 TLS: tls_process: chg=0 ks=S_PRE_START lame=S_UNDEF to_link->len=0 wakeup=604800 Sun Mar 22 18:34:10 2020 us=350540 **.***.**.**:44533 ACK reliable_can_send active=1 current=0 : [1] 0 Sun Mar 22 18:34:10 2020 us=350576 **.***.**.**:44533 ACK reliable_send_timeout 16 [1] 0 Sun Mar 22 18:34:10 2020 us=350598 **.***.**.**:44533 TLS: tls_process: timeout set to 14 Sun Mar 22 18:34:10 2020 us=350626 **.***.**.**:44533 TLS: tls_multi_process: i=1 state=S_INITIAL, mysid=83162bd8 97e3e1f4, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC] Sun Mar 22 18:34:10 2020 us=350654 **.***.**.**:44533 TLS: tls_multi_process: i=2 state=S_UNDEF, mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC] Sun Mar 22 18:34:10 2020 us=350689 **.***.**.**:44533 SCHEDULE: schedule_add_modify wakeup=[Sun Mar 22 18:34:12 2020 us=135843] pri=267344810 Sun Mar 22 18:34:10 2020 us=350722 SCHEDULE: schedule_find_least wakeup=[Sun Mar 22 18:34:12 2020 us=135843] pri=1508855979 Sun Mar 22 18:34:10 2020 us=350743 PO_CTL rwflags=0x0001 ev=8 arg=0x55c47669e168 Sun Mar 22 18:34:10 2020 us=350764 PO_CTL rwflags=0x0001 ev=7 arg=0x55c47669e068 Sun Mar 22 18:34:10 2020 us=350788 I/O WAIT TR|Tw|SR|Sw [1/136498] Sun Mar 22 18:34:11 2020 us=487963 event_wait returned 0 Sun Mar 22 18:34:11 2020 us=487999 I/O WAIT status=0x0020 Sun Mar 22 18:34:11 2020 us=488022 MULTI: REAP range 0 -> 16 Sun Mar 22 18:34:11 2020 us=488045 **.***.**.**:44533 TIMER: coarse timer wakeup 1 seconds Sun Mar 22 18:34:11 2020 us=488078 **.***.**.**:44533 SCHEDULE: schedule_add_modify wakeup=[Sun Mar 22 18:34:13 2020 us=135843] pri=1508855979 Sun Mar 22 18:34:11 2020 us=488110 SCHEDULE: schedule_find_least wakeup=[Sun Mar 22 18:34:13 2020 us=14289] pri=1890505480 port 1194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key # This file should be kept secret dh /etc/openvpn/dh2048.pem server 10.9.0.0 255.255.255.0 ifconfig-pool-persist /var/log/openvpn/ipp.txt push "route 10.4.31.0 255.255.255.0" client-to-client keepalive 10 120 tls-auth /etc/openvpn/ta.key 0 # This file is secret key-direction 0 cipher AES-128-CBC auth SHA256 user nobody group nogroup persist-key persist-tun status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log verb 9 explicit-exit-notify 1 Cервер(который выступает как сервер ovpn и клиентом первого сервера)
client dev tun proto udp remote (**.***.**.** 1194 pull-filter ignore redirect-gateway resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun remote-cert-tls server tls-auth ta.key 1 cipher AES-128-CBC auth SHA256 key-direction 1 verb 9 script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf andrey7690
( 22.03.20 19:01:06 MSK ) автор топика
Последнее исправление: andrey7690 22.03.20 19:04:58 MSK (всего исправлений: 2)
Ответ на: комментарий от anc 22.03.20 18:55:38 MSK
Я найду подходящий курс на юдеми и выучу тему построения сетей как отче наш. У меня очень простая сеть, я нарисую схему сегодня до 22.00.
andrey7690
( 22.03.20 19:03:29 MSK ) автор топика
Ответ на: комментарий от andrey7690 22.03.20 19:01:06 MSK
А где пути до сертов у клиента? Я вот в упор не вижу.
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
Ошибки «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
OpenVPN Support Forum
I have successfully spun up an OpenVPN server and connected to it in my network. So far so good.
But I have another network that just allows TLS handshake to be established with well-known TLS certificates. So in this network, I face the «TLS handshake failed».
I am new to OpenVPN. I am looking for a solution to use a domain with a certified TLS to connect to the server. Is it even possible?
ordex OpenVPN Inc. Posts: 444 Joined: Wed Dec 28, 2016 2:32 am Location: IRC #openvpn-devel @ libera.chat
Re: TLS handshake failed!
Post by ordex » Thu Oct 20, 2022 7:50 am
Hi there!
With «another network» you mean «another OpenVPN server»?
When connecting to a specific OpenVPN server you need credentials (i.e. a certificate) that is valid for *that* server.
Zartosht OpenVpn Newbie Posts: 4 Joined: Thu Oct 20, 2022 1:43 am
Re: TLS handshake failed!
Post by Zartosht » Thu Oct 20, 2022 8:34 am
Hey!
No. There is one OpenVPN server. Clients are in different networks.
To be precise, I can connect to the OpenVPN server. But clients in Iran(another network) cannot connect to it. Because they blocked the TLS handshake. As I said, they only allow TLS handshakes for well-known issuers.
I do not know how the OpenVPN handshake works. I think if I can use a domain with a well-known TLS issuer, the problem will fix.
ordex OpenVPN Inc. Posts: 444 Joined: Wed Dec 28, 2016 2:32 am Location: IRC #openvpn-devel @ libera.chat
Re: TLS handshake failed!
Post by ordex » Thu Oct 20, 2022 9:10 am
OpenVPN does not perform a classic TLS handshake like (for example) web browsers.
So probably in Iran they entirely blocking the OpenVPN protocol or the port being used (?)
Zartosht OpenVpn Newbie Posts: 4 Joined: Thu Oct 20, 2022 1:43 am
Re: TLS handshake failed!
Post by Zartosht » Thu Oct 20, 2022 11:02 am
Thanks for the clarification. Is there any documentation on how the TLS handshake works in OpenVPN?
For now, I run a server inside and did ssh port forwarding to the OpenVPN server. People can connect to the OpenVPN server through the inside server. But I was looking for a solution to remove the inside server. Note that the OpenVPN IP is not blocked and can be reached from Iran. Furthermore, I use a different port rather than 1194(the default port).
I should mention that without the inside server, the clients get a «TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)» error. I think the problem occurs before the OpenVPN protocol initiates and the connection cannot be established.
My finding: the server receives the TLS request, then answers it. But the client does not receive the server’s answer.
ordex OpenVPN Inc. Posts: 444 Joined: Wed Dec 28, 2016 2:32 am Location: IRC #openvpn-devel @ libera.chat
Re: TLS handshake failed!
Post by ordex » Thu Oct 20, 2022 11:59 am
It’s very possible that they are intercepting the OpenVPN wire format and just dropping all packets. The TLS handshake is performed like any other handshake, but it happens *inside* the OpenVPN encapsulation. The latter is what might be getting blocked
Zartosht OpenVpn Newbie Posts: 4 Joined: Thu Oct 20, 2022 1:43 am
Re: TLS handshake failed!
Post by Zartosht » Thu Oct 20, 2022 12:45 pm
Thu Oct 20, 2022 11:59 am
It’s very possible that they are intercepting the OpenVPN wire format and just dropping all packets.
Does this answer why it is possible to connect to OpenVPN through an SSH port forwarding?
Thu Oct 20, 2022 11:59 am
The TLS handshake is performed like any other handshake, but it happens *inside* the OpenVPN encapsulation.
I know this might be a silly question. It is not possible to use a signed certificate(like websites), right?
Last edited by Zartosht on Thu Oct 20, 2022 12:49 pm, edited 1 time in total.
ordex OpenVPN Inc. Posts: 444 Joined: Wed Dec 28, 2016 2:32 am Location: IRC #openvpn-devel @ libera.chat
Re: TLS handshake failed!
Post by ordex » Thu Oct 20, 2022 12:48 pm
Thu Oct 20, 2022 12:45 pm
Thu Oct 20, 2022 11:59 am
It’s very possible that they are intercepting the OpenVPN wire format and just dropping all packets.
Does this answer why it is possible to connect to OpenVPN through an SSH port forwarding?
Yeah, in this case the connection looks like a normal SSH connection. What flows inside is not visible to whoever is intercepting it.
Kamal1401 OpenVpn Newbie Posts: 1 Joined: Sat Dec 31, 2022 8:28 am
Re: TLS handshake failed!
Post by Kamal1401 » Sat Dec 31, 2022 8:54 am
I have also the similar problem. I have a Centos 7 server outside Iran, and the IP is not blocked. However, any VPN that I have installed (including Outline, OpenConnect, Wireguard, and OpenVPN) fails to do the TLS handshake with the clients inside Iran. Not to mention that all vpn’s work fine if the client is outside Iran.
I tried anything I could:
— upgrading TLS to TLS1.3,
— VPN obfuscation via auth-crypt and auth-crypt-v2 in Openvpn
— relaxing any key verification by the PAM auth (username and password) in Openvpn.
Nonetheless, the problem persists; After receiving the initial TLS packet from the client, the connection stuck and fails.
Any suggestion to circumvent this governmental internet blockage?
Is there any authorization method in Openvpn which does not need this first initial TLS packet?
9 posts • Page 1 of 1
- Announcements
- Forum & Website Support
- Community Project
- ↳ Server Administration
- ↳ Configuration
- ↳ Examples
- ↳ Routed Example
- ↳ Installation Help
- ↳ Tutorials
- ↳ Testing branch
- ↳ Scripting and Customizations
- ↳ Authentication Scripts
- ↳ Routing and Firewall Scripts
- ↳ Rolling Your Own Installer
- ↳ Wishlist
- ↳ Cert / Config management
- ↳ Easy-RSA
- OpenVPN Inc. enterprise business solutions
- ↳ The OpenVPN Access Server
- ↳ CloudConnexa (previously OpenVPN Cloud)
- ↳ OpenVPN Connect (Windows)
- ↳ OpenVPN Connect (macOS)
- ↳ OpenVPN Connect (Android)
- ↳ OpenVPN Connect (iOS)
- Off Topic, Related
- Braggin’ Rights
- ↳ My VPN
- ↳ Doh!
- Pay OpenVPN Service Provider Reviews/Comments
- HomeBoard index
- All times are UTC
- Delete cookies