[Résolus]Mise en place d'une connexion Vpn



  • Bonjour,

    Après avoir installer et fais une configuration basique de pfsense non sans mal. Je dois mettre en place une connexion vpn dans mon entreprise.

    Schéma:

    Modem/Routeur (wi-fi activer)
              |
              |
          Pare-feu
              |
              |
            Lan

    Les utilisiteurs du wi-fi doivent avoir accès au réseau Lan.Ainsi que les techniciens qui travaillent de chez eux.

    Au niveau du Modem/Routeur le réseau est 192.168.0.0
    Le Lan est 192.168.77.0/24

    J'ai donc fais des recherches et suivis différents tuto mais cela ne fonctionne pas.Je vais donc vous expliquer ce que j'ai fais et les problèmes que je rencontre.

    Tout d'abord sur pfsense j'ai télécharger le package OpenVPN Client Export Utility
    j'ai créer un certificat dans system -> certificate autority manager j'ai rentrer les informations basiques : key lenght 2048 bits, digest algorithm SHA256

    J'ai créer ensuite un utilisateur qui utilise le certificat précédemment créer.

    Puis j'ai configurer l'interface Wan : OpenVpn:Server  j'utilise le protocole UDP,le port par défauts (1194).

    Tunnel Network : 192.168.0.0 /24
    Local Network : 192.168.77.0 /24

    J'exporte le fichier client sur mon mac et j'essaye de me connecter.

    Mon fichier conf :

    #– Config Auto Generated By pfSense for Viscosity --#

    #viscosity startonopen false
    #viscosity dhcp true
    #viscosity dnssupport true
    #viscosity name openvpnserver

    dev tun
    persist-tun
    persist-key
    cipher AES-256-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote 192.168.0.2 1194 udp
    lport 0
    verify-x509-name "thomas" name
    auth-user-pass

    ca ca.crt
    tls-auth ta.key 1
    cert cert.crt
    key key.key

    Quand j'essaye de me connecter avec tunnelblink ca me met cela :

    2015-04-22 10:12:19 *Tunnelblick: openvpnstart starting OpenVPN
    2015-04-22 10:12:20 OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Apr  3 2015
    2015-04-22 10:12:20 library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08
    2015-04-22 10:12:21 *Tunnelblick: Established communication with OpenVPN
    2015-04-22 10:12:29 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:12:29 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
    2015-04-22 10:12:29 UDPv4 link local (bound): [undef]
    2015-04-22 10:12:29 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:13:29 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:13:29 TLS Error: TLS handshake failed
    2015-04-22 10:13:29 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:13:29 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:13:29 UDPv4 link local (bound): [undef]
    2015-04-22 10:13:29 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:13:29 write UDPv4: No route to host (code=65)
    2015-04-22 10:13:31 write UDPv4: Host is down (code=64)
    2015-04-22 10:13:35 write UDPv4: Host is down (code=64)
    2015-04-22 10:13:44 write UDPv4: Host is down (code=64)
    2015-04-22 10:14:29 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:14:29 TLS Error: TLS handshake failed
    2015-04-22 10:14:29 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:14:29 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:14:29 UDPv4 link local (bound): [undef]
    2015-04-22 10:14:29 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:15:00 write UDPv4: No route to host (code=65)
    2015-04-22 10:15:30 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:15:30 TLS Error: TLS handshake failed
    2015-04-22 10:15:30 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:15:30 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:15:30 UDPv4 link local (bound): [undef]
    2015-04-22 10:15:30 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:16:30 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:16:30 TLS Error: TLS handshake failed
    2015-04-22 10:16:30 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:16:30 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:16:30 UDPv4 link local (bound): [undef]
    2015-04-22 10:16:30 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:16:30 write UDPv4: No route to host (code=65)
    2015-04-22 10:16:32 write UDPv4: Host is down (code=64)
    2015-04-22 10:16:36 write UDPv4: Host is down (code=64)
    2015-04-22 10:16:44 write UDPv4: Host is down (code=64)
    2015-04-22 10:17:30 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:17:30 TLS Error: TLS handshake failed
    2015-04-22 10:17:30 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:17:30 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:17:30 UDPv4 link local (bound): [undef]
    2015-04-22 10:17:30 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:18:00 write UDPv4: No route to host (code=65)
    2015-04-22 10:18:30 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:18:30 TLS Error: TLS handshake failed
    2015-04-22 10:18:30 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:18:30 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:18:30 UDPv4 link local (bound): [undef]
    2015-04-22 10:18:30 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:19:30 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:19:30 TLS Error: TLS handshake failed
    2015-04-22 10:19:30 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:19:30 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:19:30 UDPv4 link local (bound): [undef]
    2015-04-22 10:19:30 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:19:30 write UDPv4: No route to host (code=65)
    2015-04-22 10:19:32 write UDPv4: Host is down (code=64)
    2015-04-22 10:19:37 write UDPv4: Host is down (code=64)
    2015-04-22 10:19:45 write UDPv4: Host is down (code=64)
    2015-04-22 10:20:30 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:20:30 TLS Error: TLS handshake failed
    2015-04-22 10:20:30 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:20:30 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:20:30 UDPv4 link local (bound): [undef]
    2015-04-22 10:20:30 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:21:00 write UDPv4: No route to host (code=65)
    2015-04-22 10:21:31 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2015-04-22 10:21:31 TLS Error: TLS handshake failed
    2015-04-22 10:21:31 SIGUSR1[soft,tls-error] received, process restarting
    2015-04-22 10:21:31 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    2015-04-22 10:21:31 UDPv4 link local (bound): [undef]
    2015-04-22 10:21:31 UDPv4 link remote: [AF_INET]192.168.0.2:1194
    2015-04-22 10:21:35 *Tunnelblick: Disconnecting; notification window disconnect button pressed
    2015-04-22 10:21:35 *Tunnelblick: Disconnecting using 'kill'
    2015-04-22 10:21:35 event_wait : Interrupted system call (code=4)
    2015-04-22 10:21:35 SIGTERM[hard,] received, process exiting
    2015-04-22 10:21:37 *Tunnelblick: No 'post-disconnect.sh' script to execute
    2015-04-22 10:21:37 *Tunnelblick: Expected disconnection occurred.

    Merci d'avance.



  • "-Pour le tunnel wisard j'ai sélectionner OpenVpn->Server->Wisard
    Local User Access
    Choose a certificat authority (CA) :CA_Acces_VPN ( le certificat que j'ai créer)
    Choose a sever certificate : CA_Acces_VPN (il me propose que celui-là) c'est ici que j'ai un doute.
    Et donc c'est ici que je dois mettre dans le local network pas 192.168.77.10/24 mais 192.168.77.0/24 ?"

    Oui comme je te le disais tu as entré une ip fixe non une adresse réseau.
    C'est dailleur étonnant que pfSense ne t'ai rien dis a ce propos.
    Ton local network est 192.168.77.0/24

    Un second point qui me tique un peut tu parle du réseau de ton Routeur en 192.168.0.0/24 et ensuite tu parle d'une adresse tunnel 192.168.0.0/24

    Tu as donc deux même réseau pour deux endroit différents ? La ça va poser problème. Je te conseille de changer l'adressage de ton tunnel.



  • "Un second point qui me tique un peut tu parle du réseau de ton Routeur en 192.168.0.0/24 et ensuite tu parle d'une adresse tunnel 192.168.0.0/24"

    Je t'avoue que sur ce point j'ai pas tout compris. Mon réseau au niveau du routeur est 192.168.0.0/24,vu que je me connecte à internet à ce réseau pour la connexion vpn que dois-je mettre à l'adresse tunnel?



  • Il faut essayer, en parallèle, de lire un minimum de documentation sur ces aspects tunneling, que ce soit IPSec ou OpenVPN.
    ça ne peut pas, ou alors très difficilement, tomber en marche en mettant des paramètres au hasard.

    La doc de pfSense, quoique pas très didacticielle, est une bonne recette  :)

    Essaie de la suivre à la lettre, juste pour voir.



  • Tunnel Network : 192.168.0.0 /24

    Pas possible ce réseau doit ne pas être utilisé par ailleurs. Lisez et comprenez les documentations avant de renseigner des paramètres sans les avoir compris.



  • D'accord je vais faire ca. J'ai suivis différents tutos qui ne parler pas des aspects tunnelling.Lors de la configuration du certificat du serveur je choisissez l'option local network et non tunnel network c'est pour ça que je n'y prêter pas attention.



  • @tosmoth:

    Je t'avoue que sur ce point j'ai pas tout compris. Mon réseau au niveau du routeur est 192.168.0.0/24,vu que je me connecte à internet à ce réseau pour la connexion vpn que dois-je mettre à l'adresse tunnel?

    C'est pourtant simple sur la théorie, je vais utiliser une petite méthafore qui illustre bien la chose.

    Imagine sur ta la carte de ta ville tu as deux fois la même adresse pour deux cartiers différents, tu rentre cette adresse dans ton GPS, il ne saura pas te diriger sur la bonne route.

    Ici c'est pareil, tu as deux fois la même adresse pour deux réseau différent, comme l'a dis CCnet un même réseau ne doit pas être utilisé a deux endroit différents.
    Ton premier réseau est celui du routeur le second est celui du tunnel, ça doit être deux adressage différent.
    Tu dois donc définir une autre adresse réseau pour ton tunnel VPN.



  • "Ton premier réseau est celui du routeur le second est celui du tunnel, ça doit être deux adressage différent".
    Pour cela j'avais compris,mais c'est pour l'adresse du tunnel que j'ai pas compris et dont je dois me renseigner. Dois-je créer une adresse de tunnel totalement au-hasard ? ou en rapport avec l'adresse de réseau de mon lan (192.168.77.0/24) et/ou de mon modem (192.168.0.0/24)



  • ton (tes) tunnel DOIT être dans un plan d'adressage distinct, sans aucune collision. c'est très clairement expliqué dans la doc pfSense  ;)
    Et donc ce n'est pas au hasard (tu connais Murphy n'est-ce pas  ;D)



  • Il y a des erreurs à éviter :

    Pour le VPN,

    • la doc est claire : 'Tunnel Network – Should be a new, unique network that does not exist anywhere in the current network or routing table.' Usuellement on utilise 10.0.8.0/24.

    Pour le modem/routeur,

    • ce matériel NE DEVRAIT pas fournir de Wifi : le wifi DEVRAIT être dans le LAN (ou avec une interface WIFI créée dans pfSense).


  • "Pour le VPN,

    • la doc est claire : 'Tunnel Network – Should be a new, unique network that does not exist anywhere in the current network or routing table.' Usuellement on utilise 10.0.8.0/24.

    Pour le modem/routeur,

    • ce matériel NE DEVRAIT pas fournir de Wifi : le wifi DEVRAIT être dans le LAN (ou avec une interface WIFI créée dans pfSense)."

    • ok merci je viens de lire la doc,je vais tester ça.

    • C'est ce que je voulez faire au début mais mon patron ne souhaite pas d'accès wi-fi à l'intérieur du Lan pour la sécurité,c'est pour ça que je dois mettre en place un accès vpn des utilisateur qui sont en wi-fi pour accèder aux serveurs qui sont dans le Lan.



  • @tosmoth:

    • C'est ce que je voulez faire au début mais mon patron ne souhaite pas d'accès wi-fi à l'intérieur du Lan pour la sécurité,c'est pour ça que je dois mettre en place un accès vpn des utilisateur qui sont en wi-fi pour accèder aux serveurs qui sont dans le Lan.

    C'est effectivement une solution.
    Une autre approche serait de mettre le wifi dans une DMZ, et non pas à l'extérieur, afin d'offir des services "interne" aux utilisateurs en wifi sans pour autant qu'ils soient directement sur le LAN



    • C'est ce que je voulez faire au début mais mon patron ne souhaite pas d'accès wi-fi à l'intérieur du Lan pour la sécurité,c'est pour ça que je dois mettre en place un accès vpn des utilisateur qui sont en wi-fi pour accèder aux serveurs qui sont dans le Lan.

    Présenté comme cela, je ne vois pas beaucoup de différence. Ce n'est pas l'acheminement sécurisé qui règle le problème de la connexion d'une machine sur un réseau non maitrisé (le Wifi) vers les serveurs de l'entreprise. En tout cas c'est insuffisant pour penser être en sécurité.



  • @chris:
    oui mais ça reviendrait au même. Les utilisateurs auront accès aux serveurs de même que les pirates.

    @ccnet:
    je pense que si,une connexion vpn par rapport à une connexion wi-fi sera toujours plus sécuriser.

    De mettre une connexion wi-fi dans le Lan laisse une porte aux pirates de s'y introduire.



  • @ccnet:

    Présenté comme cela, je ne vois pas beaucoup de différence. Ce n'est pas l'acheminement sécurisé qui règle le problème de la connexion d'une machine sur un réseau non maitrisé (le Wifi) vers les serveurs de l'entreprise. En tout cas c'est insuffisant pour penser être en sécurité.

    un peu quand même malgré tout, ou alors il faut laisser tomber le VPN  ;)
    C'est sûr que le VPN ne règle pas tout mais si tu admets qu'un remote access en VPN est raisonnablement sécurisé si tu imposes à la fois certificat et authentification et que par ailleurs tu estimes (à tord ou à raison) que le wifi sur le LAN c'est dangereux, alors considérer tous les utilisateurs wifi comme des utilisateurs externes qui n'accèdent qu'en VPN n'est pas moins sécurisé qu'un accès VPN pour un utilisateur venant d'internet non ?
    Ou alors j'ai raté quelque chose dans ton propos  ???



  • @tosmoth

    Il y a d'autres solutions que le VPN.
    L'idée sous-jacente à ton design est que accéder au wifi n'est pas sécurisé, sous entendu tout le monde peut s'y connecter, donc y compris les méchants  8)
    C'est certainement vrai si ton WAP est en WEP mais il y a maintenant des techniques plus évoluées. Regarde par exemple 802.1X  ;)

    Comment penses-tu que font les entreprises qui offrent du Wifi aux utilisateurs ?

    L'avantage de la DMZ par rapport à ton design actuel, c'est que tu sais mettre en place des règles différenciées par rapport à ton interface WAN. mais bon, j'dis ça, j'dis rien ;-)



  • J'ai pas tout compris…

    Je vais mieux m'expliquer.

    Avant mon arrivé dans l'entreprise le réseau était comme ceci:

    Modem/Routeur (wi-fi)
              |
              |
            Lan(utilisateur,imprimante,serveur)

    J'ai installer un pare-feu pour protéger le réseau donc :
    Modem/Routeur (wi-fi)
              |
              |
          Pare-feu
              |
              |
            Lan

    Sauf que certains utilisateurs sont obliger de se connecter en wi-fi car ils n'ont pas de port Ethernet donc ils n'avaient pas accès à l’imprimante et aux serveurs.
    A ce moment la mon tuteur car je suis en BTS en alternance m'a demander de régler le problème en créant une connexion Vpn pour les utilisateurs wi-fi pour qu'ils aient accès aux Lan.
    J'ai penser au début à mettre un point d’accès wi-fi dans le Lan mais mon tuteur m'a dit que cela ne servait à rien car les pirates n'avait qu'à cracker notre wi-fi pour avoir accès à nos serveurs et qu'une connexion vpn était plus sécuriser qu'une connexion wi-fi.De plus ca nous permettrait à moi de me connecter aux serveurs depuis chez moi



  • @chris4916:

    @ccnet:

    Présenté comme cela, je ne vois pas beaucoup de différence. Ce n'est pas l'acheminement sécurisé qui règle le problème de la connexion d'une machine sur un réseau non maitrisé (le Wifi) vers les serveurs de l'entreprise. En tout cas c'est insuffisant pour penser être en sécurité.

    un peu quand même malgré tout, ou alors il faut laisser tomber le VPN  ;)
    C'est sûr que le VPN ne règle pas tout mais si tu admets qu'un remote access en VPN est raisonnablement sécurisé si tu imposes à la fois certificat et authentification et que par ailleurs tu estimes (à tord ou à raison) que le wifi sur le LAN c'est dangereux, alors considérer tous les utilisateurs wifi comme des utilisateurs externes qui n'accèdent qu'en VPN n'est pas moins sécurisé qu'un accès VPN pour un utilisateur venant d'internet non ?
    Ou alors j'ai raté quelque chose dans ton propos  ???

    Qu'on me lise bien :
    Présenté comme cela, je ne vois pas beaucoup de différence. Ce n'est pas l'acheminement sécurisé qui règle le problème de la connexion d'une machine sur un réseau non maitrisé (le Wifi) vers les serveurs de l'entreprise. En tout cas c'est insuffisant pour penser être en sécurité.

    Donc un vpn est nécessaire mais très loin d'être suffisant si la conception de l'ensemble n'est pas cohérente. Pour le moment ce que l'on nous présente n'est ni complet ni cohérent. Parmi les manquent et les incohérences :
    Quel réseau Wifi ?
    Quel contrôle d'accès au support ?
    Quid du contrôle du routage des machines connectées, des fonctionnalités disponibles lorsque le vpn est actif ?
    La gestion des certificats, la politique de mot de passe, les listes de révocation ?
    L'absence de cloisonnement du réseau (serveurs dans le lan) est une erreur majeure.
    Liste non exhaustive …



  • C'est très clair.
    Il y a donc deux sujets différents, dont un n'est peut-être même pas d'actualité:

    • VPN depuis l'extérieur (y compris le WAP)
    • sécuriser un point d'accès wifi connecté au LAN de l’entreprise.

    Si je commence par le sujet n° 2:

    • 802.1X (EAP) permet de sécuriser très raisonnablement l'accès au LAN via le wifi, au besoin en s’appuyant sur un serveur Radius.
      En procédant de la sorte, un méchant pirate aura beaucoup plus de difficultés à cracker l'accès et à pénétrer sur le LAN. Dison que si il y arrive, il arrivera également à cracker ton serveur VPN

    Et donc le point 1:

    • accès à un serveur VPN : ça va être techniquement assez équivalent à du 802.1X puisque tu retrouves un serveur Radius et un échange de clé.
      La différence, c'est que comme ton WAP est à l'extérieur, tu vas devoir ouvrir ton réseau, que l'utilisateur va se connecter en wifi puis démarrer un client VPN pour se connecter au LAN.

    Si le but est didacticiel (exercice sur le VPN) pas de soucis, il ne sert à rien de discuter mais si c'est un objectif fonctionnel, ça vaut sans doute le coup d'échanger avec ton tuteur sur le sujet.
    Enfin… dans ce que j'en comprends  :)



  • Si le but est didacticiel (exercice sur le VPN) pas de soucis, il ne sert à rien de discuter mais si c'est un objectif fonctionnel, ça vaut sans doute le coup d'échanger avec ton tuteur sur le sujet.

    Oui.



  • D'accord je me renseigne et je vous tiens au courant.

    Merci à vous deux



  • (Comme d'hab, les remarques de ccnet sont justes !)

    Mettre en place du WIFI en entreprise :

    • signal wifi : SSID au nom clair et non ambigu, diffusé; cryptage : WPA - Personnel minimum, AES plutôt que TKIP; 802.X : c'est vous qui voyez = demande expertise
    • interface dédiée WIFI : bonne idée; n'est pas la DMZ !
    • faut-il signal visiteurs ? Si oui, interface dédiée + règles de filtrage = pas d'accès au LAN ! (forcément)

    Actuellement, un signal WIFI crypté en WPA-AES n'est pas réputé cassable, mais une clé longue et complexe ne mange pas de pain, et une interface dédiée non plus.
    Néanmoins l'interface supplémentaire impose de créer les règles justes.

    Perso, en entreprise, je place des routeurs avec signal WPA+AES dans le lan, et c'est moi qui configure les PC (en admin puisque les utilisateurs ne sont pas admin !).
    J'ai par ailleurs des routeurs pour accès visiteurs (obligé) : VLAN + interface dédiée; signal explicite ('GUEST') + mdp affiché en salle de réunion.
    C'est discutable mais c'est un compromis acceptable.



  • Merci à tous de vos réponses et de votre aide.J'ai réussi à créer une connexion vpn,je vais maintenant en discuter avec mon tuteur pour améliorer la sécurité de l'entreprise.
    Mon erreur au niveau des vpn a était un manque de lecture poussée de la doc de pfsense vpn mais aussi des différents paramètres sur le serveur vpn.

    Merci à tous et à la prochaine


Log in to reply