Problème OpenVPN - La négociation de la clé TLS n'a pas pu se produire dans les 60 secondes

Je configure un serveur OpenVPN (version 2.3.10) sur un serveur Windows 2012 mais je ne peux pas le faire fonctionner.

Le serveur est derrière un routeur et j'ai ouvert le port 1194 et créé une règle pour transmettre le trafic sur ce port au serveur.

Voici le journal que je vois sur le serveur lorsque j'essaie de me connecter à partir d'un client:

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

Où XX.XX.XX.XX est l'IP du client. Je comprends donc que le client est au moins en mesure d'arriver au serveur, donc il n'y a pas de problèmes de routage ou de pare-feu.

J'ai suivi la description fournie ici. Guide Windows simple Des idées?

Ce qui est intéressant, c'est comment le numéro de port change en cours de route:

21 mars 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: paquet initial de [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

21 mars 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: paquet initial de [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

Cela me fait penser que, quelque part entre le client et le serveur, il y a un périphérique NAT qui se comporte mal, un périphérique avec des entrées de table d'état de très courte durée, qui modifie le numéro de port source qu'il applique au flux établi du client, ce qui provoque le serveur à pense que deux communications de courte durée sont en cours, au lieu d'une communication continue.

Ces périphériques ne le font généralement qu'avec UDP, je vous ai donc conseillé de confirmer que vous utilisez UDP et d'essayer TCP à la place. C'est ce que vous avez fait et avez constaté que cela résout le problème. L'étape suivante consiste à identifier le périphérique NAT qui se comporte mal, à le frapper avec un marteau club et à le remplacer par un autre qui ne commet pas l'erreur cardinale de supposer que toutes les communications UDP sont éphémères; mais vous avez indiqué que vous êtes satisfait de passer à TCP comme solution de contournement, et donc l'affaire est terminée.

C'est l'une des erreurs les plus courantes dans la configuration d'Openvpn et il existe une entrée FAQ pour cela. Je vais citer ceci ici:

Erreur TLS: la négociation de la clé TLS n'a pas pu se produire dans les 60 secondes (vérifiez votre connectivité réseau)

L'un des problèmes les plus courants lors de la configuration d'OpenVPN est que les deux démons OpenVPN de chaque côté de la connexion sont incapables d'établir une connexion TCP ou UDP l'un avec l'autre.

Ceci est presque le résultat de:

• Un pare-feu de périmètre sur le réseau du serveur filtre les paquets OpenVPN entrants (par défaut, OpenVPN utilise le port UDP ou TCP numéro 1194).
• Un pare-feu logiciel s'exécutant sur la machine serveur OpenVPN elle-même filtre les connexions entrantes sur le port 1194. Sachez que de nombreux systèmes d'exploitation bloqueront les connexions entrantes par défaut, sauf configuration contraire.
• Une passerelle NAT sur le réseau du serveur n'a pas de règle de transfert de port pour TCP / UDP 1194 vers l'adresse interne de la machine serveur OpenVPN.
• La configuration du client OpenVPN n'a pas l'adresse de serveur correcte dans son fichier de configuration. La directive distante dans le fichier de configuration client doit pointer soit vers le serveur lui-même, soit vers l'adresse IP publique de la passerelle du réseau de serveurs.
• Une autre cause possible est que le pare-feu Windows bloque l'accès au binaire openvpn.exe. Vous devrez peut-être la mettre sur liste blanche (l'ajouter à la liste "Exceptions") pour qu'OpenVPN fonctionne.

Il est fort probable que l'un de ces problèmes provoque également le même problème dans votre cas. Il suffit donc de parcourir la liste une par une pour la résoudre.

Réf: erreur TLS: la négociation de la clé TLS n'a pas pu se produire dans les 60 secondes (vérifiez votre connectivité réseau)

J'obtenais des délais d'attente de négociation de clés TLS comme celui-ci. Mais dans mon cas, j'ai réalisé que la liaison distante était une adresse IP locale.

Le VPN sur notre pare-feu pfSense avait été par erreur placé sur l'interface LAN au lieu de l'interface WAN, et donc la configuration exportée était configurée pour essayer de se connecter à l'adresse IP LAN du pare-feu - qui n'allait jamais fonctionner avec le client étant naturellement sur un LAN différent.

Je pense que les principaux enseignements à en tirer sont les suivants:

• L'obtention d'un délai de négociation clé ne signifie pas nécessairement que vous avez même réussi à vous connecter à quoi que ce soit.

  À ce stade, il peut donc être utile de vérifier que vous vous connectez réellement au bon endroit, et qu'aucune règle de pare-feu ne bloque la connexion, etc. Surtout si votre configuration a été générée automatiquement.

  Notez que l'obtention d'une invite de connexion ne signifie pas que vous êtes connecté , car OpenVPN vous demande vos informations d'identification avant d'essayer de vous connecter.

• Assurez-vous que votre serveur VPN écoute sur la bonne interface.

  (Bien sûr, c'est l'une des nombreuses erreurs de configuration côté serveur qui peuvent se produire, telles que les règles de pare-feu, la mise en place du mauvais numéro de port, le mélange de TCP et UDP, etc.)

J'ai eu la même erreur et aucun conseil n'a aidé, tout semblait aller bien: adresses IP, ports, pare-feu, tout. Est devenu fou pendant 2 heures.

La solution était de changer le protocole d'UDP en TCP dans la configuration client (apparemment j'ai désactivé UDP exprès il y a longtemps).

J'espère que cela aide quelqu'un :)

LE: cela a résolu mon problème mais ce n'est pas la meilleure approche selon les commentaires ci-dessous. Vous devez utiliser UDP au lieu de TCP. Cela m'a aidé car j'avais des paramètres différents entre les configurations client et serveur.

Notez que vous pouvez obtenir une erreur de négociation de clé TLS, sans vous connecter avec succès au serveur OpenVPN - ou même avec succès vous connecter à quoi que ce soit!

J'ai modifié une configuration VPN pour me connecter à localhost, sur un port qui n'écoutait rien:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] construit le 26 avril 2018
Windows version 6.2 (Windows 8 ou supérieur) 64 bits
versions de bibliothèque: OpenSSL 1.1.0h 27 mars 2018, LZO 2.10
TCP / UDP: conservation de l'adresse distante récemment utilisée: [AF_INET] 127.0.0.1:12345
Lien UDP local (lié): [AF_INET] [undef]: 0
Liaison UDP distante: [AF_INET] 127.0.0.1:12345 
Erreur TLS: la négociation de la clé TLS n'a pas pu se produire dans les 60 secondes (vérifiez votre connectivité réseau)
Erreur TLS: échec de la négociation TLS
SIGUSR1 [soft, tls-error] reçu, redémarrage du processus
...

L'erreur peut vous endormir dans un faux sens que vous parlez à un serveur VPN.

Vous pouvez même être invité à fournir des informations d'identification en premier, mais rien en dehors de votre ordinateur ne les a réellement demandées.

Aucune des solutions mentionnées précédemment n'a fonctionné. Dans mon cas, même si le journal client a montré la même erreur TLS Error: TLS key negotiation failed to occur within 60 seconds, les journaux du serveur ont montré VERIFY ERROR: depth=0, error=CRL has expired.

Sur le serveur, les étapes suivantes ont résolu le problème de connexion:

# 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

J'ai rencontré cette erreur dans AWS, où OpenVPN a été installé sur un serveur avec une IP publique, mais sur une instance qui se trouvait dans un sous-réseau privé, c'est-à-dire un sous-réseau qui n'avait pas de route vers une passerelle Internet.

Une fois que j'ai déployé OpenVPN sur un serveur au sein d'un sous-réseau public, tout a bien fonctionné :)

Sur les sous-réseaux publics / privés dans AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

J'ai également rencontré le TLS key negotiation failed to occur within 60 secondsproblème.

D'après la suggestion officielle, comme Diamant post, il doit y avoir quelque chose de mal dans la connexion réseau. Cependant, ni le pare-feu ni le NAT ne provoquent le problème.

Dans mon cas, j'ai d'abord vérifié la connexion par nc -uvz xxx.xxx.xxx.xxx 1194. Le lien est OK.

En outre, plusieurs autres clients VPN dans le même réseau local fonctionnent correctement.

De quelque part, j'ai remarqué que la connexion udp a des problèmes de réponse ou de transfert de port.

J'arrête donc les clients vpn en cours d'exécution de la plus grande adresse IP au client suspendu, par exemple, de "10.8.0.100" à "10.8.0.50".

Ensuite, démarrez les clients vpn arrêtés à l'envers.

Coup! Tous les clients VPN fonctionnent correctement.

En conclusion, il y a une chance conduit au TLS key negotiation failed to occur within 60 secondsproblème que plusieurs clients vpn au sein d'un LAN démarrent dans une mauvaise séquence.

Une raison possible est que si le serveur requiert une version TLS plus récente, alors le TLS pris en charge par le client. soit 1,2 vs 1,0.

La chose évidente à essayer est de mettre à jour le client OpenVPN ou de modifier le côté serveur pour accepter TLS 1.0.