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

    Probleme DNS et redirection vers l'interface de connexion

    Français
    3
    6
    1.1k
    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.
    • R
      Redsnow
      last edited by

      Bonjour,

      Pour mon projet de fin d'étude, j'aimerais réaliser un portail captif pour une société fictive. Voici ma configuration :

      PC CLIENT -> PFSENSE (DHCP lan) -> windows serveur 2012 R2 (DNS + AD) -> BBox3 (internet)

      PFSENSE LAN : 172.16.3.1/24 (statique)
      PFSENSE WAN : 192.168.1.69/24 (statique)

      Windows serveur 2012 R2 (faisant donc parti du WAN) : 192.168.1.64/24 (statique)
      BBox3 (passerelle du WAN) : 192.168.1.1/24 (statique)

      Donc avec tout ça, j'ai créé mes utilisateurs sur mon windows server 2012 et j'ai configuré le LDAP pour avoir accès à mes utilisateurs. Le PFSENSE distribue les adresses IP sur l'interface LAN, c'est son seul autre rôle (outre faire office de portail captif). J'ai configuré le pare-feu pour que toutes les requêtes passent vers toutes les destinations et j'ai configuré les requêtes sur le port 53 en UDP. J'ai configuré le NAT pour que toutes les requêtes faites sur "172.16.3.0/24" passent vers "192.168.1.69/24".

      PROBLEMES :

      • Sur mon client je n'arrive pas à faire de résolution DNS ?
      • Mon client n'est pas redirigé vers le portail captif (je dois moi même écrire l'adresse)

      D'où viens le problème et comment puis je le résoudre ?

      Merci infiniment à ceux qui m'aiderons.

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

        Si tu crées des règles de FW qui autorisent tout dans tous les sens, comment le portail captif doit-il fonctionner ?
        Son rôle étant justement d'ouvrir des règles en fonction du comportement de l'utilisateur, si tout est déjà ouvert, ça ne sert à rien.

        • Quel est le DNS configuré sur tes postes utilisateurs ? pfSense ou Windows ?
        • Qu'entends-tu exactement par "j'ai configuré les requêtes sur le port 53 en UDP." ?
        • et surtout, ce point n'est pas rassurant: "J'ai configuré le NAT pour que toutes les requêtes faites sur "172.16.3.0/24" passent vers "192.168.1.69/24"". en effet, par défaut, sans rien configurer de spécial, pfsense va mettre en place tout seul les options de NAT nécessaires au fonctionnement correct. La modification des options de NAT par défaut est nécessaire dans quelques cas mais pas dans ce que tu vises.

        Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

        1 Reply Last reply Reply Quote 0
        • R
          Redsnow
          last edited by

          @chris4916:

          Si tu crées des règles de FW qui autorisent tout dans tous les sens, comment le portail captif doit-il fonctionner ?
          Son rôle étant justement d'ouvrir des règles en fonction du comportement de l'utilisateur, si tout est déjà ouvert, ça ne sert à rien.

          • Quel est le DNS configuré sur tes postes utilisateurs ? pfSense ou Windows ?
          • Qu'entends-tu exactement par "j'ai configuré les requêtes sur le port 53 en UDP." ?
          • et surtout, ce point n'est pas rassurant: "J'ai configuré le NAT pour que toutes les requêtes faites sur "172.16.3.0/24" passent vers "192.168.1.69/24"". en effet, par défaut, sans rien configurer de spécial, pfsense va mettre en place tout seul les options de NAT nécessaires au fonctionnement correct. La modification des options de NAT par défaut est nécessaire dans quelques cas mais pas dans ce que tu vises.

          Merci de ta réponse Chris,

          • Le DNS configuré sur mes postes utilisateurs est le suivant : 192.168.1.64 (le serveur WINDOWS SRV 2012)
          • J'ai supprimé cette option, elle m'est inutile.
          • Je l'avoue, mes connaissances en PFsense ne sont pas très élevé, j'ai trouvé ça sur internet et je pensais que c'était utile, je viens de le retirer merci :)

          Problème actuel :

          • Mes utilisateurs ne sont pas rediriger vers l'interface d'authentification du portail captif et n'ont pas accès à internet.
          • LE DNS ne fonctionne pas, pas de résolution possible.

          Potentiele idées de résolution :

          • J'ai lu sur internet ce matin que je ferais mieux de mettre mon windows serveur du coté LAN et qu'il soit DHCP et DNS, le pfsense lui autorisera toujours le windows serveur afin qu'il ait accès à internet pour permettre la rsolution DNS. Du coup, je deverai faire du NAT sur mon Windows Serveur

          Qu'en pensez vous ?

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

            pfSense n'est jamais qu'un bundle de composants. Ce qui est important de comprendre, ce n'est pas "pfSense" mais le principe de fonctionnement des différents services qui le composent et que tu utilises (ou pas).

            Bien sûr qu'il est fortement souhaitable que la résolution DNS soit accessible aux postes clients sans quoi… ça ne marche pas  ;D
            Mais il y a différentes manières d'obtenir ce résultat.

            Dans le cas précis d'HTTP, si les postes clients utilisent un proxy explicite, ils n'ont pas d'autre besoin que celui de résoudre l'adresse de celui-ci car c'est ensuite le proxy qui se charge de résoudre les fqdn.
            Ce qui rend les choses beaucoup plus simple, de ce point de vue car le DNS client se charge des résolutions "internes" et le proxy s'appuie sur un DNS qui se charge des résolutions "internet".

            La difficulté du proxy, lorsque tu couples ce composant avec le portail captif, c'est de bien comprendre que l'accès internet (si le proxy est utilisé pour l'accès internet  ;)) va se faire via le proxy et donc celui-ci doit se trouver après le portail captif sans quoi c'est ce dernier qui va être autorisé à traverser le portail.

            Ce que je te suggère, c'est, avant de vouloir empiler toutes les fonctionnalités, c'est de le faire progressivement en t'assurant que tu comprends bien chaque étape, sachant qu'au final, ton portail captif va se retrouver en coupure entre "le réseau local" et "internet".
            Donc les clients doivent résoudre les noms coté réseau local
            ils doivent s'appuyer sur un service (DNS, forwader ou resolver) qui résout les noms "internet"
            Le portail captif tournera à l'adresse IP qui est la passerelle par défaut des postes clients.

            Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

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

              je deverai faire du NAT sur mon Windows Serveur

              Quel rapport ?

              L'approche pas à pas est à privilégier. Sans oublier de comprendre les bases de fonctionnement tcp/ip et protocoles associés notamment dns. Après cela la "compréhension" de Pfsense est presque accessoire. La majorité des personnes qui arrivent ici avec des problèmes étiquetés Pfsense ont en réalité des problèmes de compréhension ou connaissances des mécanismes basiques.

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

                @ccnet:

                La majorité des personnes qui arrivent ici avec des problèmes étiquetés Pfsense ont en réalité des problèmes de compréhension ou connaissances des mécanismes basiques.

                C'est mon analyse également  ;)
                Ce qui n'empêche pas de discuter des sujets en question dans la mesure où s'est quand même mis en œuvre via ou autour de pfsense 8)

                Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.