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

tosmoth

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.

Lolight

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

tosmoth

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

chris4916

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.

ccnet

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.

tosmoth

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.

Lolight

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

tosmoth

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

chris4916

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)

jdh

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

tosmoth

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

chris4916

@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

ccnet

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

tosmoth

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

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

chris4916

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

tosmoth

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

ccnet

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

chris4916

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

ccnet

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.