Problème / Question Routing / VPN



  • Hello,
    Je me présente rapidement, je suis stagiaire dans une entreprise, celle-ci m'a confié la configuration d'un réseau.
    Le contexte est donc pro, et est amené à évoluer, je suis pour l'instant au début de la configuration, le sujet de se topic est donc amener a évoluer.

    Pour l'instant pour schématiser un peut j'ai un Pfsence avec deux VMs dans le LAN et un poste dans le WAN.
    Le but est que mon poste dans le Wan puisse pinger (établir une connexion en somme) mes postes dans le LAN.

    Le schéma est donc très simple pour le moment, a terme je devrais avoir un VPN sur l'interface WAN qui permettrais de relier différents client de l'entreprise.

    Mon premier problème (Shame on me) est tout simplement le fait d'établir une connexion entre mes VM dans le LAN et mon poste dans le WAN.

    Ping VM (côté Lan) vers patte LAN -> Ok
    Ping VM (côté Lan) vers patte Wan -> OFF  >:(
    Ping VM (côté Lan) vers Poste (côté Wan) -> OFF  >:(

    Ping Poste (côté Wan) vers patte Wan -> Ok
    Ping Poste (côté Wan) vers patte Lan -> Ok
    Ping Poste (côté Wan) vers VM (côté Lan) -> OFF  >:(

    Info Complémentaire :
    LAN 192.168.10.0/24
    WAN 192.168.0.0/24
    Rules : Aucune restriction.

    Voilà je reste disponible pour rajouter quelques info au besoins mais je pense que ça suffis.
    Certain d'être passé à côté de quelque chose de fondamental je requiert votre aide.

    Merci pour votre lecture.



  • Pfsense est une machine physique ? Quel est l'OS côté wan et ne bloque t il pas icmp ?
    La configuration réseau complète de la machine sur Wan ?

    a terme je devrais avoir un VPN sur l'interface WAN qui permettrais de relier différents client de l'entreprise.

    Si vous pensez que le schéma actuel peut être une validation de cette configuration future vous vous trompez complètement. La mise en place d'un vpn a de nombreuses implications réseaux d'une part et du point de vue de Pfsense d'autre part.



  • Hello merci pour ta réponse.
    Comme je le pensais il manque beaucoup d'info.
    Pfsense est une VM, pour être plus précis sur un ESXI, au niveau du LAN j'ai une VM Windows ainsi qu'une VM Linux, leurs GW est la patte Lan de PFsense

    Pour la machine sur le Wan est un Ubuntu 192.168.0.101 netmask /24 Gw 192.168.0.102 (Patte Wan de PFsense)
    Je pense pas que la machine bloque Icmp car le ping fonctionne sur la patte Wan de PFsense.

    Oui je me doute le la configuration de la partie Wan va complètement changer quand je mettrais le serveur VPN en place.
    L'objectif étais simplement de tester si ça fonctionnais bien et découvrir un peut comment se configurait PFsense.
    Une solution VPN a recommander ? OpenVPN / IPsec ? OpenVPN m'a l'air plus documenté et assez sécurisé.

    Edit simplement pour ajouter, je pense me tourner vers IPsec si il permet le multi site.
    Le VPN type CLient Serveur conviendrais mieux ça sera donc OpenVpn
    Quel clients VPN libre et gratuit préconisez vous pour aller avec PFsense ? J'ai vu que Shrew étais portable sur Linux et Windows.



  • Pfsense est une VM, pour être plus précis sur un ESXI, au niveau du LAN j'ai une VM Windows ainsi qu'une VM Linux, leurs GW est la patte Lan de PFsense

    C'est correct pour ce qui concerne les passerelles par défaut.
    Après tout dépend de ce que vous avez fait pour la partie réseau qui est ici entièrement contingentée à la configuration réseau de votre ESX. Configuration que nous ne connaissons pas.
    Enfin quelle est la gateway de l'interface Wan de Pfsense ?

    L'objectif étais simplement de tester si ça fonctionnais bien et découvrir un peut comment se configurait PFsense.

    Cette configuration ne le permet pas.

    J'ai vu que Shrew étais portable sur Linux et Windows.

    C'est un client IpSec et non OPenVPN. Les clients OpenVPN sont disponible ici : http://openvpn.net/index.php/open-source/downloads.html

    OpenVPN m'a l'air plus documenté et assez sécurisé.

    OpenVPN est tout à fait satisfaisant. Le niveau de sécurité effectif va dépendre de beaucoup de paramètres. Notamment la façon dont vous allez gérer les certificats, l'authentification, la configuration du VPN, l'architecture réseau et beaucoup des comportements utilisateurs.



  • Hello me revoila.

    J'ai changé l'archi elle se présente sous cette forme :

    –-routeur internet DHCP ----------WAN - pfsense - LAN ------l-----CentOS
                                                                                            l-----Windows7

    Le côté Wan va héberger un serveur VPN avec OpenVPN, du NAT afin de relier plusieurs réseaux différents et de ne pas avoir de confit d'adresse.

    Mon premier but est d’accéder a internet depuis ma CentOS/Windows afin de valider la configuration actuel.
    Dans un second temps je met en place un DynDNS, dans la foulée le serveur VPN puis le Nat.

    Voilà pour le précisions sur le projet que je vais mettre en place.

    Pour l'instant je souhaite récupérer l'ip public de mon routeur internet afin de configurer correctement le dyndns.
    J'ai donc besoins d'avoir une connexion internet depuis ma centOS ou Windows afin de faire ceci.

    Mon réseau LAN ne ping pas internet, et je ne sais pas pourquoi.
    Le ping vers la patte LAN & WAN du pfsense fonctionne correctement.

    Je pense que c'est peut être un soucis au niveau des rêgle de routage.
    J'ai ajouté une rêgle de ce type :
    0.0.0.0/32 sur l'interface Lan pour que les connexion internet soit redirigé vers pfsense.

    Quand je fais un ping de pfsense vers internet ça fonctionne.

    N'hésitez pas a demander des précision, merci pour votre lecture.



  • @Lolight:

    J'ai toujours mon problème, mon réseau Lan (CentOS/W7) ping très bien la patte LAN de mon pfsense mais pas la patte Wan.
    Je pense que c'est peut être un soucis au niveau des rêgle de routage.

    ne pas avoir de réponse au ping n'est pas nécessairement symptomatique d'un problème. par exemple si le FW ignore ICMP…

    J'ai ajouté une rêgle de ce type :
    0.0.0.0/32 sur l'interface Lan pour que les connexion internet soit redirigé vers pfsense.

    :-[ :-[  je ne comprends pas, ni l'objectif, ni la "règle" que tu as ajouté  ni ce qu'elle est sensée faire  :-\

    Dans ma compréhension, avec le design que tu décris, il n'y a strictement rien à ajouter à la configuration de base pour que ça fonctionne, à condition que les routes soient bien configurées.



  • Je pense que c'est peut être un soucis au niveau des rêgle de routage.
    J'ai ajouté une rêgle de ce type :
    0.0.0.0/32 sur l'interface Lan pour que les connexion internet soit redirigé vers pfsense.

    Lire les docs est vraiment nécessaire ! Où avez vous trouvé cette invention de règle de routage sur l'interface Lan ?
    Dans votre cas il n'y a pas 50 façons de paramétrer l'interface lan. Il ne devrait d'ailleurs ne pas être nécessaire de paramétrer quoi que ce soit si les bonnes réponses sont fournies lors de l'installation. Donc :
    IPv4 address : 192.168.0.102 /24
    Gateway : none
    Il n'y a besoin de rien d'autre. Si vous lisiez les documentations de base rien de cela ne devrait se produire.

    Le côté Wan va héberger un serveur VPN avec OpenVPN, du NAT afin de relier plusieurs réseaux différents et de ne pas avoir de confit d'adresse.

    Tout cela m'a l'air copieusement brouillon.



  • @chris4916:

    @Lolight:

    J'ai toujours mon problème, mon réseau Lan (CentOS/W7) ping très bien la patte LAN de mon pfsense mais pas la patte Wan.
    Je pense que c'est peut être un soucis au niveau des rêgle de routage.

    ne pas avoir de réponse au ping n'est pas nécessairement symptomatique d'un problème. par exemple si le FW ignore ICMP…

    Mon ping fonctionne bien sur la patte Lan et Wan, j'ai édit entre temps mais tu devais déjà être sur la page.
    J'ai aucune rêgle de filtrage donc normalement tout devrais passer.

    @chris4916:

    J'ai ajouté une rêgle de ce type :
    0.0.0.0/32 sur l'interface Lan pour que les connexion internet soit redirigé vers pfsense.

    :-[ :-[  je ne comprends pas, ni l'objectif, ni la "règle" que tu as ajouté  ni ce qu'elle est sensée faire  :-\

    Dans ma compréhension, avec le design que tu décris, il n'y a strictement rien à ajouter à la configuration de base pour que ça fonctionne, à condition que les routes soient bien configurées.
    [/quote]

    C'est pas une rêgle de filtrage mais plutôt la route par défault que j'ai voulus ajouter.
    Celle d'internet en somme, vu que me ping fonctionne je me suis dis que le problème vennait des routes.
    Etant donné que la route pour internet est 0.0.0.0 255.255.255.255 j'ai simplement voulus l'ajouter afin de tester.

    @ccnet:

    Je pense que c'est peut être un soucis au niveau des rêgle de routage.
    J'ai ajouté une rêgle de ce type :
    0.0.0.0/32 sur l'interface Lan pour que les connexion internet soit redirigé vers pfsense.

    Il ne devrait d'ailleurs ne pas être nécessaire de paramétrer quoi que ce soit si les bonnes réponses sont fournies lors de l'installation. Donc :
    IPv4 address : 192.168.0.102 /24
    Gateway : none

    Je suppose ici que tu parle de mon interface Wan, elle est maintenant en DHCP, celle-ci prends donc l'ip de la box internet lui fournis.
    Tu me préconise de mettre aucune passerelle sur le Wan ? Si je retire la passerelle (adresse de la box internet) je risque de perdre la connexion internet sur pfsense.

    Ce sont juste me VMs qui n'arrivent pas a joindre internet.

    @ccnet:

    Le côté Wan va héberger un serveur VPN avec OpenVPN, du NAT afin de relier plusieurs réseaux différents et de ne pas avoir de confit d'adresse.

    Tout cela m'a l'air copieusement brouillon.

    Sur le papier pas vraiment, sur le côté pratique complètement car se sont des choses que j'ai jamais fait.
    Mais c'est la mission que l'on m'a confié je dois donc la mener a bien.



  • C'est vraiment pénible ! Dans votre cas encore une fois il n'y a pas à toucher aux routes. Merci de poster une copie d'écran de la configuration de l'interface LAN. Je dis bien LAN.



  • @ccnet:

    C'est vraiment pénible ! Dans votre cas encore une fois il n'y a pas à toucher aux routes. Merci de poster une copie d'écran de la configuration de l'interface LAN. Je dis bien LAN.

    CCnet je te remercis de venir répondre ici et de perdre du temps pour mon cas c'est très gentils a toi et je te remercierais surement jamais assez, mais si vraiment ça t'embête ne le fais pas :)

    J'ai finalement retiré ma route complètement fausse.
    J'ai retiré la GW sur le LAN et tout marche.
    Mon erreur étais d'avoir mis la en GW l'interace LAN sur l'interface LAN. Oui oui lapidez moi.

    C'est pas facile pour moi d'être sur ce type de projet en total autonomie alors que je suis stagiaire de plus je dois le rendre assez vite et je ne veux pas décevoir.
    J'ai hérité d'un serveur a moitié configuré par un prestataire du coup ba je sais pas trop se qu'il ont fait/pas fait du coup je patauge un peut avec certain outils notamment pfsense.
    Merci encore pour le temps que vous m'avez accordé et vos réponses.

    Je peux enfin avancer dans le projet.



  • Bonjour,

    1/
    pFsense est capable de gérer un très grand nombre d'interfaces, quelle soit physique (carte eth) ou logique (Vlan); ces interfaces peuvent être défini comme des Wan ou comme des Lan :
    Interface AVEC une GW configurer = WAN
    Interface SANS GW de configurer = LAN

    2/
    @Lolight:

    Pour l'instant je souhaite récupérer l'ip public de mon routeur internet afin de configurer correctement le dyndns.
    J'ai donc besoins d'avoir une connexion internet depuis ma centOS ou Windows afin de faire ceci.

    Du blabla/charabia !

    Si votre FAI vous fournie une IP dynamique vous avez effectivement besoin d'un dyndns/no-ip pour configurer vos Vpn; si votre FAI vous fournie une IP fixe pas besoin.
    Si votre IP est dynamique il vous suffis d'aller dans : Menu SERVICE | Dynamic DNS et de configurer votre compte, pf se chargera des mises à jour lors du changement de l'IP Wan

    Cordialement



  • Pour OpenVpn vous pouvez installer la package : Client Export Utility

    Il vous simplifiera la vie quand à la configuration des clients en vous produisant un installeur ou des fichiers contenant la config et les certificats tout prêt pour les différentes plate-forme  ;)



  • Hello merci pour ces précision bien utiles  ;)

    Pour les IP public oui effectivement mais il faut bien donner l'ip au site dans un premier temps afin d'ajouter un host a mon compte dyndns, on le fais une fois puis le client pfsense se charge du reste par la suite.

    C'est d’ailleurs réglé et ça fonctionne parfaitement.

    J'ai installé le package comme tu me la préconisé, ça a l'air vraiment pas mal, je suis toujours en phase de test.
    Niveau du VPN je me suis orienté vers OpenVpn avec une connexion Site-To-Site avec cert PKI, celon la documentation c'est se qui correspondrais le mieux au besoins de mon entreprise.

    Je repasserais vous voir pour vous tenir au jus de mon avancée  :)



  • Hello,
    Un petit retour sur les tests et soucis rencontré que j'ai fais/eu pour l'instant, j'ai maquetté un serveur VPN en Remote Accès sur OpenVpn  avec Auth User + Certificat PKI.

    Ca mache bien, en tout cas dans un sens, je dois avoir un soucis, mes paquets sont filtré par un FW du réseau dans un sens  ::)
    L'export grace au package "OpenVPN Client Export Utility" c'est fais très facilement merci Baalserv  :P

    Je test actuellement une connection VPN en IPsec mais j'ai quelques soucis.
    Je me suis servis de cette documentation pour le faire :
    https://doc.pfsense.org/index.php/VPN_Capability_IPsec
    https://doc.pfsense.org/index.php/NAT_with_IPsec_Phase_2_Networks
    Et de celle ci pour essayer de corriger mes erreurs : https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Phase_1_Identifier_Mismatch

    Je cacherais volontairement les ips mais voici se que me renvois les logs :

    Mar 25 13:41:40 charon: 12[NET] received packet: from IPDESTINANTION[500] to 192.168.1.14[500] (404 bytes) 
    Mar 25 13:41:40 charon: 12[ENC] parsed AGGRESSIVE response 0 [ SA KE No ID V V V NAT-D NAT-D V V HASH ] 
    Mar 25 13:41:40 charon: 12[ENC] received unknown vendor ID: 40:4b:f4:39:52:2c:a3:f6 
    Mar 25 13:41:40 charon: 12[ENC] received unknown vendor ID: 5b:36:2b:c8:20:f6:00:07 
    Mar 25 13:41:40 charon: 12[IKE] <con1000|5229>received NAT-T (RFC 3947) vendor ID 
    Mar 25 13:41:40 charon: 12[IKE] received NAT-T (RFC 3947) vendor ID 
    Mar 25 13:41:40 charon: 12[IKE] <con1000|5229>received DPD vendor ID 
    Mar 25 13:41:40 charon: 12[IKE] received DPD vendor ID 
    Mar 25 13:41:40 charon: 12[IKE] <con1000|5229>received XAuth vendor ID 
    Mar 25 13:41:40 charon: 12[IKE] received XAuth vendor ID 
    Mar 25 13:41:40 charon: 12[IKE] <con1000|5229>IDir 'C0EAE4699FB6' does not match to '62.244.85.53' 
    Mar 25 13:41:40 charon: 12[IKE] IDir 'C0EAE4699FB6' does not match to 'IPDESTINATION' 
    Mar 25 13:41:40 charon: 12[ENC] generating INFORMATIONAL_V1 request 4183444803 [ N(INVAL_ID) ] 
    Mar 25 13:41:40 charon: 12[NET] sending packet: from 192.168.1.14[500] to IPDESTINATION[500] (56 bytes)</con1000|5229></con1000|5229></con1000|5229></con1000|5229> 
    

    Je pense que le soucis se situe a cette ligne :
    Mar 25 13:41:40 charon: 12[IKE] IDir 'C0EAE4699FB6' does not match to 'IPDESTINATION'

    Mais je n'arrive pas a déterminer le paramètre que cible cette ligne dans la configuration d'IPsec ainsi que la phase 1 ou 2.

    Voici un extrais de ma configuration de mon tunnel Phase 1 (je vous met cette partie car j'immagine que le soucis viens d'ici vu le message des logs mais je me trompe surement)
    My identifier : DynDNS : mondyndns.net
    Peer identifier : Ip Address : IPDESTINANTION

    NOTA : IPDESTINATION correspond à l'ip public de mon partenaire avec lequel je veux établir le tunel VPN.
                192.168.1.14 correspond à la patte Wan de mon pfSense.

    Merci pour votre lecture  :)



  • Si tu veux vraiment cacher les adresses IP….. il reste une petite référence à Bluegix dans ton extrait de log  ;)
    et je ne comprends pas à quoi correspond 'C0EAE4699FB6' qui ressemble à une MAC address Sonicwall



  • Hello chros4916 merci pour ta réponse.

    Je ne sais pas, c'est pas de mon côté, j'aurais plus de détails dans l'aprem mais il me semble qu'effectivement un FW de type Sonicwall étais présent bien vu.

    –--

    J'ai encore et toujours une, en fait plusieurs questions, aujourd'hui elle seront à propos du NAT et d'OpenVPN.

    Alors je m'explique, le but et d'avoir différents client VPN relié à mon serveur VPN et de les répartir sur des plage d'adresse bien définis et statique, afin de pouvoir monitorer leurs équipement et en séparant chaque Client. Voilà pour le contexte.

    Pour ce faire je me suis dis, c'est facile, je monte mon tunel, je NAT mon client avec un NAT de type 1:1 donc static sur un sous réseau et je fais pareil pour chaque client.
    Mais au moment de schématiser ça sur papier je me pose quelques questions.

    Toujours sur le plan théorique je me demande si je dois mettre en place mon NAT sur la machine où je lance mon client VPN ou bien sur pfSense ou bien sur les deux.

    Celons moi, il serais logique que le NAT se fasse soit sur le Client soit sur le pfSense mais pas forcément sur les deux car la translation d'adresse ne ferais qu'en 1 point.

    Ensuite, si sur mon réseau interne LAN j'ai un type d'adressage avec un masque /16 et que mes client NATé sont chacun avec des masques /29 pour 6 hosts par exemple.
    Mon réseau ayant un /16 devrais accéder a tout mes sous réseau vu que son masque est plus petit ?

    Voilà mes différentes interrogations merci pour votre lecture et le temps que vous m'accordez.



  • La description de ce dernier point ne me parait pas très claire.
    J'intuite (plus que je comprends) qu'il s'agirait plutôt de relier des sites entre eux au travers d'un tunnel VPN dans une architecture 'hub & spoke" (en étoile) afin de pouvoir, depuis le site central, surveiller des équipements qui se trouvent sur les sites distants. Dans ce cas, même si la notion de client/serveur (VPN) existe toujours si on prend en compte l'initiative d'établissement de la connexion, ces deux rôles s’estompent rapidement et une même implémentaiton de VPN sur un site donné peut être à la fois serveur et client, voire même simultanément dans certains cas.

    Dans ce type de configuration, la visibilité qu'a un site distant des autres sites connectés en VPN dépend des règles sur le FW (je suppose car je n'ai jamais déployé la version de pfSense  :-[) et des routes qui sont annoncées.

    Par ailleurs, j'ai l'impression, mais peut-être me trompe-je, que tu confonds les aspects réseaux liées à l'établissement du tunnel (un tunnel site-à-site va se satisfaire d'un masque /30)  avec les éventuels besoins de NAT liés à la non unicité des réseaux.
    Je m'explique:

    • dans une vision d'un monde idéal ou toutes les adresses IP utilisées seraient en dehors de la RFC1918 (ce qui présenterait par ailleurs d'autres inconvénients mais c'est un autre débat), il n'y aurait pas besoin de NAT. Chaque réseau étant unique du point de vue de son adressage IP, depuis ton site tu tapes directement l'adresse IP (ou le host si tu as fait le nécessaire en terme de DNS) à joindre et le serveur VPN redirige la requête vers la route qui va bien au travers du bon tunnel puisqu'il connaît la route. Et ceci fonctionne dès lors que les adresses à chaque coté sont uniques.
      -  dans la vraie vie, les réseaux de part et d'autre vont plutôt utiliser des adresses dans la RFC1918. Il est donc nécessaire de mettre en place des solutions de type NAT pour que, sur un réseau donné, lorsque tu veux joindre une machine distante, le nom de la machine soit résolu avec une adresse qui est unique tu point de vue [b]local afin que le VPN local t'oriente vers le bon tunnel.  Cette problématique de NAT est donc avant tout locale mais peut devir complexe dans le cas d'un réseau VPN maillé, surtout si tu ne maîtrises pas les sites distants (d'un point de vue configuration réseau).
      Dans ce cas, si il s'agit de te connecter depuis une machine de monitoring d'un site central vers plusieurs machines sur chacun des sites distants, il serait peut-être plus simple de déployer cette machine sur un bout de réseau isolé (une DMZ par exemple) pour assurer une gestion simple des règles de FW, et de mettre en place des règles de NAT pour cette interface (DMZ) uniquement.
      Si ton nombre de machine à surveiller est connu et que celles-ci disposent d'un adresse IP fixe, est-ce que du 1:1 ne résout pas le problème ?


  • Bonjour Chris4916,

    Tu intuite très bien c'est bien une architecture de type "Hub & Spoke" que je suis sensé mettre en place a la suite de ma maquette dans l'objectifs de monitorer divers équipements.
    Tu as aussi très bien cerné les problématique et ce pourquoi je veux mettre en place du Nat.

    Pour l'instant au niveau du FireWall, je ne filtre rien étant donné que je suis sur une maquette au niveau d'OpenVpn.
    Je règlerais le FireWall dès que je suis sur que le reste de la maquette fonctionne.

    Oui, effectivement tu vois juste je fais un peut l'amalgame entre VPN et NAT, c'est dailleur pour ça que j'avais du mal à définir l'endroit ou devais être mis en place le NAT du réseau distant.
    Merci pour ta réponse, et effectivement je ne maitrise pas l'adressage des sites distant ce qui complexifie la chose.
    Je risque de tomber sur plusieurs site avec exactement le même adressage, se qui probablement posera quelques soucis au niveau de l'orientation vers un des tunnel m'enfin j'en suis pas encore la mais il faut quand même que j'y pense.

    Oui je pense que le 1:1 résous mon problème, après le nombre de machine m'es inconnus.
    Je me suis fais un petit plan d'adressage pour tout mes sous réseaux et je suis partis sur une base de 126 Host par site ce qui devrais être largement suffisant.

    Je vais faire mes test sur ma maquette avec le NAT 1:1 de pfSense voir se que ça donne.
    Merci



  • Si tu ne maîtrisés pas les sites distants, c'est alors peut-être plus complexe que ce que tu as peut-être imaginé:
    la problématique d'unicité d'adresse IP existe de ton point de vue (site central) mais également du point de vue de chaque site distant qui aura un lien VPN vers ton site mais potentiellement vers d'autres sites que tu ne connais pas forcément.
    Du coup, il peut être nécessaire de faire de la translation de part et d'autre en fonction de ces cas particuliers.



  • Deux choses :

    L'ipsec entre Pfsense et Cisco fonctionne depuis un client Cisco vers serveur Pfsense, tout comme "serveur" Cisco vers serveur Pfsense. Client vers site ou site à site fonctionnent.
    De mémoire je ne suis pas certain qu'il en soit de même avec un Sonicwall. C'est bien le problème d'ipsec.

    Ensuite pour les problèmes de translation j'ai rencontré il y a peu une situation où des numéros de réseaux étaient identiques entre source et destination dans le cadre d'un lien site à site. La solution ne réside pas dans le nat 1:1 mais dans l'utilisation de l'option nat/binat disponible dans l'onglet phase 2 de la configuration Ipsec. Quelques informations complémentaires en bas de cette page :
    http://www.onlamp.com/pub/a/bsd/2003/03/06/ssn_openbsd.html?page=4



  • Hello, merci chris4916 et ccnet pour vos réponses.

    Mon tunnel IPsec est établis, et effectivement, il y avais bien un FW de type SonicWall a l'autre bout.

    J'ai eu plusieurs erreurs mais je pense que celle qui bloquais principalement étais un problème de configuration de l'autre côté au niveau des KeyID Tag ainsi que le mode agressive qui apparemment rencontre quelques soucis avec pfSense 2.2.

    Maintenant que tout cela est fait je m'attaque au NAT.
    Je vais commencer par étudier la solution pour OpenVPN puis IPsec dans un second temps.

    J'ai bien pris note ccnet de l'option NAT/BINAT que j'avais repéré lors de ma configuration.
    Je ne manquerais pas de te faire un retour dès que je m'y attèle.

    –--

    Je me suis fais un shéma qui est celui-ci (il représente la maquette):
    EDIT : Pour plus de claretée j'ai mis un shéma en PJ plus propre, et je pense que celui-ci étais faux au niveau de l'adressage du tunnel VPN

    10.0.8.6/24 tun0                          10.0.8.1/24 OpVpn          172.16.0.2/16
    Client                      RPI –--------------------------------------------pfSense                  CentOS
    192.168.0.10/21  192.168.0.80/21 eth0                                  172.16.0.1/16 LAN          l
      l                            l                                                                      l                            l
      l                            l                                                                      l                            l
    -------------------------                                                                      ------------------------

    J'espère que mon shéma de mon infra actuel est pas trop brouillon.
    Je vais essayer de détailler un peut, le tun0 représente l'insterface client de mon tunnel OpenVPN et de l'autre côté l'interface serveur d'OpenVpn.

    L'objectif est donc de mettre en place du NAT afin de translater le réseau 192.168.0.0/21 sur un sous réseau 172.16.1.0/25

    Côté RPI j'ai a ma disposition iptables qui est capable de gérer du NAT static et côté pfSense ces outils de NAT.
    Bien évidement je ne compte pas faire de NAT pour plus de 126 Host (/25) donc la différence des masque ne devrais pas poser soucis.

    Cela vous semble correct ?



  • nous sommes bien d'accord que la translation n'est nécessaire que si, coté pfSense, une autre route existe déjà pour un autre réseau 192.168.0.0/24 et/ou que, dans l'autre sens, coté machine à monitorer, une autre route existe pour un autre réseau 172.16.0.0/16, sans quoi ça devrait déjà fonctionner, si je comprends bien



  • Oui chris4916, j'ai besoins d'une translation seulement si mes deux réseau ont le même adressage.

    J'ai un petit soucis qui je pense est externe a la configuration de pfSense peut être saurez vous y répondre.

    Mon tunnel VPN est établis celons le shéma suivant, j'ai encore changé l'adressage, normalement celui ci devrais être le définitif.
    Chaque tunnel avec chaque client aura sont propre sous réseau.

    De mon centOS je peux effectuer un ping jusqu'à la patte VPN côté RPI (172.16.1.2)
    Je peux aussi prendre la main sur le RPI depuis le CentOS en SSH.
    Seulement quand je tente de faire un ping sur la patte en 192.168.0.80 cela ne fonctionne pas.
    J'ai ce type de message : Communication prohibited by filter
    Un peut comme si un FW bloquais mon traffic, j'ai donc effectué un iptables -L sur mon RPI afin de voir si une rêgle n'étais pas présente et .. non aucune.

    Si c'est censé fonctionner j'ai bien un soucis mais je ne sais pas trop ou chercher pour le coup.



    • as-tu lu ça ?
    • qui (quoi) te renvoie ce message "communication prohibited by filter" ?
    • à noter également que ICMP peut être bloqué mais d'autres protocoles peuvent être autorisés mais pour le savoir, il faut déterminer quel est l’élément qui filtre.


  • Merci chris4916 pour ta réponse.


    Pour ton liens, je suis dessus j'ai l'impression que son problème est sensiblement le même que le mien.
    La solution qu'il expose si j'ai bien compris et de rajouter une rêgle de filtrage sur sa pfSense box pour que celle ci ne filtre plus son accès SSH.

    Mon soucis est le même sauf que j'ai l'impression que mon filtrage s'effectue côtré RPI non pfSense.

    --
    Si tu as la possibilité de voir le shéma que j'avais mis sur mon précédent post je vais te décrire exactement ou ça passe et ou ça passe pas et se qui me fais déduire que c'est le RPI qui filtre.

    Sens Lan pfSense vers RPI

    Ping de CentOS vers le tunnel VPN –> Ok sur les deux interface (côté pfSense, côté RPI)
    Ping de CentOS vers l'interface LAN du RPI (adressage en 192) --> Non OK
    Retour du ping :

    
    PING 192.168.0.80 (192.168.0.80) 56(84) bytes of data.
    From 80.10.124.140 icmp_sec=3 Packet Filtered
    From 80.10.124.140 icmp_sec=6 Packet Filtered
    From 80.10.124.140 icmp_sec=7 Packet Filtered
    
    

    Ce qui me perturbe dans cette réponse c'est l'adresse 80.10.x.x qui à priori serait une adresse ip public qui ne correspond a aucune des deux côté.

    Sens Lan RPI vers pfSense

    Le RPI a deux patte réseau, son eth0 sur le 192.168 et Tun0 qui correspond au Tunnel VPN.
    Le ping de tun0 vers le tunnel VPN fonctionne.
    Le ping de tun0 vers la machine CentOS du LAN pfSense fonctionne aussi.

    Le ping de eth0 vers le tunnel VPN ne fonctionne pas.
    Commande utilisée :

    ping -I eth0 172.16.1.2
    

    Je pense donc que ça coince ici.
    Soit dans les routes soit dans les iptables.

    iptables :
    Les trois chaine INPUT, FORWARD et OUTPUT sont vide.
    Avec (Policy ACCEPT) qui je suppose veut dire que ça accepte tout par défault.

    Route

    
    Destination                Passerelle             Genmask               Iface
    default                      192.168.0.1          0.0.0.0                  eth0
    172.16.0.0                172.16.1.1            255.255.255.128   tun0
    172.16.1.0                *                          255.255.255.128   tun0
    192.168.0.0              *                          255.255.248.0       eth0
    
    

    Voilà j'espère pas être passé a côté de quelque chose de trop gros.

    PS :
    J'ai ajouté la configuration de mon NAT 1:1 fais côté pfSense.
    Mais je pense que le problème juste au dessus si il n'es pas réglé empêchera le NAT de fonctionner.

    Je me sert de ce site pour me documenter et essayer de trouver un solution actuellement :
    http://fr.wikibooks.org/wiki/Administration_réseau_sous_Linux/Routage

    EDIT :
    Après avoir bidouillé un peux et fait quelques test je viens vous faire un petit feedback.

    J'ai tripatouillé mon iptables pour être sur qu'il ne filtre rien, j'ai donc ajouté des rêgles de filtrage acceptant tout trafic en INPUT OUTPUT et FORARDING.

    Ensuite je me suis aperçus quand si je me place dans le shell de mon CentOS (Côté LAN pfSense) et que je fais un ping vers une adresse type 172.16.54.1 (adresse complètement fictive), il n'y a aucun équipement a cette adresse et j'ai toujours cette fameuse réponse "Packet filtered"

    Du coup je me dis que c'est peut pas du côté RPI que ça coince.
    Je continue de chercher, bonne journée  :)



  • Tu essaies bien ces "ping" une fois que le tunnel est établi ? (je pense si je m'en tiens aux routes que tu montres)



  • Salut Chris4916.

    Oui j'ai fais l'ensemble de ces ping avec le tunnel établis.

    Peut être que le problème viens du routage de mon ping.

    C'est à dire que j'ai l'impression que mon ping est dirigé vers la sortie Box Internet et non vers le tunnel VPN.

    traceroute du LAN pfSense la patte RPI du tunnel (tun0)
    Destination 172.16.1.2

    
    1  172.16.1.2 (172.16.1.2)  45.026 ms  42.225 ms  36.892 ms
    
    

    traceroute du LAN pfSense vers 192.168.0.80 patte eth0 du RPI

    
     1  192.168.1.1 (192.168.1.1)  1.200 ms  0.956 ms  0.761 ms
     2  * * *
     3  * * *
     4  * * *
     5  * * *
    ...
    
    

    On peut voir que le chemin utilisé n'es pas du tout le même.
    La mon paquet sort par la sortie WAN de mon pfsense et passe par la box.
    Idéalement il devrait sortir sur la sortie "Ovpn" pour atterrir dans le tunnel et avoir une chance d'arriver sur le réseau distant.

    Alors je me demande si il faut pas que j'ai une approche différente, j'ai vu certain tutoriel sur le net qui ajoutait une interface virtuelle qu'ils appelais OPT1 par exemple.
    Je me dis qu'avoir une interface me permettrais d'entrer mes routes manuellement et donc d'être sûr de rediriger mon paquet vers le tunnel.

    J'essaye de vous faire part de mon raisonnement pour plus de clarté sur les tenant et aboutissant de se que je fais.



  • J'avoue que je n'ai pas fait l'effort de regarder le détail des équipements et des routes que tu décris dans tes différents schémas.
    Pour comprendre ce qui s'y passe vraiment, il faut que ce soit exhaustif.

    Ce qu'il faut comprendre, mais je pense que as déjà assimilé ça, c'est que la route vers le site distant (ou son adresse translatée lorsqu'il y a translation) est au départ connue par le serveur VPN local et propagée (ou pas) par celui-ci.
    Lorsque le serveur VPN local est la route par défaut des éléments connectés à celui-ci, ces équipement n'ont pas besoin de connaître cette route car les requêtes arrivent sur la route par défaut (ici l'extrémité locale du tunnel) qui elle connaît la route vers le site distant au travers du tunnel.

    Ce qui me conforte dans le fait que j'ai bien fait de ne pas étudier le détail de ton réseau avant, c'est que, sauf si j'ai raté quelque chose, tu sembles introduire maintenant un équipement réseau (en 192.168.1.1) qui ne fait pas partie de ce que tu as décrit avant.

    Peut-être faut-il commencer par cette description exhaustive du réseau, hors tunnel(s) avant d'aller plus loin ?

    Je vais quand même tout relire depuis le début  ;)



  • Merci pour ta réponse Chris4916

    Effectivement, j'introduis la partie hors VPN et je pense que le problème viens de la.
    J'ai essayé de faire un schéma assez clair de l'infra sans trop détailler bien que ce soit une maquette j'utilise quand même des donnée et des équipement bien réel.

    J'ai aussi essayé de produire quelque chose de plutôt propre afin de faciliter la compréhension.
    Je n'ai pas tenus compte du NAT dans le shéma mais idéalement le réseau LAN RPI serais sur un subnet de type 172.168.X.0/25




  • En tous cas, c'est beaucoup (beaucoup) plus clair comme ça.
    Je vais relire tes précédents posts à la lumière de ce schéma.
    Ce qui apparaît déjà - visuellement - clair, c'est que pfSense est tr_ès probablement la route par défaut pour les équipement sur le site A alors que la route par défaut sur le site B est plutôt le modem/routeur derrière le switch. Il faut donc que celui-ci sache que la route vers 172.16.0.0/25 passe part le RPI, en tous cas pour les sessions issues du site B.



  • Hello,
    Content que ça te permette de mieux visualiser les choses.
    Le but avant de pouvoir atteindre mes host de test étant de pouvoir atteindre l'ip interne configuré sur la patte eth0 de mon RPI (192.168.0.80).
    J'ai pas la main sur les Hote de test pour le moment, mais leurs rôle sera simplement de répondre à des pings émis du CentOS(côté Lan pfSense).

    Si il arrive a joindre l'hôte, le retour ne devrais pas poser de problème, enfin j'espère, peut être que je ne vois que la partie émergé de l'iceberg  ;D



  • je pense, comme toi, que si tu arrives à joindre le serveur cible, il n'y a pas de problème de "retour".
    En revanche, je ne suis pas certain que le ping soit l'arme absolue pour les tests, sauf si tu as une vision précise de ce qui est fait en terme de ICMP (et de règles de FW en général)

    Dois-je déduire de ton schéma que l'adresse publique de l'équipement réseau situé sur le site B est 80.10.xx.xxx ?

    Et donc, dans ma compréhension, nous avons:

    • sur l'équipement en 80.10.xx.xxx (site B) , une redirection vers 192.168.0.80 (interface du RIP) pour le(s) ports utilisés par OpenVPN
    • ça permet d'établir un tunnel entre les sites A et B (le choix du netmask /25 pour le réseau du tunnel est surprenant  mais pourquoi pas…)
    • une fois le tunnel établi, pfSense connaît la route vers 192.168.0.0/24 (celle-ci passe par le tunnel donc la GW est 172.16.1.xxx)
    • les machines sur le réseau A ayant pfSense comme gateway par défaut, les requêtes vers 192.168.0.x vont passer par le tunnel sans qu'il soit besoin de définir de route statique, à la main, de part et d'autre.

    J'ai juste jusque là ?

    Si oui:

    • je ne comprends pas quel est le problème (au delà du fait que la réponse au ping n'est pas nécessairement activée partout
    • je ne comprends pas pourquoi nous aurions un filtrage de la part de 80.10.xx.xxx (même si physiquement ça passe par là, nous sommes "dans" le tunnel n'est-ce pas ?)

    Je continue ma lecture ;-)



  • A noter que si tu veux faire des tests de B ver A, il faut que sur la gateway par défaut des machines du réseau B il y ait une route "en dur" qui précise que la route vers 172.16.0.0/25 passe par 192.168.0.80

    Je suppose que cette gateway est l'interface interne de l'élément qui se situe à la frontière avec le WAN (l'équipement qui a 80.10.124.xxx en adresse publique ;-) )



  • @chris4916:

    Dois-je déduire de ton schéma que l'adresse publique de l'équipement réseau situé sur le site B est 80.10.xx.xxx ?

    Et non justement c'est ça qui me fais penser que ça part se perdre dans les méandre du web.
    Aucune de mes deux ip public ne correspond a cette adresse qui me retourne "Packet filtered"
    Il y a aussi le traceroute qui me met sur cette voie la.

    @chris4916:

    Et donc, dans ma compréhension, nous avons:

    • sur l'équipement en 80.10.xx.xxx (site B) , une redirection vers 192.168.0.80 (interface du RIP) pour le(s) ports utilisés par OpenVPN

    Exactement, sauf l'ip public qui ne correspond mais dans l'idée oui c'est ça.

    @chris4916:

    • ça permet d'établir un tunnel entre les sites A et B (le choix du netmask /25 pour le réseau du tunnel est surprenant  mais pourquoi pas…)

    Je compte le changé, j'ai eu un soucis de compréhension en lisant la doc et j'ai cru qu'il fallait que j'alloue un sous réseau pour le tunnel.
    M'enfin c'est comme ça pour la maquette, j'y touche plus mais quand je le mettrais en place ça changera surement

    @chris4916:

    • une fois le tunnel établi, pfSense connaît la route vers 192.168.0.0/24 (celle-ci passe par le tunnel donc la GW est 172.16.1.xxx)

    Tu pense ?
    Quand je fais un traceroute depuis le LAN pfSense vers 192.168.0.80 j'obtiens ceci :

     1  192.168.1.1  1.220 ms  0.952 ms  0.997 ms
     2  * 80.10.124.140  2.332 ms !X *
     3  * * 80.10.124.140  1.979 ms !X
     4  80.10.124.140  1.928 ms !X * *
     5  * 80.10.124.140  1.666 ms !X *
     6  * * *
     7  * * *
    
    

    Si il passais par le tunnel il devrais me retourner 172.16.0.2 qui est le bout du tunnel.. Non ? Ou au moins 172.16.0.1 (Patte LAN pfSense, puis 172.16.0.2 Patte Tun0 du RPI)

    @chris4916:

    • les machines sur le réseau A ayant pfSense comme gateway par défaut, les requêtes vers 192.168.0.x vont passer par le tunnel sans qu'il soit besoin de définir de route statique, à la main, de part et d'autre.

    J'ai juste jusque là ?

    Normalement oui mais du coup je suis pas sur avec le traceroute.

    @chris4916:

    Si oui:

    • je ne comprends pas quel est le problème (au delà du fait que la réponse au ping n'est pas nécessairement activée partout
    • je ne comprends pas pourquoi nous aurions un filtrage de la part de 80.10.xx.xxx (même si physiquement ça passe par là, nous sommes "dans" le tunnel n'est-ce pas ?)

    Je continue ma lecture ;-)

    Il n'y a pas de filtrage, il y a bien un FW mais j'ai ajouté une règle pour ne rien filtrer sur la destination 192.168.0.80 donc le RPI.
    Puis le tunnel est établis donc tout devrais passer dedans.

    Je fais des ping, cas l'objectif est de faire du monitoring avec notre ami Nagios, et il me semble que le check_host_alive passe par de l'icmp :)

    Je te donne beaucoup de lecture et peut être un mal de tête, encore et encore merci :)



  • Donc oui il y a bien un truc dans le potage  ;D  car depuis le client VPN, une fois le tunnel établi, la route vers le(s) réseau(x) connecté(s) au serveur devrait être connue et publiée.

    Je n'ai pas fait de test avec OpenVPN de pfSense (mais j'en ai déployé plein d'autres  ;)) et si l'advertising est configuré correctement,  alors cette route est publiée.
    Dans le cas contraire, pas étonnant que ça ne marche pas.

    Pour en revenir au subnet associé au tunnel lui même, dans le cas d'un tunnel qui sert à raccorder 2 réseaux, un netmask en /30 suffirait puisque ça contient 2 hosts, soit un par extrémité du tunnel  ;)
    Mais c'est du détail et ne gène en rien le fonctionnement

    Une fois que tu as établi le tunnel, vérifie quelles sont les routes de part et d'autre avant de faire plus de tests ;-)



  • Hello,
    Je viens vous donner des new, je suis toujours bloqué mais je n'ai plus ce prblème de de "Packet filtered"

    Alors niveau VPN j'ai monté un tunel Site to Site avec OpenVpn.
    Les configuration sont sensiblement les même.

    Mon tunnel est bien établis sur OpenVPN et le client RPI arrive à ping le LAN pfSense.
    Pour l'instant c'est comme avant.

    Je n'arrive pas à joindre dans l'autre sense mon LAN RPI.
    J'arrive quand même à ping le tunnel VPN.

    Je pense qu'ici c'est un simple problème de route.
    Je vais donc étudier le problème dans le sens LAN pfSense vers LAN RPI

    Pour commencer la route par défault de mon LAN pfSense est pfSense.
    Donc les paquet devrais être bien acheminé vers le pfSense.
    Ensuite niveau pfSense la route pour joindre mon réseau 192.168.0.X est bien le tunnel VPN
    Donc la aussi ça devrais être bon.

    Niveau route sur le RPI j'ai du mal a saisir si la configuration est bonne ou pas.

    
    Table de routage IP du noyau
    Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
    default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
    10.0.8.0        *               255.255.255.0   U     0      0        0 tun0
    172.16.0.0      10.0.8.1        255.255.255.128 UG    0      0        0 tun0
    192.168.0.0     *               255.255.248.0   U     0      0        0 eth0
    
    

    Faut-il que j'ajoute une route pour lui dire tout se qui arrive de tun0 a destination de 192.168.0.0/21 doit sortir sur eth0 ?



  • le serveur VPN est ici pfSense. Lorsque le client établi le tunnel, le serveur informe le client que la route vers le réseau (LAN) du serveur passe par le tunnel.
    Dans ce que tu veux faire, c'est un poste sur le LAN du serveur VPN qui veut joindre un poste sur le LAN du réseau "client"

    Ceci nécessite une route décrivant le tunnel comme route pour le réseau client, ce qui semble être le cas.
    Peux-tu afficher ici les routes présentes sur pfSense une fois le tunnel établi ?



  • Merci Chris pour l'aide que tu m'as apporté sur Skype/Mail.
    Mon problème n'es pas résolus mais je vais reposer les choses dans un nouveau topic avec un titre explicite et une présentation concrète des routes règles FW.
    J'ai tellement manipulé tout ça que vous serez perdu et perdrais du temps avec des shéma plus à jour ou mal décris.


Log in to reply