Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Problème de routage Vlan / LAN / DHCP avec ESXI

    Français
    5
    11
    1668
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      bakara49 last edited by

      Bonjour,

      Je suis nouveau sur le forum et mon ancien firewall un dlink 210 ayant brulé (oui au sens propre), je souhaite utiliser pfsense pour le remplacer en utilisant la virtualisation vmware ESXi.
      le serveur est composé de 10 interfaces physiques (2 nic natives + 2 quad intel i350-t4).

      Contexte: maison pour mon labo de test, je ne suis pas débutant(hic).

      schéma de l'installation:

      Les interfaces physiques 4-5-6-7 sont pour le firewall pfsense.
      les interfaces 3-4 sont les WAN.
      les interfaces 6 et 7 sont le LAN et la DMZ.
      La DMZ n'est pas configurée.

      sur le switch (dlink dgs1210), le port P10 est untagged dans le VLAN50. Il est attribué au PC01.
      Le port p1-p2 est taggué dans différents VLAN (celui de l'ESXi)

      WAN:
      j'ai 2 connexions ADSL.

      1 WAN OVH
      1 WAN FREE
      Ils sont mis en load balancing.

      DMZ: pas configuré.

      LAN: adressage en 192.168.1.0/24. Le dhcp est activé pour l'interface LAN plage de 192.168.1.10 à 192.168.1.245.
      Attention:

      Sur cette interface, j'ai créé 1 VLAN.

      VLAN50: 192.168.50.0/24 avec ip de l'interface 192.168.50.1. Le dhcp est activé sur cette interface VLAN50 plage de 192.168.50.2 à 192.168.50.10

      Je ne veux pas configurer les autres interfaces tant que le vlan ne fonctionne pas.

      Ce que je souhaite faire:

      point 1: Faire communiquer le VLAN 50 et l'interface LAN en autorisant uniquement  HTTP/HTTPS

      point 2: Faire communiquer l'interface VLAN50 à internet. (1 station du VLAN50 doit pouvoir surfer)

      Le point 1 n'est pas prioritaire.

      Mar ègle de firewall pour l'interface VLAN50 est la suivante:

      ID PROTO SOURCE PORT DESTINATION PORT GATEWAY QUEUE

      ipv4             VLAN50 net * * *         gwvlan50                     none

      ici gwvlan50 est la passerelle du vlan50 , j'ai mis l'ip de l'interface vlan50 à savoir 192.168.50.1.

      TESTS EFFECTUES:

      ping d'une vm dans le vlan50 sur la passerelle: KO . je n'arrive pas à faire un ping.

      PC01 dans aucun VLAN. AUCUNE ADRESSE DHCP n'est récupérée.

      Les passerelles des LAN et VLAN50 doivent-elles être respectivement 192.168.1.1 et 192.168.50.1 ?

      Que mettre comme passerelle pour la regle de firexall / advanced feature ? celle par défaut, du VLAN , du LAN ?

      merci de l'aide que vous pourrez me donner.


      1 Reply Last reply Reply Quote 0
      • C
        ccnet last edited by

        Dans des messages précédents j.ai expliqué à plusieurs reprises comment monter des vlans qui fonctionnent. Je me répète donc : on ne monte rien sur l'interface physique. On monte les vlans 1 et 50 dans votre cas sur cette interface. On reboot. A partir de la cela fonctionne. Si vos cartes gèrent correctement les vlans.
        Pour le reste je redis pour mémoire l'ineptie qu'il y a à virtualiser un firewall. Certes c'est une config de test. Admettons. Si ce n'est que l'on ne peut rien généraliser des tests. A vous de voir.

        1 Reply Last reply Reply Quote 0
        • J
          jdh last edited by

          En sus de ccnet, je ne suis pas sûr de

          Mar ègle de firewall pour l'interface VLAN50 est la suivante:

          ID      PROTO  SOURCE        PORT        DESTINATION        PORT      GATEWAY        QUEUE

          ipv4              VLAN50 net      *              *            *                gwvlan50                        none
          ici gwvlan50 est la passerelle du vlan50 , j'ai mis l'ip de l'interface vlan50 à savoir 192.168.50.1.

          Etes vous sûr que la gateway puisse avoir une valeur interne ?

          1 Reply Last reply Reply Quote 0
          • B
            bakara49 last edited by

            Bonjour,

            merci de vos réponse ccnet jdh.

            CCNET: Si je comprends bien, tu veux que je mon en plus sur l'interface LAN un VLAN qui est la VLAN1 ?

            Mais quel réseau lui donner ?
            et donc après je désactive l'interface LAN et je ne garde que les interfaces virtuelles (VLAN1 VLAN 50).

            JDH: Mon VLAN50 est en 192.168.50.0/24 sa passerelle est logiquement 192.168.50.1 (pour moi mais cela aurait peu etre 192.168.50.254°

            CCNET: tu confirmes ou pas ?

            merci

            1 Reply Last reply Reply Quote 0
            • C
              ccnet last edited by

              Pas en plus. A la place.

              1 Reply Last reply Reply Quote 0
              • J
                jdh last edited by

                La gateway d'une règle n'a rien à voir avec la gateway d'un réseau !!
                En anglais ça s'écrit 'policy routing' !

                1 Reply Last reply Reply Quote 0
                • C
                  chris4916 last edited by

                  @jdh:

                  La gateway d'une règle n'a rien à voir avec la gateway d'un réseau !!
                  En anglais ça s'écrit 'policy routing' !

                  oui… avec cependant un commentaire explicatif.

                  La remarque à propos de l'utilisation d'une adresse interne en tant que gateway pour cette règle est tout à fait correcte. Ce choix n'a pas beaucoup de sens ici.
                  Cependant le concept de gateway au niveau d'une règle est bien celui d'une gateway réseau.

                  Dans l'écriture d'une règle pour le FW, il y a 2 choix en terme de gateway:

                  • laisser "default", auquel cas le routage utilise les valeurs de routage du système (c'est très généralement le bon choix)
                  • la possibilité de choisir une des gateway définie au niveau des paramètres réseau, ce qui permet de faire du routage basé sur une règle de FW (le "policy routing" correspond à l'association de ce routage (routing) à la règle (policy)

                  Ce qui est vraiment intéressant dans ce point de détail, c'est que la sélection au niveau de l'interface des gateway se fait via une dropdown box. Ce qui signifie que gwvlan50 est définie comme gateway dans pfSense, ce qui n'a probablement pas beaucoup de sens.
                  Du point de vue de pfSense, la, ou les si il y a plusieurs WAN,  gateway correspond à l'adresse utilisée pour le flux sortant. S'il devait y avoir des gateway sur le réseau interne, ce qui est techniquement possible, ce seraient des adresses IP internes mais pas celles de pfSense lui-même.

                  Ce qui n'empêche pas les interfaces internes de pfSense d'être les gateway des machines sur le réseau interne  :)  mais ceci ne nécessite pas d'être défini en tant que tel en terme de réseau sur pfSense et ce n'est donc pas disponible dans les policy routing  8)

                  1 Reply Last reply Reply Quote 0
                  • J
                    jdh last edited by

                    (L'art de noyer le lecteur !)

                    La 'gateway' d'une règle permet d'indiquer, au niveau de pfSense, la sortie de flux désigné par la règle.
                    Par exemple, avec un pfSense avec 2 interfaces WAN1 et WAN2, et donc 2 gateway gtWAN1 et gtWAN2,
                    la gateway d'une règle sera donc ou gtWAN1 ou gtWAN2 selon le choix voulu.

                    Il est évident que ce système ne concerne donc que le multi-WAN et rien d'autre.

                    Le fait que l'interface LAN du pfSense soit gateway des PC connectés à cet interface n'a donc rien à voir (et ne saurait être configuré sur pfSense !).

                    Le texte pour une règle est 'Leave as 'default' to use the system routing table. Or choose a gateway to utilize policy based routing.'.
                    Soit cela vous parle et vous savez quoi faire, soit cela ne vous parle pas, et vous laissez 'default'.

                    Autre façon de dire : les seules gateways à indiquer dans un pfSense sont des routeurs vers un autre réseau : sur les interfaces WAN le plus généralement. En aucun, on indique le pfSense comme gateway !

                    1 Reply Last reply Reply Quote 0
                    • B
                      bakara49 last edited by

                      Bonjour,

                      Merci pour ces infos sur la routing policy.

                      CCNET, tu indiques que l'on doit "désactiver" l'interface physique et mettre le ou les vlan à la place.

                      OK. Je prends ma 3eme interface physique (celle qui sera pour ma DMZ). Mais pour mon test, considères la comme une simple interface.

                      1- Je creer le vlan35.
                      2- Je lui affecte l'ip 192.168.35.1 /24
                      3- Je reboot pour etre sur de la prise en compte du vlan.
                      4- Je regle le dhcp du vlan35 de 192.168.35.10 –> 192.168.35.20
                      5- Les règles de firewall sont les suivantes.

                      interf. vlan35: Je laisse tout passer sur cette interface vlan35.
                      interf. WAN: Je laisse passer tout le traffic sur l'interface vlan35 en direction  WAN.

                      Sur mon ESXi:

                      Création d'une NIC dans le VLAN35.
                      Ma VM windows 7 a cette carte réseau d'attribuée (donc dans le vlan35).

                      Sur le switch
                      Je taggue le port P8 dans vlan 35 (qui correspond à l'interface physique sur lequel est configuré le vlan 35).

                      Résultat: depuis la VM, je n'obtiens pas d'adresse du DHCP. Je mets une ip en dure 192.168.35.100 /24 et gateway 192.168.35.1.
                      Je n'arrive pas à faire de ping de la passerelle du vlan35 (c'est à dire 192.168.35.1).

                      Je suis vraiment perplexe devant cette situation. On ne peut pas faire plus simple.
                      1 vlan, 1 dhcp, une VM, la carte reseau virtuelle dans le vlan35.

                      Si vous avez des pistes ? switch ? pfsense ?

                      merci

                      1 Reply Last reply Reply Quote 0
                      • Tatave
                        Tatave last edited by

                        salut salut

                        avez vous pensé à faire accepter les vlan au niveau d'esxi.

                        Cordialement.

                        1 Reply Last reply Reply Quote 0
                        • B
                          bakara49 last edited by

                          bonsoir,

                          Les ports de l'ESXi sont bien dans le bon VLAN. y compris celui de de l'interface physique du VLAN 35. La carte virtuelle de l'ESXi est bien dans le VLAN35.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post

                          Products

                          • Platform Overview
                          • TNSR
                          • pfSense
                          • Appliances

                          Services

                          • Training
                          • Professional Services

                          Support

                          • Subscription Plans
                          • Contact Support
                          • Product Lifecycle
                          • Documentation

                          News

                          • Media Coverage
                          • Press
                          • Events

                          Resources

                          • Blog
                          • FAQ
                          • Find a Partner
                          • Resource Library
                          • Security Information

                          Company

                          • About Us
                          • Careers
                          • Partners
                          • Contact Us
                          • Legal
                          Our Mission

                          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                          Subscribe to our Newsletter

                          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                          © 2021 Rubicon Communications, LLC | Privacy Policy