Problème port OpenVPN



  • Bonsoir tout le monde,

    Je suis débutant sur Pfsense et je m'arrache les cheveux dessus pour l'instant!

    Ma situation:
    Il est nécessaire dans notre infra de mettre en place un serveur OpenVPN pour pouvoir administrer notre LAN depuis n'importe où

    Matériel:
    VM debian
    pfsense version : actuellement 2.2.6 (AMD64)

    Topologie et config:

    WAN <–--------->Pfsense <--------> LAN
                            (openVPN)

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

    server mode : Remote access (user auth)
        protocol : UDP
        Device mode : tun
        interface: WAN | port : 443
        TLS authentication: 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
        DH : 2048|encrypt AES-256-CBC | auth: SHA1
        Certificate depth: One(Client+Server)

    ip tunnel : 10.0.2.0/24
        ip network 192.168.1.0/24

    Règles firewall:
    -> wan :autorise le trafic pour le port 443 en UDP (crée via le WIZARD)
    -> openvpn: autorise any any

    Mon problème:

    Impossible de me connecter à mon VPN depuis mon client

    Quote

    Wed May 25 22:49:23 2016 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug  4 2015
    Wed May 25 22:49:23 2016 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
    Wed May 25 22:49:33 2016 Control Channel Authentication: using 'pfSense-udp-443-vpnuser-tls.key' as a OpenVPN static key file
    Wed May 25 22:49:33 2016 UDPv4 link local (bound): [undef]
    Wed May 25 22:49:33 2016 UDPv4 link remote: [AF_INET]195.154.xxx.xxx:443
    Wed May 25 22:50:33 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Wed May 25 22:50:33 2016 TLS Error: TLS handshake failed
    Wed May 25 22:50:33 2016 SIGUSR1[soft,tls-error] received, process restarting

    diagnostique et remarques

    J'ai déjà recrée plusieurs fois le serveur ainsi que redemarré.
    J'ai fais un NMAP sur mon serveur et seul le port 22 et  3389 sont ouverts (ouverts pour d'autres besoin) le port 443 lui n'apparait pas.
    Si j'ajoute une règle pour ouvrir le port 443 vers une autre machine (le vcenter par exemple) mon NMAP me retourne  bien que le port est ouvert…
    PS : j'ai chosi le port 443 car à mon école c'est malheureusement un des seul port ouvert sur leur firewall

    Aurais-je mal crée mes règles ? Sachant que cette règle a été crée directement par le Wizard.

    Je vous remercie d'avance pour l'aide que vous pouvez m'apporter



  • Salut agire,

    jolie présentation (enfin disons jolie reprise de la mienne, mais ça signifie qu'elle était bien faite :p)

    Alors moi, je suis perturbé par l'emploi du port 443 (https ?)
    Je serai toi je resterai sur 1194 ou bien tu fais comme moi et prend 11394, mais pas utilisé un port faisant partir du range <1024 (ports réservés)

    pour la partie

    TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Wed May 25 22:50:33 2016 TLS Error: TLS handshake failed

    Dans mon labo de test perso comme tu as pu le lire ça marche, mais dans la version prod mon collègue a le même message d'erreur.

    Pourrais-tu faire un test et désactiver ton firewall de ta machine physique ?
    peux-tu afficher le contenu de ton fichier .ovpn ?

    Voilà, je pense que si on arrive à résoudre un des deux postes on y sera :D

    ps: en général, on cache son adresse IP publique (les derniers octets) pour éviter de se prendre une attaque dessus :-)



  • @fab_d:

    Alors moi, je suis perturbé par l'emploi du port 443 (https ?)
    Je serai toi je resterai sur 1194 ou bien tu fais comme moi et prend 11394, mais pas utilisé un port faisant partir du range <1024 (ports réservés)

    L'emploi du port 443 est en fait assez courant car c'est le moyen efficace d'établir un tunnel dans des environnements ou seuls HTTP/HTTPS sont autorisés au niveau du FW coté client VPN.
    Même si dans le principe je trouve ça nul, c'est très efficace.

    ps: en général, on cache son adresse IP publique (les derniers octets) pour éviter de se prendre une attaque dessus :-)

    :)

    Si tu affiches dans un forum en français que tu as un service VPN sur cette IP publique, ça donne en effet une petite information à une part très limitée de la population susceptible de t'attaquer.
    Si tu regardes bien la source des attaques que tu dois subit quotidiennement, il y en a finalement assez peu qui viennent de France, beaucoup font du port scanning et du coup l'intérêt de l'information que tu as publié est faible, donc la pseudo protection que tu penses avoir en ne publiant pas cette information est faible également  :-X

    Là où il peut être intéressant de ne pas publier cette IP publique, c'est éventuellement pour les aspects de "social engineering" qui permettraient de faire l'association entre cette IP et la société ou la personne qui détient le domaine associé.
    Dans ce cas, c'est une IP de Online.net (poneytelecom) donc ça ne te mène pas bien loin.

    En ce qui concerne la gestion des certificats à la fois pour le serveur OpenVPN et les clients (pour des comptes créés dans pfSense via l'interface), l'outil d'export fonctionne très bien. Les seuls pièges potentiels sont ceux liés justement à l'adresse IP qui va éventuellement apparaitre dans le fichier de conf en fonction des choix effectués lors de l'export.
    Pour la partie certificat, je n'ai jamais rencontré de problème, à savoir que le bundle contient bien les certificats décrits par la conf et ceux-ci sont bien générés (si on prend soin d'activer l'option) lors de la création des comptes utilisateur.



  • Le choix du port d'OpenVPN :

    Qui n'a jamais pensé qu'utiliser https (443/tcp) est la solution idéale ?
    En effet, ne maitrisant pas le réseau utilisé par le client, il est probable qu'https soit autorisé en sortie.
    De plus, il y a des solutions pour, côté serveur, séparer le flux OpenVPN et un flux véritablement https (vers un serveur web).

    Mais ici, c'est 443/udp qui est choisi ! Donc l'idée n'est pas remplie !!

    Il faut rappeller que (d'après le site OpenVPN) :

    • il est préférable de rester sur udp pour des raisons de performances : encapsuler du tcp dans du tcp dégrade la performance
    • le port usuel est 1194/udp
    • il peut-être judicieux de changer le 1194 en une autre port (de préférence >1024, oui) pour éviter le scan typique (nmap) qui, par défaut, ne scanne que les ports usuels (qq centaines de ports)

    Concernant TLS,
    j'ai rappelé que le site OpenVPN recommande le renforcement avec TLS qui se paramètre de la façon suivante :

    • côté serveur : cochez la case TLS authentification, et copiez le contenu de la case suivante dans un fichier 'tls-xxxx.key'
    • côté client : ajoutez le fichier 'tls-xxxx.key' dans conf, et insérez la ligne 'tls-auth tls-xxxx.key 1' dans le .ovpn
      (la présence de la ligne 'tls-client' n'est pas obligatoire : absente de mon modèle pro)

    L'absence côté client se traduit exactement par le message 'TLS key negotiation failed to occur within 60 seconds (check your network connectivity)'.
    (Ce qui n'est pas le message exact de fab_d).

    Concernant ExportOpenVPN,
    J'ai mentionné un échec la première fois (v1.3), et je n'ai pas réessayé. Mais il est possible que cela fonctionne très bien.
    J'ai donc juste un modèle avec une ligne à modifier et extraire le bon .pkcs12 (regroupe .key et .crt client) : pas trop contraignant.

    (Masquer une ip publique est à conseiller, inversement masquer une ip privée est plutôt idiot :
    n'hésitez pas à modifier votre message : 195.x.x.x est sans ambiguité.)



  • Bonjour,

    Merci déjà de vos réponses rapides et completes!
    Effectivement je me suis inspiré du post de fab_d car il etait bien fait (merci!)
    Je viens de cacher mon ip publique effectivement j'avais pas fait attention…

    Par rapport à mon problème je viens de faire la manip de jdh mais j'ai toujours le meme message d'erreur.
    J'ai desormais sur mon client 3 fichiers :
    pfSense-udp-443-vpnuser.ovpn
    pfSense-udp-443-vpnuser.p12
    pfSense-udp-443-vpnuser-tls.key

    tous extrait de mon serveur dans le fichier .key j'ai copié le contenu de TLS authentification
    Voila le contenu de mon fichier .ovpn :
    dev tun
    persist-tun
    persist-key
    cipher AES-256-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote 195.xxx.xxx.xxx 443 udp
    lport 0
    verify-x509-name "Server_CERT_ne" name
    auth-user-pass
    pkcs12 pfSense-udp-443-vpnuser.p12
    tls-auth pfSense-udp-443-vpnuser-tls.key 1
    ns-cert-type server

    Mais est-ce normal que le nmap sur mon serveur ne detecte pas le port 443 comme ouvert?

    Merci encore de votre aide!



  • @agire:

    Mais est-ce normal que le nmap sur mon serveur ne detecte pas le port 443 comme ouvert?

    il est évident que si le port que tu veux accéder n'est pas ouvert, ça ne va pas marcher :-)

    • le service OpenVPN (si bien démarré) écoute sur le port que tu as configuré
    • il faut effectivement ouvrir ce port au niveau du FW sur l'interface WAN
    • petit point de "détail" : selon comment est configuré ton accès WAN, si tu es par exemple derrière un routeur et que l'IP publique est en fait celle du routeur, il faut bien penser à faire un forward vers pfSense  ;)


  • remote 195.xxx.xxx.xxx 443 udp
    Donc le port utilisé est 443/udp.
    Qui n'est pas https (443/tcp)
    Par conséquent, il faut

    • tester (depuis wan) avec un ''map -sU' (sU permet le scan des ports udp !)
    • depuis pfsense, en shell, verifier par sockstat (equiv de netstat -l)

    Perso, je recommanderai de revenir soit à 1194/udp soit à 443/tcp



  • @jdh:

    Mais ici, c'est 443/udp qui est choisi ! Donc l'idée n'est pas remplie !!

    En effet, j'étais perturbé par le 443 car il était en UDP. Sinon c'est sûr qu'il s'agit d'une bonne solution lorsqu'on a pas la main sur le réseau. :-)

    @chris4916:

    Si tu affiches dans un forum en français que tu as un service VPN sur cette IP publique, ça donne en effet une petite information à une part très limitée de la population susceptible de t'attaquer.
    Si tu regardes bien la source des attaques que tu dois subit quotidiennement, il y en a finalement assez peu qui viennent de France, beaucoup font du port scanning et du coup l'intérêt de l'information que tu as publié est faible, donc la pseudo protection que tu penses avoir en ne publiant pas cette information est faible également  :-X

    Là où il peut être intéressant de ne pas publier cette IP publique, c'est éventuellement pour les aspects de "social engineering" qui permettraient de faire l'association entre cette IP et la société ou la personne qui détient le domaine associé.
    Dans ce cas, c'est une IP de Online.net (poneytelecom) donc ça ne te mène pas bien loin.

    Mieux vaut adopter une bonne politique de sécurité à tout niveau. Dans le cas suivant, il s'agit d'une IP de online.net comme tu le précise, mais si ça n'avait pas été le cas.
    Enfin, il vaut mieux prévenir que guérir.  8)

    @agire: Pourrais-tu nous faire un topo de l'état actuelle de ta config, maintenant que tu as effectué les changements

    • règles de firewall

    • contenu du fichier .ovpn (actuel)

    • logs du serveur openVPN ?

    • tu redémarres le service openVPN de ton serveur ?

      • lorsque tu vas dans Diagnostics > sockets, tu vois bien ton serveur openVPN écoutant sur l'IP wan et le bon port ainsi que le bon protocole ?

      merci



  • Bonjour,

    Merci à tous de vos conseils! J'ai changer le port en 443 TCP et depuis tout fonctionne :)
    En revanche le Nmap ne me remonte pas le port ouvert ce qui est étrange tout de même ?
    Je ne sais pas comment se comporte la règle crée automatiquement par OpenVPN sur le firewall donc peut être qu'elle "n'ouvre" pas le port en temps que tel (IPv4 UDP * * WAN address 443 (HTTPS) * none   OpenVPN OPEN_VPN_NE wizard )
    En tout cas je vous remercie tous de vos conseils constructifs!