[RESOLU] openVPN (tls-error) ?

fab_d · May 26, 2016, 12:21 PM

Bonsoir tout le monde,

Je me permets de venir vers vous, car j'ai besoin d'un second regard sur le problème.
Je pense que j'ai tellement tourné autour du problème que je n'ai plus le recule suffisant :-\

Ma situation:
Il m'a été demander de mettre en place une connexion VPN avec authentification login/password + OTP.
Le but serait de ne plus avoir de certificat pour les utilisateurs mais uniquement le token OTP (software)

Matériel:
Apu plateform : apu1d4
pfsense version : actuellement 2.3.1 (AMD64) || la version originale était la 2.1.4 puis j'ai effectué une upgrade vers 2.3 (AMD64)

Topologie et config:

Pfsense <–------> OTPserver included (freeRadius + proxy LDAP) <-----------> LDAP (AD 2012R2)
(openVPN)

J'ai donc configuré mon serveur openVPN selon les paramètres suivants:

server mode : Remote access (user auth)
backend for authentication : mon serveur OTP (j'ai vérifié la connexion grâce à l'outils "authentication" situé dans diagnostique)
protocol : UDP
Device mode : tun
interface: WAN | port : 11394
TLS authentication: not enable
Peer Certificate Authority: j'ai généré le CA via pfsense
Server certificat : j'ai généré un certificat de type serveur sur base du CA (précédent)
DH : 1024 |encrypt AES-256-CBC | auth: SHA1
Certificate depth: pas de check

ip tunnel : 10.0.8.0/24
ip network 192.168.0.0/16
DNS server enable : oui et j'ai défini 2 IPs que sont les serveurs DNS interne à l'infra.
custom options : NOTHING

J'utilise le package "openVPN export" pour exporter mes fichiers de config -> j'obtiens donc un fichier .ovpn et un .crt

Règles firewall:
-> wan :autorise le trafic pour le port 11394 en UDP
-> openvpn: autorise any any

Mon problème:

Lorsque j'effectue mes tests, j'ai donc un pc portable avec GNS3/VMwareWorkstation (simulant l’infrastructure) et une seconde machine physique dans mon réseau comme client pour le VPN, elle utilise les fichiers .ovpn et .crt => ça marche nickel

J'effectue la même configuration sur le pfsense de l'infrastructure et lorsque je tente de me connecter en VPN sur l'infra. (par l'intermédiaire de la connexion 4G partagée de mon téléphone à mon pc pour me mettre en condition réelle).
=> pas moyen, j'obtiens la sortie logs suivantes dans le openVPN client:

Tue May 24 08:59:52 2016 us=279466 OpenVPN 2.3.11 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Tue May 24 08:59:52 2016 us=279466 Windows version 6.1 (Windows 7) 64bit
Tue May 24 08:59:52 2016 us=279466 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.09
Enter Management Password:
Tue May 24 08:59:52 2016 us=279466 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25341
Tue May 24 08:59:52 2016 us=279466 Need hold release from management interface, waiting…
Tue May 24 08:59:52 2016 us=767005 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25341
Tue May 24 08:59:52 2016 us=867013 MANAGEMENT: CMD 'state on'
Tue May 24 08:59:52 2016 us=867013 MANAGEMENT: CMD 'log all on'
Tue May 24 08:59:52 2016 us=939519 MANAGEMENT: CMD 'hold off'
Tue May 24 08:59:52 2016 us=942019 MANAGEMENT: CMD 'hold release'
Tue May 24 09:00:07 2016 us=785707 MANAGEMENT: CMD 'username "Auth" "yyyyy"' (censure du login)
Tue May 24 09:00:07 2016 us=788207 MANAGEMENT: CMD 'password […]'
Tue May 24 09:00:07 2016 us=995723 LZO compression initialized
Tue May 24 09:00:07 2016 us=998224 Control Channel MTU parms [ L:1558 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Tue May 24 09:00:07 2016 us=998224 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue May 24 09:00:07 2016 us=998224 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
Tue May 24 09:00:07 2016 us=998224 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Tue May 24 09:00:07 2016 us=998224 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Tue May 24 09:00:07 2016 us=998224 Local Options hash (VER=V4): '22188c5b'
Tue May 24 09:00:07 2016 us=998224 Expected Remote Options hash (VER=V4): 'a8f55717'
Tue May 24 09:00:07 2016 us=998224 UDPv4 link local (bound): [undef]
Tue May 24 09:00:07 2016 us=998224 UDPv4 link remote: [AF_INET]193.190.XXX.XXX:11394 (censure de l'IP)
Tue May 24 09:00:07 2016 us=998224 MANAGEMENT: >STATE:1464073207,WAIT,,,
Tue May 24 09:01:07 2016 us=306033 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue May 24 09:01:07 2016 us=306033 TLS Error: TLS handshake failed
Tue May 24 09:01:07 2016 us=306033 TCP/UDP: Closing socket
Tue May 24 09:01:07 2016 us=306033 SIGUSR1[soft,tls-error] received, process restarting

diagnostique et remarques

diag:
-> service openVPN stop/restart/supprimer et recréer le serveur openVPN
-> firewall a été reboot
remarques:

Lors de mes tentatives de connexion, il semblerait que le pfsense "ralentisse" voir "freeze temporairement" car les membres en interne perdent la connexion internet.

si je tente la connexion au serveur OpenVPN depuis l'intérieur de mon infra tout en gardant le fichier de config client avec l'ip WAN ça établit la connexion VPN, mais je ne peux rien faire…(à ne rien y comprendre...)

#la société possède un autre serveur OpenVPN en mode "Remote access SSL/TLS" et il marche sans problème.

Est-ce que j'aurais raté quelque chose d’essentielle dans ma config ? :-\

je vous remercie d'avance pour l'aide ou les conseils.

jdh · May 25, 2016, 8:05 AM

Bonne présentation de votre fil : il y a des infos, bravo !

J'utilise une config 'standard' :

certificats (générés par System > Cert manager, sans mot de passe),
serveur en 'Remote Access (SSL/TLS)',
création manuelle des fichiers .opvn,
copie des .pkcs12.
Il est notable que je coche 'TLS authentification' (Yes) et que j'ajoute copie du contenu de la zone suivante dans un fichier tls_xxxx.key et une ligne 'tls-auth tls-xxxx.key 1'.
(Mon premier essai de OpenVPN export ayant échoué, je n'ai pas confiance, et, avec un fichier .pkcs12, je n'ai juste qu'une ligne à modifier !)

Quelque fois, j'ai oublié de copier ce fichier tls_xxxx.key, et j'obtenais … le message d'erreur 'TLS Error: TLS key negotiation failed'.
Il me semble qu'il faut vérifier attentivement config côté pfSense, fichiers de conf coté client ...

NB : le site d'OpenVPN recommande de renforcer la connexion avec l'usage de TLS ...

fab_d · May 25, 2016, 2:21 PM

Bonjour jdh,

je te remercie du compliment pour la présentation, mais c'est une base essentielle pour se faire comprendre je pense :-)

je pense avoir une configuration standard (enfin logiquement…) ;D

Ce que je ne comprends pas c'est pourquoi j'ai un problème de TLS Error dans la version "prod", alors que dans ma version "testing" ça passe comme une lettre à la poste... ???
Je comprends bien qu'il y a un problème d'échange de clés durant la phase "handshake" au vu du message d'erreur, ce qui résulte que le système ne peut établir la suite de la connexion.

Mais si je me trompe pas, il me faut le fichier .opvn (contenant la config), 1 fichier .crt (certificat du serveur) et donc faudrait que j'ajoute 1 fichier .key (pour avoir un "secret partagé" avec mon openVPN serveur) ?

mon fichier actuel .opvn est le suivant (sachant que TLS authentication: not enable):

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 193.190.XXX.XXX 11394 udp
lport 0
auth-user-pass
ca prod-fw-01-udp-11394-ca.crt
ns-cert-type server
comp-lzo adaptive
verb 5
tun-mtu 1500
dev-type tun
auth-nocache
proto udp

une idée ?

jdh · May 25, 2016, 4:54 PM

Je vois, au moins 1 erreur probable, et 1 difficulté possible :

Je peux présumer que 'tls-client' impose que le serveur ait tls activé, d'où activation (côté serveur) et récupération (indispensable AMHA) de la clé tls.

Le MTU à 1500 me gêne : sur un réseau ethernet classique, cela peut convenir; mais avec une liaison PPPoE, le max est 1492. Par défaut, j'évite d'imposer un MTU !

(D'autres choses non essentielles :
J'ignore pourquoi il y a 2 lignes un peu identiques : 'dev tun' et 'dev-type tun' …
Je réorganiserai les lignes pour 'regrouper' par sujet : p.e. remote + proto + lport = réseau; ...)
Je doute de l'efficacité de comp-lzo mais ...)

Bien comprendre que les config serveur et client doivent être 'parfaitement' coordonnées !

(Concernant la présentation, avec un certain nombre d'habitués, nous avons réfléchi à un formulaire.
les fils de la journée montrent, s'il en est besoin, de la nécessité de fournir de l'information.
Sans respecter le formulaire, vous avez fourni de l'info, et en retour, vous avez des pistes, me semble-t-il ...
Malheureusement certain ne sont pas d'accord !)

ccnet · May 25, 2016, 6:55 PM

J'utilise un fichier de configuration client un peu plus simple :

dev tun
persist-tun
persist-key
cipher AES-192-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 7*.2**.2**.1** 1194 udp
lport 0
verify-x509-name "pfsense.domaine.fr" name
pkcs12 user.p12
tls-auth user-tls.key 1
ns-cert-type server
route-method exe
route-delay 2
auth-user-pass
auth-nocache

En particulier verb 5 et comp-lzo m'ont déjà posé problème. Il y a longtemps. J'évite aussi le mtu.
Après il faut que vous soyez certain de vos identifiants.

fab_d · May 25, 2016, 9:04 PM

bonsoir bonsoir :-)

@jdh:

Je peux présumer que 'tls-client' impose que le serveur ait tls activé, d'où activation (côté serveur) et récupération (indispensable AMHA) de la clé tls.

Possible que ça vient de cela, mais dans mon infra test GNS3/Workstation.. je laisse cette option dans le fichier et n'active pas "TLS authentication" et ça marche tout de même… bon après c'est peut être un coup de chance que ça ne fasse rien en "test"

Le MTU à 1500 me gêne : sur un réseau ethernet classique, cela peut convenir; mais avec une liaison PPPoE, le max est 1492. Par défaut, j'évite d'imposer un MTU !

Oui, je me suis rendu compte de mon erreur de forcer le MTU à cette valeur. Il est préférable que le serveur openVPN négocie la valeur.

(D'autres choses non essentielles :
J'ignore pourquoi il y a 2 lignes un peu identiques : 'dev tun' et 'dev-type tun' …
je m'étais basé sur l'exemple donné sur le site de ubuntu pour le fichier opvn du client

Je réorganiserai les lignes pour 'regrouper' par sujet : p.e. remote + proto + lport = réseau; …)
je viens de le faire
Je doute de l'efficacité de comp-lzo mais …)
c'est le collègue qui a activé cette option… la compression je ne pense pas que ça doit nécessaire

(Concernant la présentation, avec un certain nombre d'habitués, nous avons réfléchi à un formulaire.
les fils de la journée montrent, s'il en est besoin, de la nécessité de fournir de l'information.
Sans respecter le formulaire, vous avez fourni de l'info, et en retour, vous avez des pistes, me semble-t-il …
Malheureusement certain ne sont pas d'accord !)
je comprends parfaitement votre situation, je ne le vis que trop souvent

@ccnet:

J'utilise un fichier de configuration client un peu plus simple :

dev tun
persist-tun
persist-key
cipher AES-192-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 7*.2**.2**.1** 1194 udp
lport 0
verify-x509-name "pfsense.domaine.fr" name
pkcs12 user.p12
tls-auth user-tls.key 1
ns-cert-type server
route-method exe
route-delay 2
auth-user-pass
auth-nocache

En particulier verb 5 et comp-lzo m'ont déjà posé problème. Il y a longtemps. J'évite aussi le mtu.
Après il faut que vous soyez certain de vos identifiants.

Oui, je pense réduire la verbosité à 4 et laisser faire le serveur openVPN pour le MTU

Sinon, j'ai refait des tests dans mon petit labo virtuel.

2 serveurs openVPN (port 11394 et 11395) identiques en configuration, seule différence j'ai activé le "TLS authentication" sur celui dont le port est 11394

Dans un cas, j'ai un répertoire contenant (.ovpn .crt) et dans l'autre cas j'ai un répertoire avec ( .ovpn, .crt et .key)

Fichier opvn avec authentification TLS (NOT enable)

client
tls-client #avec l'option ou sans, le serveur me connecte quand même

remote 192.168.0.34 11395 udp
lport 0
resolv-retry infinite

dev tun

persist-tun
persist-key

cipher AES-256-CBC
auth SHA256

auth-user-pass
ca pfSense-udp-11395-ca.crt
ns-cert-type server
auth-nocache

fichier opvn avec l'authentification TLS (enable)

client
tls-client

remote 192.168.0.34 11394 udp
lport 0
resolv-retry infinite

dev tun

persist-tun
persist-key

cipher AES-256-CBC
auth SHA256

auth-user-pass
auth-nocache
ca pfSense-udp-11394-ca.crt
tls-auth pfSense-udp-11394-tls.key 1
ns-cert-type server

Je peux vous dire qu'à chaque fois ça marche dans mon labo virtuel.
Je ne comprends pas comment ça fait que mon collègue qui test en prod n'arrive pas à obtenir le même résultat. (la seule différence entre lui et moi ? son pc portable et donc son firewall personnel de windows peut-être ?)

Et sur le serveur OTP, je vois que l'authentification "Radius" a répondu positivement, lors de son authentification vpn. Donc ça cible vraiment le problème au niveau du pfsense/openVPN

en tout cas un grand merci de m'aider les gars :-)

jdh · May 26, 2016, 8:07 AM

J'ai des fichiers de conf .ovpn quasi identique : client, proto + remote, resolv-retry, dev tun, persist-, cipher / auth, ca, tls-auth (sans tls-client !), ns-cert, et pkcs puisque authentif par certificats.

Le message 'TLS key negotiation failed to occur within 60 seconds (check your network connectivity)' est typique de problème TLS.
cf https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity.html
Parmi les 5 pistes, l'une des plus vicieuses est l'utilisation de noms dns dans la ligne 'remote' : on lit le bon nom mais la résolution réelle n'est pas correcte !

fab_d · May 26, 2016, 11:59 AM

Bonjour bonjour :-)

Alors j'ai une bonne nouvelle le VPN fonctionne !

Il y avait une affaire d'IP virtuelle qui avait été configurée dans le firewall (par un autre collègue), va savoir ce qu'il voulait faire on a qu'un seul firewall…
Nous avons à nouveau parcouru la config du firewall et tadam ça fonctionne :-)

Il y a juste un élément que je cherche à rectifier, le VPN semble se désactiver au bout de 2min d'inactivité. Il y a moyen de changer cela ? :-)

En tout cas un grand merci à Jdh et Ccnet de votre aide ;)

chris4916 · May 26, 2016, 12:17 PM

Je ne me souviens pas avoir vu le paramètre "keepalive" exposé dans l'interface d'admin de OpenVPN mais tu peux toujours essayer de le préciser dans les options de configuration. Je n'ai cependant pas fait de test pour voir si cette valeur personnalisée va remplacer la valeur par défaut.

fab_d · May 26, 2016, 12:21 PM

@chris4916:

Je ne me souviens pas avoir vu le paramètre "keepalive" exposé dans l'interface d'admin de OpenVPN mais tu peux toujours essayer de le préciser dans les options de configuration. Je n'ai cependant pas fait de test pour voir si cette valeur personnalisée va remplacer la valeur par défaut.

je vais tester dans ce cas et je te redis quoi ;)
merci