Problème NAT Reflection ?
-
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.
-
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.
-
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. -
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) ? -
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. -
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.
-
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 -
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.
-
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.
-
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'.