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

    RULES & NAT - SITEWEB

    Français
    4
    21
    4.0k
    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.
    • J
      jdh
      last edited by

      Que tout cela est confus !
      Merci de noter WAN au lieu de PUBLIQUE et LAN au lieu d'INTRANET : les noms de ces interfaces sont usuels, et sauf à compliquer, je ne vois pas l'intérêt …

      Mes sites distants n'arrivent pas à pinger sur l'adresse @IP PUBLIQUE 81.240.20.20 de mon Pfsense alors que j'ai créé une rules.

      Il faut, en effet, pour avoir une réponse à un test de ping, une règle dans l'onglet WAN. Quelle règle avez vous créée (qui ne fonctionnerait pas) ?

      81.200.30.1/25  …  81.201.30.1/26  ...  81.202.30.1/27  ...  81.203.30.1/28

      Ce ne serait pas plutôt 81.200.20.1/32 pour votre 2ième adresse ip publique (présente sur WAN) ? J'aimerais bien savoir comment vous feriez la différence entre vos écritures …

      Le but est permettre au site distant de communiquer directement avec mon siteweb intranet via des rules et nat sur le Pfsense.

      Cette phrase est incorrecte.

      La bonne version :

      On crée une règle NAT (de type 'port forward') pour permettre l'accès depuis Internet à un serveur web interne.
      (La règle NAT crée automatiquement une règle dans l'onglet WAN.)

      J'ajoute : il ne faut surtout pas s'amuser à modifier la règle créé de l'onglet WAN.

      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
      • TataveT
        Tatave
        last edited by

        Salut salut,

        Je suis personnellement sur une conf en double box (orange/free) je n'ai pas de soucis de redirection vers mes machines ou services en arrière de mon cluster pfsense.
        en résumé que cela soit avec un cluster ou un simple pare feu PF.

        Le wan écoute toutes les requêtes sur un port déterminé venant de toutes sources ip à destination d'une ip dans un segment réseau derrière votre PF sur un port défini.
        Mais il faut avoir au préalable paramétré dans le NAT onglet outbount en "manual outbount". (il y a suffisamment de tuto sur le web pour cela)

        Pour une simplicité de relecture des regles, pensez à mettre en place des alias pour les ip_machines / ports_machines

        Pensez simples == pensez efficace.

        Cordialement.

        aider, bien sûre que oui
        assister, évidement non !!!

        donner à manger à un homme, ne lui permettra que de survivre qu'un temps.
        apprendre à un homme comment cuisiner, il sera vivre.

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

          @jdh:

          81.200.30.1/25
          81.201.30.1/26
          81.202.30.1/27
          81.203.30.1/28

          Ce ne serait pas plutôt 81.200.20.1/32 pour votre 2ième adresse ip publique (présente sur WAN) ? J'aimerais bien savoir comment vous feriez la différence entre vos écritures …

          Je n'avais pas fait attention aux (fausses) adresses IP  ;D ;D
          ça sent le copier/coller dans un tableur  ;)

          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

            Les adresses IP PUBLIQUES cités sont des exemples c'est pour le principe.  J'ai créé un ALIAS regroupant les IP PUBLIQUES que j'ai besoin.

            1 Reply Last reply Reply Quote 0
            • 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.