Problema do OpenVPN - a negociação da chave TLS falhou em 60 segundos

Question

Estou configurando um servidor OpenVPN (versão 2.3.10) em um servidor Windows 2012, mas não consigo fazê-lo funcionar.

O servidor está atrás de um roteador e eu abri a porta 1194 e criei uma regra para encaminhar o tráfego nessa porta para o servidor.

Aqui está o log que eu vejo no servidor quando tento me conectar de um cliente:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

Onde XX.XX.XX.XX é o ip do cliente. Então, eu entendo que o cliente, pelo menos, é capaz de chegar ao servidor, então não há problemas de roteamento ou firewall.

Eu segui a descrição fornecida aqui Guia Fácil do Windows Alguma idéia?

    

Answer 1

O que é interessante é como o número da porta muda no meio do fluxo:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3

Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525

Isso me faz pensar que, em algum lugar entre cliente e servidor, há um dispositivo NAT com comportamento inadequado, um dispositivo com entradas de tabela de estado de vida muito curta, que está alterando o número da porta de origem que ele aplica ao fluxo estabelecido do cliente, causando o servidor pensa que duas comunicações de curta duração estão em andamento, em vez de uma contínua.

Esses dispositivos geralmente só fazem isso com o UDP, então eu o aconselhei a confirmar que você está usando o UDP e tente o TCP. Isso você fez e descobriu que isso resolve o problema. O próximo passo é identificar o mau funcionamento do dispositivo NAT, atingi-lo com um martelo de tacos e substituí-lo por um que não cometa o erro cardinal de assumir que todas as comunicações UDP são efêmeras; mas você indicou que está feliz em mudar para o TCP como uma solução alternativa e, assim, o assunto está concluído.

    

Answer 2

Este é um dos erros mais comuns na configuração do OpenVPN e há uma entrada de FAQ para isso. Eu vou citar isso aqui:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other.

This is almost a result of:

• A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
• A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
• A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
• The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
• Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.

É altamente provável que qualquer um deles esteja causando o mesmo problema no seu caso também. Então, basta ir pela lista, um por um, para resolvê-lo.

Ref: Erro TLS: a negociação da chave TLS falhou em 60 segundos (verifique sua conectividade de rede)

    

Answer 3

Eu tive o mesmo erro e nenhum conselho ajudou, tudo parecia estar bem: IPs, portas, firewall, tudo. Fiquei louco por duas horas.

A solução foi mudar o protocolo de UDP para TCP na configuração do cliente (aparentemente eu desativei o UDP propositadamente há muito tempo).

Espero que isso ajude alguém:)

LE: isso resolveu meu problema, mas não é a melhor abordagem conforme os comentários abaixo. Você deve usar o UDP em vez do TCP. Isso me ajudou porque eu tinha configurações diferentes entre o cliente e as configurações do servidor.

    

Answer 4

Eu estava obtendo tempos limite de negociação de chave TLS como este. Mas no meu caso, percebi que o link remoto era um endereço IP local.

A VPN em nosso firewall pfSense foi colocada na interface LAN em vez da interface WAN e, portanto, a configuração exportada foi definida para tentar se conectar ao endereço IP da LAN do firewall - que nunca funcionaria com o cliente naturalmente estando em uma LAN diferente.

Acho que os principais argumentos são:

• Obter um tempo limite de negociação de chave não significa necessariamente que você esteja conectado a um servidor VPN.

  Então, neste estágio, ainda vale a pena verificar se você está realmente se conectando ao lugar certo, e não há regras de firewall bloqueando a conexão, etc. Principalmente se sua configuração foi gerada automaticamente.

• Verifique se o seu servidor VPN está escutando na interface certa

  (Claro, essa é uma das várias configurações incorretas do servidor que podem ocorrer, como regras de firewall, colocando o número de porta errado, misturando TCP e UDP, etc.)

Answer 5

Note que você pode obter um erro de negociação de chave TLS, sem conectar-se com êxito ao servidor OpenVPN - ou até mesmo se conectar a qualquer coisa com sucesso!

Eu modifiquei uma configuração VPN para conectar ao host local, em uma porta que não estava escutando nada:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Windows version 6.2 (Windows 8 or greater) 64bit
library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:12345
UDP link local (bound): [AF_INET][undef]:0
UDP link remote: [AF_INET]127.0.0.1:12345
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, process restarting
...

O erro pode levar você a uma falsa impressão de que você está falando com um servidor VPN.

Você pode até receber uma solicitação de credenciais primeiro, mas nada do lado de fora do seu computador realmente as solicitou.

    

Answer 6

Eu encontrei esse erro na AWS, onde o OpenVPN foi instalado em um servidor com um IP público, mas em uma instância que estava em uma sub-rede privada, ou seja, uma sub-rede que não tinha uma rota para um gateway da Internet. / p>

Uma vez que eu implantei o OpenVPN em um servidor dentro de uma sub-rede pública, tudo funcionou bem:)

Em sub-redes públicas / privadas na AWS: link