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

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 vejo no servidor quando tento conectar-me a partir 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. Entendo, a partir disso, que pelo menos o cliente é capaz de chegar ao servidor, portanto não há problemas de roteamento ou firewall.

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

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

Seg 21 de março, 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: Pacote inicial de [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Seg 21 de março, 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: Pacote inicial de [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

Isso me faz pensar que, em algum lugar entre o cliente e o servidor, existe 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 se aplica ao fluxo estabelecido do cliente, fazendo com que o servidor pense que duas comunicações de curta duração estão em andamento, em vez de uma contínua.

Esses dispositivos geralmente fazem isso apenas com o UDP, por isso eu recomendo que você confirme que está usando o UDP e tente o TCP. Você fez isso e descobriu que isso resolve o problema. O próximo passo é identificar o dispositivo NAT com comportamento inadequado, acertá-lo com um martelo e substituí-lo por um que não cometa o erro fundamental de assumir que todas as comunicações UDP são efêmeras; mas você indicou que está satisfeito em mudar para o TCP como uma solução alternativa e, portanto, o assunto está concluído.

Este é um dos erros mais comuns na configuração do Openvpn e existe uma entrada de FAQ para isso. Vou citar isso aqui:

Erro TLS: falha na negociação da chave TLS dentro de 60 segundos (verifique a conectividade da sua rede)

Um dos problemas mais comuns na configuração do OpenVPN é que os dois daemons do OpenVPN dos dois lados da conexão não conseguem estabelecer uma conexão TCP ou UDP entre si.

Isso é quase o resultado de:

• Um firewall de perímetro na rede do servidor está filtrando os pacotes OpenVPN recebidos (por padrão, o OpenVPN usa o número da porta UDP ou TCP 1194).
• Um firewall de software em execução na máquina do servidor OpenVPN está filtrando as conexões de entrada na porta 1194. Esteja ciente de que muitos sistemas operacionais bloqueiam as conexões de entrada por padrão, a menos que configurado de outra forma.
• Um gateway NAT na rede do servidor não possui uma regra de encaminhamento de porta para TCP / UDP 1194 para o endereço interno da máquina do servidor OpenVPN.
• A configuração do cliente OpenVPN não possui o endereço de servidor correto em seu arquivo de configuração. A diretiva remota no arquivo de configuração do cliente deve apontar para o próprio servidor ou para o endereço IP público do gateway da rede do servidor.
• Outra causa possível é que o firewall do Windows está bloqueando o acesso ao binário openvpn.exe. Você pode precisar colocar a lista de permissões (adicioná-la à lista "Exceções") para que o OpenVPN funcione.

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

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

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

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

Eu acho que as principais conclusões disso são:

• Obter um tempo limite de negociação importante não significa necessariamente que você conseguiu se conectar a qualquer coisa.

  Portanto, nesse estágio, ainda pode valer 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.

  Observe que obter um prompt de login não significa que você está conectado , pois o OpenVPN solicita suas credenciais antes de tentar se conectar.

• Verifique se o servidor VPN está escutando na interface correta.

  (Obviamente, essa é uma das várias configurações incorretas do servidor que podem ocorrer, como regras de firewall, colocação do número da porta incorreta, mistura de TCP e UDP, etc.)

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

A solução foi alterar o protocolo de UDP para TCP na configuração do cliente (aparentemente, eu desabilitei o UDP de propósito 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.

Nenhuma das soluções mencionadas anteriormente funcionou. No meu caso, mesmo que o log do cliente tenha mostrado o mesmo erro TLS Error: TLS key negotiation failed to occur within 60 seconds, os logs do servidor mostraram VERIFY ERROR: depth=0, error=CRL has expired.

No servidor, as etapas a seguir resolveram o problema de conexão:

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

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

Modifiquei uma configuração de VPN para conectar-se 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] criado em 26 de abril de 2018
Windows versão 6.2 (Windows 8 ou superior) de 64 bits
versões da biblioteca: OpenSSL 1.1.0h 27 mar 2018, LZO 2.10
TCP / UDP: preservando o endereço remoto usado recentemente: [AF_INET] 127.0.0.1:12345
Local do link UDP (vinculado): [AF_INET] [undef]: 0
Remoto do link UDP: [AF_INET] 127.0.0.1:12345 
Erro no TLS: a negociação da chave TLS falhou em 60 segundos (verifique a conectividade da rede)
Erro TLS: falha no handshake TLS
SIGUSR1 [leve, erro-tls] recebido, processo reiniciado
...

O erro pode levar você a um falso senso de que está falando com um servidor VPN.

Você pode até solicitar credenciais primeiro, mas nada fora do seu computador realmente as solicitou.

Eu encontrei esse erro na AWS, onde o OpenVPN estava 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.

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

Em sub-redes públicas / privadas na AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

Eu também me deparei com o TLS key negotiation failed to occur within 60 secondsproblema.

Pela sugestão oficial, como postagem de Diamant, deve haver algo errado na conexão de rede. No entanto, nem o firewall nem o NAT causam o problema.

No meu caso, verifiquei a conexão pela primeira vez nc -uvz xxx.xxx.xxx.xxx 1194. O link está OK.

Além disso, vários outros clientes VPN na mesma LAN funcionam bem.

De algum lugar, notei que a conexão udp tem alguns problemas de resposta ou de encaminhamento de porta.

Portanto, paro os clientes vpn em execução do maior IP para o cliente suspenso, por exemplo, de "10.8.0.100" para "10.8.0.50".

Em seguida, inicie os clientes vpn interrompidos ao contrário.

Bang! Todos os clientes vpn funcionam adequadamente.

Em conclusão, há uma chance de TLS key negotiation failed to occur within 60 secondsque vários clientes VPN em uma LAN iniciem em uma seqüência incorreta.