Problema de OpenVPN: no se pudo negociar la clave TLS en 60 segundos

Estoy configurando un servidor OpenVPN (versión 2.3.10) en un servidor Windows 2012 pero no puedo hacer que funcione.

El servidor está detrás de un enrutador y abrí el puerto 1194 y creé una regla para reenviar el tráfico de este puerto al servidor.

Aquí está el registro que veo en el servidor cuando intento conectarme desde un 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

Donde XX.XX.XX.XX es la ip del cliente. Por lo tanto, entiendo que al menos el cliente puede llegar al servidor, por lo que no hay problemas de enrutamiento o firewall.

Seguí la descripción provista aquí Guía fácil de Windows ¿Alguna idea?

Lo interesante es cómo cambia el número de puerto a mitad de la secuencia:

Lun Mar 21 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: Paquete inicial de [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Lun Mar 21 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: Paquete inicial de [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

Esto me hace pensar que, en algún lugar entre el cliente y el servidor, hay un dispositivo NAT que se comporta mal, un dispositivo con entradas de tabla de estado de muy corta duración, que está cambiando el número de puerto de origen que se aplica a la secuencia establecida del cliente, haciendo que el servidor Piense que hay dos comunicaciones de corta duración en curso, en lugar de una continua.

Tales dispositivos generalmente solo hacen esto con UDP, por lo que le aconsejé que confirme que está usando UDP y que pruebe TCP en su lugar. Esto lo has hecho y descubriste que soluciona el problema. El siguiente paso es identificar el dispositivo NAT que se comporta mal, golpearlo con un martillo y reemplazarlo con uno que no cometa el error fundamental de suponer que todas las comunicaciones UDP son efímeras; pero ha indicado que está contento con cambiar a TCP como solución alternativa, por lo que el asunto está concluido.

Este es uno de los errores más comunes al configurar Openvpn y hay una entrada de preguntas frecuentes para esto. Voy a citar esto aquí:

Error de TLS: la negociación de la clave TLS no se produjo en 60 segundos (verifique la conectividad de su red)

Uno de los problemas más comunes al configurar OpenVPN es que los dos demonios de OpenVPN a cada lado de la conexión no pueden establecer una conexión TCP o UDP entre sí.

Esto es casi el resultado de:

• Un firewall perimetral en la red del servidor está filtrando los paquetes entrantes de OpenVPN (de forma predeterminada, OpenVPN usa el número de puerto UDP o TCP 1194).
• Un firewall de software que se ejecuta en la máquina del servidor OpenVPN está filtrando las conexiones entrantes en el puerto 1194. Tenga en cuenta que muchos sistemas operativos bloquearán las conexiones entrantes de manera predeterminada, a menos que se configure de otra manera.
• Una puerta de enlace NAT en la red del servidor no tiene una regla de reenvío de puerto para TCP / UDP 1194 a la dirección interna de la máquina del servidor OpenVPN.
• La configuración del cliente OpenVPN no tiene la dirección correcta del servidor en su archivo de configuración. La directiva remota en el archivo de configuración del cliente debe apuntar al servidor o a la dirección IP pública de la puerta de enlace de la red del servidor.
• Otra posible causa es que el firewall de Windows está bloqueando el acceso al binario openvpn.exe. Es posible que deba incluirlo en la lista blanca (agregarlo a la lista de "Excepciones") para que OpenVPN funcione.

Es muy probable que cualquiera de estos también esté causando el mismo problema en su caso. Así que solo revisa la lista uno por uno para resolverlo.

Ref: Error de TLS: la negociación de la clave TLS no pudo ocurrir en 60 segundos (verifique la conectividad de su red)

Estaba obteniendo tiempos de espera de negociación clave de TLS como este. Pero en mi caso me di cuenta de que el enlace remoto era una dirección IP local.

La VPN en nuestro firewall pfSense se colocó por error en la interfaz LAN en lugar de la interfaz WAN, por lo que la configuración exportada se configuró para intentar conectarse a la dirección IP LAN del firewall, que nunca funcionaría con el cliente naturalmente encendido Una LAN diferente.

Creo que las principales conclusiones de esto son:

• Obtener un tiempo de espera de negociación clave no significa necesariamente que incluso haya logrado conectarse a cualquier cosa.

  Por lo tanto, en esta etapa aún puede valer la pena verificar que realmente se está conectando al lugar correcto, y que no hay reglas de firewall que bloqueen la conexión, etc. Particularmente si su configuración se ha generado automáticamente.

  Tenga en cuenta que obtener un mensaje de inicio de sesión no significa que esté conectado , ya que OpenVPN le pide sus credenciales antes de intentar conectarse.

• Asegúrese de que su servidor VPN esté escuchando en la interfaz correcta.

  (Por supuesto, esta es una de una serie de configuraciones incorrectas del lado del servidor que podrían ocurrir, como reglas de firewall, poner el número de puerto incorrecto, mezclar TCP y UDP, etc.)

Tuve el mismo error y ningún consejo me ayudó, todo parecía estar bien: IP, puertos, firewall, todo. Se volvió loco por 2 horas.

La solución fue cambiar el protocolo de UDP a TCP en la configuración del cliente (aparentemente deshabilité UDP a propósito hace mucho tiempo).

Espero que esto ayude a alguien :)

LE: esto resolvió mi problema, pero no es el mejor enfoque según los comentarios a continuación. Debe usar UDP en lugar de TCP. Me ayudó porque tenía diferentes configuraciones entre el cliente y las configuraciones del servidor.

Tenga en cuenta que puede obtener un error de negociación de clave TLS, sin conectarse con éxito al servidor OpenVPN, ¡ o incluso conectarse con éxito a cualquier cosa!

Modifiqué una configuración de VPN para conectarme a localhost, en un puerto que no escuchaba nada:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] construido el 26 de abril de 2018
Windows versión 6.2 (Windows 8 o superior) 64 bits
versiones de la biblioteca: OpenSSL 1.1.0h 27 mar 2018, LZO 2.10
TCP / UDP: preservar la dirección remota utilizada recientemente: [AF_INET] 127.0.0.1:12345
Enlace UDP local (enlazado): [AF_INET] [undef]: 0
Enlace remoto UDP: [AF_INET] 127.0.0.1:12345 
Error de TLS: la negociación de la clave de TLS no se produjo en 60 segundos (verifique la conectividad de su red)
Error de TLS: error de apretón de manos de TLS
SIGUSR1 [soft, tls-error] recibido, proceso reiniciando
...

El error puede inducirlo a una falsa sensación de que está hablando con un servidor VPN.

Incluso es posible que primero se le soliciten las credenciales, pero nada fuera de su computadora realmente las ha solicitado.

Ninguna de las soluciones mencionadas anteriormente funcionó. En mi caso, aunque el registro del cliente mostró el mismo error TLS Error: TLS key negotiation failed to occur within 60 seconds, los registros del servidor mostraron VERIFY ERROR: depth=0, error=CRL has expired.

En el servidor, los siguientes pasos resolvieron el problema de conexión:

# 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

Me encontré con este error en AWS, donde OpenVPN se instaló en un servidor con una IP pública, pero en una instancia que estaba en una subred privada, es decir, una subred que no tenía una ruta a una puerta de enlace de Internet.

Una vez que implementé OpenVPN en un servidor dentro de una subred pública, todo funcionó bien :)

En subredes públicas / privadas en AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

También me encontré con el TLS key negotiation failed to occur within 60 secondsproblema.

Según la sugerencia oficial, como publicación de Diamant, debe haber algo mal en la conexión de red. Sin embargo, ni el firewall ni el NAT causan el problema.

En mi caso, primero verifiqué la conexión nc -uvz xxx.xxx.xxx.xxx 1194. El enlace esta bien.

Además, varios otros clientes vpn dentro de la misma LAN funcionan bien.

Desde algún lugar noté que la conexión udp tiene algunos problemas en respuesta o puerto hacia adelante.

Así que detengo los clientes vpn en ejecución desde la ip más grande hasta el cliente colgado, por ejemplo, de "10.8.0.100" a "10.8.0.50".

Luego, inicie los clientes vpn detenidos a la inversa.

¡Explosión! Todos los clientes vpn trabajan de manera proactiva.

En conclusión, existe la posibilidad de que el TLS key negotiation failed to occur within 60 secondsproblema sea que varios clientes vpn dentro de una LAN comiencen en una secuencia incorrecta.

Una posible razón es si el servidor requiere una versión TLS más nueva que la TLS admitida por el cliente. es decir, 1.2 contra 1.0.

Lo obvio que debe intentar es actualizar el cliente OpenVPN o modificar el lado del servidor para aceptar TLS 1.0.