Problème port OpenVPN

agire

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

fab_d

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

chris4916

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

jdh

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

agire

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!

chris4916

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

jdh

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

fab_d

@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

agire

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!