[RESOLU] Problème NAT sur interface OPT



  • Connection sur 192.168.1.253 à partir du WAN -> OK
    Connection sur 192.168.3.253 à partir du WAN -> KO

    Ces deux machines ne sont pas dans le même réseau. Sont elles connectées à la même interface de pfsense ?



  • @ccnet:

    Connection sur 192.168.1.253 à partir du WAN -> OK
    Connection sur 192.168.3.253 à partir du WAN -> KO

    Ces deux machines ne sont pas dans le même réseau. Sont elles connectées à la même interface de pfsense ?

    Non, cela est 2 interfaces différentes



  • @jdh:

    Le choix du mot "NAT" seul est très gênant : il faut utiliser le terme "port forward" !

    Si on veut, de l'extérieur, accéder à une machine en lan et une en dmz, il faut :

    • une règle "port forward" : Firewall > NAT > Port forward : avec Interface = Wan + External address = Interface Address
    • une règle "rule" : Firewall > Rules > onglet WAN

    NB : dans le lan, on n'essaiera pas de tester le cas : cela est prévu et fonctionne DEPUIS l'extérieur !

    Dans pfSense 1.2.x, la création du port forward créé la règle "rule", mais la modif du port forward ne la modifie pas !
    Dans pfSense 2.x, les définitions sont synchronisées.

    Je fait mes études dans l'administration réseau (Bac Pro) et j'essaye plus ou moins de décodé ce que tu m'as écrit ;)



  • @jdh:

    Le choix du mot "NAT" seul est très gênant : il faut utiliser le terme "port forward" !

    Si on veut, de l'extérieur, accéder à une machine en lan et une en dmz, il faut :

    • une règle "port forward" : Firewall > NAT > Port forward : avec Interface = Wan + External address = Interface Address
    • une règle "rule" : Firewall > Rules > onglet WAN

    NB : dans le lan, on n'essaiera pas de tester le cas : cela est prévu et fonctionne DEPUIS l'extérieur !

    Dans pfSense 1.2.x, la création du port forward créé la règle "rule", mais la modif du port forward ne la modifie pas !
    Dans pfSense 2.x, les définitions sont synchronisées.

    Bon, après avoir bien relu ton message, il se trouve que j'ai effectivement essayé de creer la règle rule automatiquement. Voyant que cela ne fonctionnait pas j'ai laissé l'action pass à la place de la création automatique de la règle rule.

    Effectivement, j'ai pu constaté (et j'aurais tendance à apprécier) que les définitions sont syncrhonisées.

    Sinon, pour arriver à mes fin, comment doit-je creer cette foutu règle alors ???



  • Beh, on supprime et on recréé, correctement cette fois !
    Mais avant on regarde :

    La première image est celle du "port forward" (Firewall > Nat > onglet "port forward") en v2.

    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 !

    Depuis l'extérieur, on ne voit QUE l'adresse ip de WAN (Interface Address) (ou des ip virtuelles si notre fai a été trop généreux !).
    Le port forward transfère le flux désigné vers la "vraie" destination appelé NAT IP.
    Le port IP permettant, de plus, de substituer un n° de port (entrée en 2253 mais arrivée en 22).



  • D'accord, je recreer.

    Bon, avant tout je donne un max d'informations :

    Ensuite je creer ma règle NAT de cette manière :

    Dite moi si je me trompe

    Je prend soin de vider les logs du firewall qui se remplissent un peu trop vite à mon goût

    Puis je me place coté WAN :

    En revanche coté LAN :

    Où se situe le problème ?



  • Ces tests n'ont aucun sens !
    J'ai déjà écris pourquoi en posant une question dans mon post précédent !

    Par ailleurs

    • WAN ayant une adresse privée (rfc1918), il n'est pas judicieux d'activer "block private networks",
    • l'écriture de la règle "port forward" n'a aucun sens.

    Il y a une enoaurme confusion (incompréhension) !

    Enlevez les mains du clavier, relisez ce que j'écris, dessiner le schéma avec la position de chaque matériel, faites fonctionner votre cerveau …
    Et, un, vous écrirez un autre "port forward", deux, vous ferez d'autres tests, et cela fonctionnera.



  • @jdh:

    • WAN ayant une adresse privée (rfc1918), il n'est pas judicieux d'activer "block private networks",

    Même si derrière il y le modem routeur directement (pas de filtrage) ?

    @jdh:

    dessiner le schéma avec la position de chaque matériel,

    Voici un schéma du réseau lorsqu'il fonctionnais. J'avais un problème de VPN donc ne pas tenir compte de la partie de gauche

    @jdh:

    faites fonctionner votre cerveau …

    Je sais bien  :o Et J'essaye aussi beaucoup  ;D

    @jdh:

    Il y a une enoaurme confusion (incompréhension) !

    Impeccable, je suis là pour comprendre et corriger mes erreurs.

    @jdh:

    J'ai déjà écris pourquoi en posant une question dans mon post précédent !

    Oui j'ai eu l'occasion de voir et je t'explique ce que j'ai compris et ce qui est encore confus pour moi :

    @jdh:

    Le port forward transfère le flux désigné vers la "vraie" destination appelé NAT IP.
    Le port IP permettant, de plus, de substituer un n° de port (entrée en 2253 mais arrivée en 22).

    Mais tout cela se trouve bien sur la page Firewall -> NAT on peut comme sur la screen substituer un numéro de port , non ?

    @jdh:

    Si on veut, de l'extérieur, accéder à une machine en lan et une en dmz, il faut :

    • une règle "port forward" : Firewall > NAT > Port forward : avec Interface = Wan + External address = Interface Address
    • une règle "rule" : Firewall > Rules > onglet WAN

    Dans pfSense 2.x, les définitions sont synchronisées.

    Donc, les deux règles sont bien créés ?

    @jdh:

    • l'écriture de la règle "port forward" n'a aucun sens.


    Et, un, vous écrirez un autre "port forward", deux, vous ferez d'autres tests, et cela fonctionnera.

    Alors, je dois la créer cette règle ou pas ??

    J'essaye de vous faire voir ce qui pour moi est très confus.

    Edit :

    Je te remercie de passer du temps à faire comprendre à un neuneu ce qui est apparemment très simple…



  • J'ai écrit ceci :

    La première image est celle du "port forward" (Firewall > Nat > onglet "port forward") en v2.

    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 !

    (Pour être encore plus précis, j'aurais du écrire "adresses privées et internes" !)

    Puis, comme je lis une nouvelle règle "port forward" toujours incorrecte, pour la même raison, alors j'écris

    l'écriture de la règle "port forward" n'a aucun sens.

    D'ailleurs, c'est exactement toujours la même raison pour laquelle les tests n'ont AUCUN SENS !

    Maintenant, on enlève ses mains du clavier, et on cherche POURQUOI j'écris cela.

    Le reste sera enfantin ! Mais il FAUT comprendre pourquoi !
    Et ce n'est pas la peine d'aller plus loin …



  • @jdh:

    Puis, comme je lis une nouvelle règle "port forward" toujours incorrecte, pour la même raison, alors j'écris
    l'écriture de la règle "port forward" n'a aucun sens.

    Ok elle doit être associé à une rule c'est ce que tu me dit depuis le début ??

    @jdh:

    Puis, comme je lis une nouvelle règle "port forward" toujours incorrecte, pour la même raison, alors j'écris

    Jusqu'à présent, j'ai toujours effectué mes règles de cette manière sur n'importe quelle routeurs. De mémoire même lors des cours avec le profs ont effectuaient le pat/nat de cette manière. J'ai demandé à un ami qui a eu son bac en mrim sans avoir de réponses concluantes. Avec pfsense 1.2.3 il en est était de même.

    @jdh:

    Maintenant, on enlève ses mains du clavier, et on cherche POURQUOI j'écris cela.

    Je suis débutant et effectivement, après avoir lu et relut le nat sur wikipedia, il y a toujours quelques choses qui m'échappent.
    Donc je suis d'accord avec toi qu'une réponse ne vient jamais tout cuit dans le bec et qu'il faut un temps de recherche (je pense qu'il est dépassé :D), mais si déjà je connais quelques informations qui paraissent alors erronés, je suis bien dans le pétrin.

    Il me reste ces solutions envisageables :

    • Repasser à pfsense 1.2.3 et mourir idiot
    • Demander de l'aide et avoir une réponse
    • Chercher pourquoi depuis le début et ne rien demander à personne.
    • Je suis trop neuneu, et j'espère réussir mes études en tant que technicien de surface…

    Ou alors, ce que je recherche n'est pas le nat, mais le pat.

    Sinon, ma rules ne me parrait pas erroné (mise à par le CIDR que je ne peut pas modifier) :

    Edit : Ou alors, il n'y à rien à faire dans le port forward, et tout ce passe dans les rules

    Edit 2 : Même après avoir relut des tutos je ne trouve pas l'erreur



  • 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 :

    http://www.google.fr/url?sa=t&source=web&cd=6&ved=0CDQQFjAF&url=http%3A%2F%2Fwww.math-info.univ-paris5.fr%2F~le-t%2FCoursHTML1%2FCOURS%2FTheorie%2520Reseau%2FAutresSupports%2FLe%2520routeur%2520NAT.pdf&rct=j&q=quel%20est%20la%20destination%20%C3%A0%20indiquer%20dans%20un%20port%20forwarding&ei=EXR1TMiZFpDN4AbHm-SXBg&usg=AFQjCNGnZhiGBslGgNUbb-yN5fQQYTg2Ag&cad=rja

    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.  ;)


Log in to reply