[RESOLU] openVPN (tls-error) ?



  • 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.



  • 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 ...



  • 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 ?



  • 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 !)



  • 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.



  • 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 :-)



  • 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 !



  • 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 ;)



  • 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.



  • @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