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

    RULES & NAT - SITEWEB

    Scheduled Pinned Locked Moved Français
    21 Posts 4 Posters 4.3k Views
    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.
    • P
      Pfense85
      last edited by

      J'ai créé un RULE

      Proto Source Port Destination Port Gateway           Queue Schedule
                      IPv4 * IP PUBLIQUES * WAN address     *         * none

      1 Reply Last reply Reply Quote 0
      • P
        Pfense85
        last edited by

        J'ai créé un rule sur les adresses ip avec l'alias IP PUBLIQUES

        Proto Source     Port Destination Port Gateway Queue
        IPv4 * IP PUBLIQUES * WAN address * *         none

        Et ensuite une NAT

        If         Proto Src. addr         Src. ports Dest. addr Dest. ports NAT IP                 NAT Ports
        WAN TCP         IP PUBLIQUES *                 LAN address 443 (HTTPS) 192.168.1.200 443 (HTTPS)

        Je viens de regarder mes logs et les adresses IP PUBLIQUES ne sont pas bloques sur le firewall.

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

          Il n'empêche que l'exemple est particulièrement mal choisi puisque c'est la même adresse avec des masques différents !
          Ma remarque est sur ce masque !

          Le mieux est TOUJOURS d'indiquer une adresse publique de la forme 81.xx.xx.1, 81.xx.xx.2 et ainsi de suite …
          (Cette notation permet de bien mentionner le côté 'je n'ai pas mis les vraies adresses'.)

          EDIT : J'ai commencé à écrire avant les 2 post supplémentaires !

          Si vous souhaitez avoir des avis, il serait judicieux de mettre une copie d'écran de vos règles.

          Je mentionne qu'une seule règle est nécessaire pour donner un accès à un serveur Intranet via une adresse publiques (c'est dire la difficulté).
          La seul règle nécessaire est bien évidemment un NAT port forward : je l'ai décrit le 8/1.
          L'utilisation d'alias dans une règle NAT ne me parait pas judicieux mais je peux me tromper.

          Par ailleurs, et c'est le principe de la mutualisation en http, la logique est plutôt d'avoir une seule ip publique et un serveur web capable de pousser plusieurs sites web (avec des noms différents).

          Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

          1 Reply Last reply Reply Quote 0
          • P
            Pfense85
            last edited by

            @jdh:

            Il n'empêche que l'exemple est particulièrement mal choisi puisque c'est la même adresse avec des masques différents !
            Ma remarque est sur ce masque !

            Le mieux est TOUJOURS d'indiquer une adresse publique de la forme 81.xx.xx.1, 81.xx.xx.2 et ainsi de suite …
            (Cette notation permet de bien mentionner le côté 'je n'ai pas mis les vraies adresses'.)

            EDIT : J'ai commencé à écrire avant les 2 post supplémentaires !

            Si vous souhaitez avoir des avis, il serait judicieux de mettre une copie d'écran de vos règles.

            Je mentionne qu'une seule règle est nécessaire pour donner un accès à un serveur Intranet via une adresse publiques (c'est dire la difficulté).
            La seul règle nécessaire est bien évidemment un NAT port forward : je l'ai décrit le 8/1.
            L'utilisation d'alias dans une règle NAT ne me parait pas judicieux mais je peux me tromper.

            Par ailleurs, et c'est le principe de la mutualisation en http, la logique est plutôt d'avoir une seule ip publique et un serveur web capable de pousser plusieurs sites web (avec des noms différents).

            Site Distant @IP PUBLIQUE / MASK

            81.XXX.XX.6/25
            83.XXX.XX.8/26
            94.XXX.XX.2/27
            87.XXX.XX.4/28

            Pfsense
            @IP PUBLIQUE 81.240.20.20
            @IP INTRANET  192.168.1.253

            Site Web intranet @IP INTRANET  192.168.1.200

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

              Bon, puisque vous ne semblez pas comprendre, expliquez comment, depuis Internet, accédez vous à 81.XXX.XX.6/25 ? (sous-entendu différemment de 81.xx.xx.6/32 ou /26)

              La règle NAT est correcte et indique une cible claire.
              Si cela pouvait vous inspirez …

              Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

              1 Reply Last reply Reply Quote 0
              • P
                Pfense85
                last edited by

                Depuis internet, les sites distants avec les adresses publiques ennoncées dans le topic doivent pouvoir communiquer avec le serveur de mon reseau informatique.

                C'est pour cette raison que je pensais créer une rule autorisant ces sites à communiquer avec le wan de mon pfsense et ensuite une nat qui redirige les communication vers mon ip lan 192.168.1.200

                Je suis perdu dans les solutions entre une NAT outbound, 1:1 et port forward.

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

                  En terme de règle sur le FW, il faut autoriser les adresses externes à accéder… à l'interface WAN.
                  Tu utilises bien ce concept pour ta règle de NAT.
                  Le sigle "∞" à gauche de ta règle de NAT signifie qu'il y a une règle de FW automatiquement créée avec cette règle de NAT.
                  Tu peux y accéder lorsque tu es en mode édition sur la règle de NAT  ;)

                  Et à l'occasion, tu constateras que la règle du tu crées manuellement ne marche pas car tu autorises à accès à l'IP de ton adresse LAN... sur l'adresse WAN

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

                  1 Reply Last reply Reply Quote 0
                  • P
                    Pfense85
                    last edited by

                    @chris4916:

                    En terme de règle sur le FW, il faut autoriser les adresses externes à accéder… à l'interface WAN.
                    Tu utilises bien ce concept pour ta règle de NAT.
                    Le sigle "∞" à gauche de ta règle de NAT signifie qu'il y a une règle de FW automatiquement créée avec cette règle de NAT.
                    Tu peux y accéder lorsque tu es en mode édition sur la règle de NAT  ;)

                    Et à l'occasion, tu constateras que la règle du tu crées manuellement ne marche pas car tu autorises à accès à l'IP de ton adresse LAN... sur l'adresse WAN

                    Si je resume la situation le NAT que j'ai créé est fonctionnel car tout ce qui arrive sur le wan avec le port 443 est redirigé vers mon lan.

                    Mais ma rule est n'est pas operationnelle je dois crée un rule sur le wan qui autorise les adresses IP PUBLIQUES.

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

                      @Pfense85:

                      Mais ma rule est n'est pas operationnelle je dois crée un rule sur le wan qui autorise les adresses IP PUBLIQUES.

                      …. si tu continues ta phrase jusqu'au bout:

                      une règle sur le WAN qui autorise les adresses publiques à accéder à l'adresse IP WAN (et pas LAN)  :P

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

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

                        Je vois que vous ne comprenez vraiment pas beaucoup !

                        1ère erreur :
                        Vos adresses 81.XXX.XX.6/25 sont stupides ! Si vous voulez ajouter des adresses virtuelles, elles seront /32, que l'on note sans le /32 par convention.

                        J'ai eu beau l'écrire plusieurs fois, posez plusieurs fois la question 'comment on fait', vous passez sur ces âneries sans comprendre …

                        2ième erreur :
                        J'écris que la règle NAT est correcte (et qu'elle génère automatiquement une règle liée dans l'onglet WAN).
                        J'écris les mot 'cible claire', et vous ne comprenez pas la suite logique

                        Il faut 1 règle NAT identique pour chaque ip virtuelle !
                        C'est quand même pas grand chose ...

                        Ce qui aurait été intelligent, c'est de créer des règles WAN pour accepter le ping sur les ip publiques. Mais ça, vous avez oublié en route.
                        Perso c'est ce que je commence par faire parce que cela permet de vérifier que les ip virtuelles sont bien 'présentes' et 'actives' au niveau du WAN.

                        En fait c'est souvent bien plus simple mais il faut juste faire ce qui est nécessaire.
                        Quand quelqu'un répète quelque chose, il faudrait comprendre que cela veut dire des choses ... Mais non ...

                        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

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