VPN IPSEC et OPENVPN
-
En jouant un peu aux devinettes car je ne suis pas certain de comprendre ta question :
- tu as un lien IPSec entre ton LAN et le LAN d'un client qui héberge des automates via de ton coté pfSense.
- tu veux te connecter via OpenVPN à ton LAN et de là atteindre le site du client (via le tunnel IPSec donc)
C'est bien ça ?
avec ton tunnel OpenVPN, tu arrives avec une IP qui est celle configurée dans les settings du serveur OpenVPN.
Pour accéder au réseau distant (client), il faut déjà que tu pousses (au niveau du serveur OpenVPN) la route vers ce réseau afin que ton client OpenVPN sache que pour atteindre ces adresses, il faut passer par le serveur pfSense qui établit le tunnel IPSec. -
Franchement, pensez vous vraiment fournir assez d'informations ?
Est ce la peine de créer un nouveau fil et fournir si peu d'informations ?Même Chris4916 ne répond qu'en 30' : sans doute a-t-il été surpris de voir aussi peu !
Je donne les infos minimales :
- site distant : adressage local, passerelle par défaut des machines internes, paramétrage du serveur OpenVPN, quel rôle pour IPsec
- poste client : paramétrage OpenVPN, route print (après connexion)
-
Un nouveau post ne change rien. Nous vous avons déjà demandé un schéma complet. Que vous ne donnez pas.
Par ailleurs notre interlocuteur écrit dans un fil précédent :Je comprend pas pourquoi il est nécessaire que mon client ajoute une route si les flux sont dans un seul sens (c'est moi qui doit pouvoir me connecter sur mes machines à distance …).
Ce qui rend la bonne compréhension par mryou impossible. Si on ignore qu'une connexion TCP bien que établie dans un seul sens (encore faut il comprendre ce que cela signifie dans TCP) necessite des paquets dans les deux sens, on ne peut comprendre pourquoi le routeur à besoin d'une route retour.
Ce problème a une solution qui demande, pour commencer, d'être bien posé. Ensuite on peut expliquer quelles routes doivent être ajoutées et où.
Attendons qu'il soit bien posé. -
Je récapitule,
De mon côté j'ai :
VM pfSense : @IP 10.4.0.0/16
VM lambda : @IP 10.4.0.0/16Du côté de mon client :
Routeur avec lequel je suis connecté via un tunnel VPN IPSEC
Plusieurs automates appartenant à plusieurs sous réseauxAujourd’hui j'arrive à accéder aux automates (http et ssh) via ma VM client qui est derrière mon routeur pfSense.
J'ai créé un accès OpenVPN (@IP : 192.168.2.X), j'arrive à me connecté sur ma page de configuration pfSense mais je n'arrive pas à accéder aux automates qui sont chez mon client (http ou ssh).
Je précise que je peux faire les tests uniquement avec les ports http et ssh (le reste est bloqué via le tunnel vpn par mon client).
-
Du côté de mon client :
Routeur avec lequel je suis connecté via un tunnel VPN IPSEC
Plusieurs automates appartenant à plusieurs sous réseauxCette partie, très importante doit être décrite. La façon dont sont connectés les sous réseaux est critique pour déterminer une solution. Un schéma complet avec tous les équipements !!! Pas des copies d'écran. Sinon je l'aurai écrit.
-
En gros j'ai deux tunnels vers deux sous-réseaux (17.0.0.0/8 et 18.0.0.0/8 : ce sont les 2 réseaux de mon client).
Mes automates ont donc des IP dans les plages 17.0.0.0/8 et 18.0.0.0/8 .Je reprécise que lorsque je créé une VM avec comme passerelle l'IP LAN de mon routeur, tout fonctionne très bien (j'arrive à me connecté en http et ssh a mes automates).
-
J'en ai assez d'aller à la pèche. TERMINÉ.
-
J'ai ajouté un schéma avec les ip.
La problématique est que via un accès OpenVPN (j'obtient une IP en 192.168.2.0/16) je n'arrive pas à communiquer avec mes automates via HTTP et SSH (17.0.0.0 et 18.0.0.0).
Entre mon pfSense et le routeur de mon client, un tunnel VPN est créé (mon réseau 10.0.0.0/8 vers le réseau de mon client 17.0.0.0/8 et 18.0.0.0/8).
Le tunnel IPSEC est fonctionnel, j'ai créé une VM en mettant en passerelle l'@ LAN de mon pfSense (10.4.0.254).
-
Personne ne comprend qu'il y ait un tunnel Ipsec et un tunnel Openvpn.
Ca ne fait pas tilt chez vous ?
ccnet a raccroché, et pourtant il a une très forte expérience.
Moi je ne comprends toujours pas VOTRE schéma.
Si vous n'êtes pas capable de le faire comprendre, vous n'aurez aucune aide … -
L'accès OpenVPN est fait de manière à ce que je puisse me connecté à mes automates depuis n'importe où (je précise que pfSense est sur un cloud …).
-
Une fois ton tunnel OpenVPN établi, affiche sur ton client les routes (un truc genre "route print" sur une machine Windows) ce qui te dira quelles routes ton client connaît et par où il passerait pour joindre 18.0.0.0
-
L'accès OpenVPN est fait de manière à ce que je puisse me connecté à mes automates depuis n'importe où (je précise que pfSense est sur un cloud …).
Ce point est assez clair mais ta manière de le représenter (schéma) est un peu surprenante.
Il y a plusieurs points qu'il faut vérifier:
- ton client (OpenVPN) connaît-il la route vers le réseau qui héberge les automates ?
- le firewall (pfSense) autorise t-il d'atteindre cette destination à partir d'une source qui est ton adresse "OpenVPN" ?
- le firewall coté cible (ce que tu décris comme "routeur client" sur ton schéma autorise t-il des accès depuis une adresse IP qui est celle du client OpenVPN ?
-
L'accès OpenVPN est fait de manière à ce que je puisse me connecté à mes automates depuis n'importe où (je précise que pfSense est sur un cloud …).
Ce point est assez clair mais ta manière de le représenter (schéma) est un peu surprenante.
Il y a plusieurs points qu'il faut vérifier:
- ton client (OpenVPN) connaît-il la route vers le réseau qui héberge les automates ? Commande push c'est ca ?
- le firewall (pfSense) autorise t-il d'atteindre cette destination à partir d'une source qui est ton adresse "OpenVPN" ? Voir la pj, c'est bien ca ?
- le firewall coté cible (ce que tu décris comme "routeur client" sur ton schéma autorise t-il des accès depuis une adresse IP qui est celle du client OpenVPN ? Non le routeur client autorise uniquement le réseau 10.0.0.0/8
-
J'avoue ne pas comprendre ce que tu montres. Il n'y a ni commentaire ni titre à ce morceau d'affichage :(
De plus, je pense que tu n'as pas compris mon propos : il s'agit, depuis la machine qui établi le tunnel OpenVPN (le client OpenVPN et non pas pfSense qui est le serveur OpenVPN) de vérifier la route.
En premier lieu, il FAUT que ce client OpenVPN, une fois le tunnel OpneVPN établi, sache que pour joindre le réseau 18.0.0.0, il faut passer par le tunnel OpenVPN.
Autrement dit, il faut faire un "push route" coté serveur OpenVPN ou obliger tout le flux depuis ce client à passer par le tunnel OpneVPN. -
Désole erreur de manip.
En premier lieu, il FAUT que ce client OpenVPN, une fois le tunnel OpneVPN établi, sache que pour joindre le réseau 18.0.0.0, il faut passer par le tunnel OpenVPN.
Autrement dit, il faut faire un "push route" coté serveur OpenVPN ou obliger tout le flux depuis ce client à passer par le tunnel OpneVPN.Non pas de route, il faut plutôt dire qu'il faut passer par ma passerelle LAN (10.4.0.254) pour joindre les réseaux 17.0.0.0 et 18.0.0.0 ?
-
extrait de la documentation OpenVPN:
Push routes to the client to allow it
to reach other private subnets behind
the server. Remember that these
private subnets will also need
to know to route the OpenVPN client
address pool (10.8.0.0/255.255.255.0)
back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"Dans ton cas, il faut faire :
push "route 18.0.0.0 255.255.255.0"
push "route 17.0.0.0 255.255.255.0"si on suppose que coté automates, les subnets sont des classes C.
Dans pfSense, ceci se fait dans la section advanced configuration" du serveur OpenVPN 8)
-
Bon visiblement, vous ne comprenez pas ce qu'on vous demande : vous n'êtes pas capable de décrire votre schéma !
J'en déduit que vous ne souhaitez pas vraiment être aidé …
Je m'arrête donc aussi.NB : quand on écrit 18.0.0.0/8, le /8 signifie 255.0.0.0 et non 255.255.255.0 !
-
Merci beaucoup pour l'aide chris4916.
J'ai entré la commande mais ca ne fonctionne pas.
-
J'ai entré la commande mais ca ne fonctionne pas.
Ce n'est pas parce que tu as ajouté cette route que ça doit fonctionner maintenant. C'est une étape indispensable mais:
1 - une fois cette configuration effectuée, tu devrais vérifier que c'est bien opérationnel coté "client OpenVPN" (e.g. "route print")
2 - comme je te l'ai déjà écrit, il faut que le client OpenVPN connaisse la route vers le réseau cible mais il faut également s'assurer que coté firewall (de par et d'autre du tunnel IPSec) les flux sont autorisés, y compris pour l'adresse IP allouée à ton client OpenVPN.
-
Je trouve que c'est complètement fou ça…
Quelque soit le fil de discussion, on retrouve systématique la même problèmatique : réfléchir en terme de solution AVANT de réfléchir en terme de besoin.
Lorsque l'on réfléchit en terme de solution :
- on donne peu d'informations
- on cherche une solution pourvu qu'elle marche
- on comprend rarement ce que l'on fait
- la plupart du temps on n'apprend rien (ou mal)
Lorsque l'on réfléchit en terme de besoin
- on se construit un cahier des charges (terme qui devrait être souvent utilisé alors qu'il n'est jamais présent)
- grâce au cahier des charges on fournit des informations
- grâce aux informations on aboutit à une solution adaptée aux besoins (sans compter qu'on obtient de l'aide beaucoup plus facilement)
- on comprend mieux ce que l'on fait
- quand on comprend on apprend, donc on progresse
Savoir bidouiller est une chose, savoir pourquoi en est une toute autre.