Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [RESOLU] openVPN (tls-error) ?

    Scheduled Pinned Locked Moved Français
    10 Posts 4 Posters 9.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      fab_d
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • J
        jdh
        last edited by

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

        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

        1 Reply Last reply Reply Quote 0
        • F
          fab_d
          last edited by

          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 ?

          1 Reply Last reply Reply Quote 0
          • J
            jdh
            last edited by

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

            Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

            1 Reply Last reply Reply Quote 0
            • C
              ccnet
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • F
                fab_d
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • J
                  jdh
                  last edited by

                  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 !

                  Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                  1 Reply Last reply Reply Quote 0
                  • F
                    fab_d
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • C
                      chris4916
                      last edited by

                      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.

                      Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                      1 Reply Last reply Reply Quote 0
                      • F
                        fab_d
                        last edited by

                        @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

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.