[RESOLU] Problème NAT sur interface OPT
-
J'écris D'ABORD ceci :
Si on est à l'extérieur, peut on avoir comme destination ces adresses ci ?
Evidemment NON ! Ce sont des adresses privées … donc inaccessibles depuis l'extérieur !
Il FAUT répondre, en français, à cette question !
La règle "port forward" qui créé ou non la "rules", je m'en moque.
Quand on est à l'extérieur, quelle(s) adresse(s) est accessible(s) ?
NB : les (s) sont en trop !!!!!
-
Alors ?
Pourquoi toutes ces règles "port forward" (NAT) sont elles mauvaises ?
Parce que la "destination" NE PEUT PAS être celle indiquées et testées !Donc, je répète, quelle est la "destination" à indiquer dans un "port forward" ?
Autrement dit, une machine reliée à WAN peut discuter avec quelle "destination" ? -
Ok ok t'énerve pas ;)
@jdh:
Quand on est à l'extérieur, quelle(s) adresse(s) est accessible(s) ?
Depuis l'extérieur, il n'y aura que l'adresse IP WAN de pfsense de disponible.
@jdh:
Donc, je répète, quelle est la "destination" à indiquer dans un "port forward" ?
Bah, jusqu'à maintenant, pour la part je pense au serveur dmz ?
single or alias -> Adresse IP serveur dmz
J'ai beau regarder d'autres tutos, et bien je ne trouve pas mon erreur…
http://www.figer.com/publications/nat.htm
Et même sur la doc :
http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F
A mon avis je doit me planter à l'étape 5
Je pense que ce que tu essais de me faire comprendre est détaillé dans cette doc :
Edit : Je pense avoir compris ce que tu veux me faire comprendre, mais j'arrive pas à le mettre sur papier…
-
Décidément, ces mécanismes vous sont totalement incompréhensibles !
Dans la doc pfSense, vous ne comprenez pas le point 3 ! (Alors le 5 …)
Une règle "port forward" a besoin de 2 paramètres (en terme d'adresse ip et en sus du "port")
- la destination
- la NAT IP
La destination c'est l'adresse ip accessible depuis la machine extérieure qui initie le trafic.
La NAT ip, c'est l'adresse ip de la machine interne vers laquelle le trafic est "forwardé".Le "port forward" c'est un tour de magie : une machine, à l'extérieur, envoie ses paquets à une "destination" (donc accessible), mais pfSense "forward" les paquets vers une machine interne.
Dans le cas simple de l'ADSL, on a UNE SEULE adresse ip publique (normalement la WAN address). C'est FORCEMENT la seule "destination" possible pour la machine extérieure.
Tandis que le NAT IP est une machine interne qui NE PEUT PAS être accessible directement de l'extérieur.Si vous mettez une machine du côté WAN (ici en 192.168.0.x) et en essayant de faire "ssh 192.168.1.x", c'est que vous ne comprenez RIEN !
Pour la machine en WAN, elle ne voit QUE l'interface WAN du pfSense ! (forcément).
MAIS, avec une règle "port forward", pfSense saura transférer le trafic du port donné vers une machine interne (la nat ip).Par exemple www.google.fr c'est 66.249.92.104, c'est une adresse accessible depuis Internet.
Mais c'est l'adresse externe du firewall à l'entrée de Google, ce n'est pas l'adresse réelle d'un des dizaines de milliers de serveurs web du réseau interne de Google.Mais alors pourquoi la "destination" n'est pas, par défaut, la WAN Address et peut être au choix ?
Parce que pfSense a la possibilité de gérer PLUSIEURS adresses du côté WAN (fournies par le FAI), et, à ce moment, on pourra choisir l'adresse externe.Encore une fois, vous ne lisiez que les dernières phrases :
la "destination", ca n'est pas la machine en DMZ ou dans le LAN (ce qui est d'ailleurs mauvais !)
par incompréhension, et par mauvaise lecture du schéma !Le WAN d'un pfSense est INFRANCHISSABLE ! Autrement dit une machine du côté WAN envoie des paquets à une adresse côté WAN.
Même si, après un port forward, le paquet arrive finalement à un serveur en DMZ ! -
Effectivement, j'ai un peu (beaucoup) honte de ma connerie. Je ne sais pas pourquoi je voulais absolument passer par l'adresse 192.168.3.253 puisque j'ai toujours, quand je suis à l'extérieur, taper l'adresse ip publique de la box avec le port qui allait bien.
Par contre, j'ai l'habitude, lors des règles nat, d'avoir comme matériel, une box, ou le petit routeur à porté de tous. Effectivement, l'adresse de destination je ne connaissais pas et j'ai déduit trop rapidement qu'il s'agissait de l'adresse du serveur dmz.
C'est quand même très sympa à toi d'être mon professeur d'informatique ;)
Pour ma part, la destination peut donc être mis à any, non ?
Voici mes réglages :
J'espère ne pas me faire taper sur mes doigts ce qui vas être surement le cas, car je dois avoir une erreur quelque part (connexion refused (ssh 192.168.0.253))
-
La destination n'est certainement pas "any" ! (Je pourrais être vexé après ce que je décris !)
Mais alors pourquoi la "destination" n'est pas, par défaut, la WAN Address et peut être au choix ?
Parce que pfSense a la possibilité de gérer PLUSIEURS adresses du côté WAN (fournies par le FAI), et, à ce moment, on pourra choisir l'adresse externe.La plupart du temps, la destination est (interface WAN / destination WAN Address) … puisque l'extérieur ne voit que cette adresse !
-
Wan address donne le même resultat :-\
-
Alors, …
Cette règle de "port forward" est correcte et conforme au fonctionnement logique d'un firewall (quel qu'il soit). (Enfin ?)
Mais, il faut aussi la règle "rules" (Firewall > Rules > onglet Wan) qui soit en accord avec le "port forward".
Avec 1.2.3, il est préférable de supprimer les 2 puis de recréer le "port forward" car il créé directement la bonne "rules".
Avec 2.0beta, je ferais de même, tout en notant qu'en principe la modification de la première entraine la seconde.Bien évidemment, je testerai avec une machine placé en Wan, puis finirai par regarder le renvoi sur la box (qui est en tout point identique à ce mécanisme !).
Au fait, comment est fait le test (côté Wan) ? Et peut-on tester cela du côté Lan ?
-
Coté WAN
Internet -> Livebox -> Pfsense -> différents LANs
Je tente avec une machine connecté en wifi sur la livebox. -> ko
Je tente avec une machine connecté dans n'importe quels autres LANs -> ok
Edit : J'ai recréé ma règle -> idem
-
Sur les 2 questions que je pose, l'une est volontairement destinée à votre réflexion :
- peut-on tester cela du côté Lan : evidemment c'est NON puisque cela n'a pas de sens de faire un ssh vers l'adresse Wan pour revenir en Dmz (ou, mauvais, Lan)
Il n'y a pas de réponse correctement à la première question, alors que c'est essentiel !
Après un énorme incompréhension sur le fonctionnement du port forward, je vois là un manque de précision, un manque de méthode …
Il faut se ressaisir !La PRECISION ! réaliser PAS A PAS, tester PAS A PAS ! L'ATTENTION aux détails ("The devil is in the details") !
Activer le log sur une règle, consulter les logs, tracer une communication avec tcpdump, ... cela s'apprend en le faisant ...
NB : tant qu'à faire : pourquoi ne pas balayer CHAQUE élément en jeu : la règle "port forward", la règle "rule", les autres rules, la façon de faire le test (parce que les tests précédents étaient illogiques !)
Franchement c'est un peu long pour un problème quand même assez basique ...
-
@jdh:
Franchement c'est un peu long pour un problème quand même assez basique …
Je suis bien d'accord
@jdh:
Sur les 2 questions que je pose, l'une est volontairement destinée à votre réflexion :
- peut-on tester cela du côté Lan : evidemment c'est NON puisque cela n'a pas de sens de faire un ssh vers l'adresse Wan pour revenir en Dmz (ou, mauvais, Lan)
Si, on peut tester et cela fonctionne. Bien sur cela perd tout son sens, non ?!
Sans partir dans les outils d'analyses réseaux, ma règle est bien bonne d'après ton précédent message ?
C'est un truc tout bête où l'on doit passer moins de 30 secondes à faire sa règle. Es-ce que toi tu vois une erreur quelques part ?
-
Rebonjour jdh
Malgré mes quelques incompétences en la matière j'ai réussit (enfin me dira tu) à faire ce que je voulais.
La solution au problème ? l'adresse de la patte coté WAN qui était erroné.
J'ai remarqué ceci, et je ne sait pas si c'est un bug de cette version. Mais quand je changeais l'adresse IP coté WAN par le biais de la configuration en http et bien cela ne fonctionnais qu'a moitié.
C'est à dire que lorsqu'à la place de mettre 192.168.0.254 je mettait l'adresse 192.168.254.254 l'adresse définitive était 192.168.254.10.
Je ne sais pas si cela proviens du fait que sur cette version de pfsense à la possibilité de gerer plusieurs adresse côté WAN qui à mis le basard dans ma configuration ?
Bref, j'ai remarqué le problème en mettant le DHCP coté WAN (j'en est eu besoin temporairement). Le serveur qui me le fournissait était en 254.10
Pour finir, j'ai l'adresse directement en console pour résoudre le problème.
Maintenant cela fonctionne correctement.
J'espère ne pas t'avoir trop enquiquiné, mais cette expérience m'as beaucoup appris.
Merci mille fois. ;)