Navigation

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

    Problème NAT Reflection ?

    Français
    3
    11
    1122
    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.
    • W
      wallack last edited by

      Bonjour à tous,

      Mon existant :

      J’ai  plusieurs adresses IP publiques :
      217.119.180.114
      217.119.180.115
      271.119.180.116
      etc

      Interface 1 : LAN
      Interface 2 : DMZ (contient  les serveurs FTP et SFTP)

      Dans Firewall : Virtuals IP :
      J’ai déclaré 217.119.180.115/32

      Dans Firewall : Nat : Port Forward :
      WAN TCP * * 217.119.180.115  22 (SSH) srv_sftp 22 (SSH)

      WAN TCP * * 217.119.180.115  21 (FTP) srv_freenas 21 (FTP)

      Dans Firewall : Nat : 1 :1 :
      WAN 217.119.180.115  192.168.1.14 * sftp

      WAN 217.119.180.115  192.168.1.5 * ftp, support

      Mon problème :

      Depuis le LAN, pas de problème si j’attaque les serveurs FTP et SFTP sur leurs adresses locales

      Depuis ailleurs aucun problème si j’attaque les serveur FTP et SFTP sur l’ip publique 217.119.180.115

      Par contre en utilisant le Nat Réflection, j’ai un problème depuis mon LAN si j’essaie de joindre le serveur FTP en utilisant l’adresse publique 217.119.180.115 mais je n’ai pas ce problème si j’attaque le SFTP de la même manière.

      De quoi cela peut venir ?

      J’ai fait exactement les mêmes règles que vous pouvez voir ci-dessus.

      Je sais que vous allez me dire de faire une règle entre le LAN et la DMZ mais j’ai absolument besoin de pouvoir l’attaquer sur cette IP publique.

      Donc si vous avez une idée c’est avec plaisir.

      Je reste disponible si vous avez d’autres questions ou que vous voulez des compléments d’informations sur ma config.

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

        De quoi cela peut venir ?

        Avez vous regardé de près le fonctionnement de ftp, les différents modes ? C'est fort différent de sfttp.

        j’ai absolument besoin de pouvoir l’attaquer sur cette IP publique.

        Je suis très curieux de savoir pourquoi depuis un lan on a absolument besoin de joindre une machine en dmz avec son ip publique.

        1 Reply Last reply Reply Quote 0
        • W
          wallack last edited by

          Cela fonctionnait sur IPCOP avant que je passe sur PFSENSE.
          Aucune modification n'a été faite sur le serveur FTP.

          Je pense donc qu'il me manque un paramétrage au niveau de PFSENSE.

          En réalité j'ai un IPCOP sur une autre IP publique 217.119.180.119 avec un autre LAN derrière sur lequel je dois pouvoir accéder au FTP -> Le problème ne vient pas de ce FW il laisse tout passer pour le moment et cela fonctionnait avant la migration.

          Mais j'ai fais une demande pour mon LAN qui présente le même symptôme afin de simplifier ma demande.

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

            Rien compris. Un schéma de l'ensemble serait salutaire.
            Pour FTP je vous incite à bien regarder et comprendre son fonctionnement selon que vous êtes en mode passif ou actif. Vous n'êtes pas sans savoir que FTP peut nécessiter, selon le mode, différents ports ouverts. Vous déduirez la configuration de Pfsense.

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

              Avec un firewall avec ip publiques et des règles de NAT forward vers des serveurs en DMZ, il est clair que l'on doit tester le NAT Forward.
              Mais on a besoin de le tester qu'une fois … pour vérifier que le transfert fonctionne.
              Ensuite, en général, on accède de LAN à DMZ via un nom de domaine en utilisant un "split-dns" ...
              Pourquoi vouloir utiliser des adresses ip publiques et une 'reflexion' alors qu'un nom de domaine suffit (et est naturel) ?

              1 Reply Last reply Reply Quote 0
              • W
                wallack last edited by

                Schéma : http://hpics.li/51e058f

                C'est du FTP passif et les ports correspondants sont ouverts correctement puisque cela fonctionne très bien depuis une adresse externe.
                Je vais quand même essayer de creuser à ce niveau voir ce que je peux trouver.

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

                  Je continue à ne pas comprendre l'intérêt qu'il y aurait à accéder au ftp 192.168.1.5 depuis le réseau 192.168.60.0/24 en utilisant l'ip 217.119.180.115 puisque cela fonctionne bien avec l'ip privée. Par ailleurs la solution propre, simple, efficace c'est bien le mécanisme DNS split horizon.

                  1 Reply Last reply Reply Quote 0
                  • W
                    wallack last edited by

                    Je peux accéder au 192.168.1.5 depuis le LAN 192.168.60.0

                    Mais pas depuis le 192.168.200.0 d'ou l'idée de l'attaquer sur l'ip Publique. Cela fonctionnait bien comme cela avant que je migre sur Pfsense.

                    Ok je ne connais pas ce mécanisme mais je vais donc me pencher dessus. Mais même si il voit que c'est une requête externe et qu'il me résout mon nom depuis 192.168.200.0 vers l'ip publique 217.119.180.115 , je pense que cela ne marchera pas vu que cela ne marche déjà pas avec la simple IP publique …

                    Sinon dans mon Dns Forward j'ai déjà renseigné ceci pour mon LAN 192.168.60.0 mais ce n'est pas le problème.
                    Host Overrides :
                    ftp Toto.com 192.168.1.5
                    sftp Toto.com 192.168.1.14

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

                      Le problème est tout différent compte tenu de votre topologie réseau. Deux solutions dans votre cas.

                      1. Un réseau propre avec un troisième patte sur Pfsense pour connecter 192.168.200.0/24. L'ip 217.119.180.115 est ajoutée sur l'interface wan de Pfsense. Pas besoin de nat reflection. Le split horizon règle votre problème si vous voulez utiliser des noms au lieu des ip et on accède depuis l'extérieur comme l’intérieur avec un nom du type ftp.domaine.com.

                      2. L'architecture réseau ne bouge pas et pas besoin non plus de nat reflection puisque votre situation est analogue à celle d'un utilisateur externe dès lors que l'on veut se connecter au ftp depuis le réseau 192.168.200.0/24. En effet il n'y a pas de lien autre qu'un lien wan entre le réseau 192.168.200.0/24 et d'autre part 192.168.60.0/24. Il faut que le routage soit correct sur le Cisco.

                      Avec votre post initial il est impossible de comprendre la situation. A aucun moment on n'a connaissance des deux lans séparés.

                      1 Reply Last reply Reply Quote 0
                      • W
                        wallack last edited by

                        En effet, excusez moi pour ma mauvaise explication.

                        Je vais chercher au niveau du cisco pour l'option 2 car je n'ai plus de patte disponible pour faire l'option 1.

                        Encore merci à vous d'avoir prit le temps de m'aider.

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

                          Comme dit (excellement) par ccnet, le schéma, s'il avait été fourni dès le post initial, aurait évité de partir dans de mauvaises suppositions.

                          Il est très clair qu'il faut 'tuer' votre Ipcop : pourquoi gérer 2 firewall différents alors que pfSense peut parfaitement gérer 3 réseaux internes (dont 1 DMZ) (ce dont est incapable Ipcop !).
                          Enfin le split-dns ou horizon est une astuce assez basique qui évite d'utiliser une bricole tel le 'NAT reflexion'.

                          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