[NAT] Ports "vérouillés".



  • Bonjour / Bonsoir,

    Mes observations ont été effectuées avec la topologie suivante :

    Box (192.168.1.1 /24) –----------------------------- (192.168.1.200 /24) Pfsense (172.16.0.1 /24) ------ (172.16.0.254 /24) switch 3560 (172.16.1.1 /24) ----- (172.16.1.92 /24) PC A.
    |
    |
    WS2012 (DHCP) (192.168.1.254 / 24)


    Je précise que mon 3560 effectue le relais dhcp vers 192.168.1.254.


    Lorsque le NAT est configuré de la façon suivante le dhcp (192.168.1.254) voit arriver les DHCP DISCOVER du PC A et y répond, mais les DHCP OFFER n'arrivent jamais plus loin que l'interface wan du pfsense.

    (pièce jointe : NAT basique)

    Lorsque le NAT est désactivé (voir configuration en dessous), le PC A peut communiquer sans difficulté avec le serveur dhcp (192.168.1.254).

    (pièce jointe : NAT désactivé)

    –-

    J'ai donc effectué de multiples tests / captures de paquets pour essayer de déterminer l'origine du problème et je suis arrivé au constat suivant :
    Si le pc A envoie un paquet / datagramme avec comme port source X1, que ce paquet est "Naté" par le pfsense et qu'une machine envoie un datagramme au pc A sur le port X1 (en indiquant donc l'ip du pc A et pas celle du pfsense comme adresse de destination), ce paquet / datagramme sera bloqué par le pfsense.

    Exemple :

    PC A envoie un datagramme UDP : port source 55000 port destination 35, ip source 172.16.1.92 ip destination 192.168.1.254.
    PFSENSE transforme le datagramme en : port source 34000 port destination 35 ip source 192.168.1.200 ip destination 192.168.1.254.
    192.168.1.254 (par exemple) reçoit le paquet / datagramme et renvoie le datagramme suivant : port source : x, port destination : 55000, ip source : 192.168.1.254, ip destination : 172.16.1.92.
    PFSENSE voit le paquet / datagramme arriver sur sa carte réseau 192.168.1.200 mais le "drop"  :o.

    (Normalement 192.168.1.254 devrait indiquer comme ip de destination 192.168.1.200 (pfsense) puisque ce dernier à "Naté" la requête mais le service dhcp windows ne fonctionne pas comme ça).


    Je vous pose donc la question suivante : Est il possible de faire en sorte que pfsense laisse passer les paquets / datagrammes à destination d'un port X1 sur le PC A même si le pfsense a "Naté" des requêtes provenant du port X1 du PC A ?

    Merci d'avance !  :)






  • Je ne comprend pas votre schema. Sur quel interface de pfsense est connecté le serveur dhcp (windows serveur 2012) ?
    Et surtout j'aimerai comprendre votre besoin fonctionnel. Vous decrivez une solution (dont je ne suis pas certain qu'elle en soit une) qui ne vous donne pas satisfaction techniquement, mais pas le besoin fonctionnel. Commençons par le début.



  • Bonjour,

    le serveur dhcp - Windows serveur 2012 - est connecté sur un port de ma box, le pfsense est connecté sur un autre port de ma box (les | et les –-- de mon schéma représentent les câbles entre mes équipements).

    Mon besoin est de comprendre pourquoi le pfsense bloque "sans raison" les paquets à destination d'un port X du PC A si le pfsense à "NATé" des requêtes provenant de ce même port X du PC A.

    Merci d'avance pour vos réponses



  • (172.16.0.254 /24) switch 3560 (172.16.1.1 /24)

    Je ne comprend toujours pas ce qui précède. A ma connaissance le 3560 n'est pas un switch niveau 3.

    Exemple :

    PC A envoie un datagramme UDP : port source 55000 port destination 35, ip source 172.16.1.92 ip destination 192.168.1.254.
    PFSENSE transforme le datagramme en : port source 34000 port destination 35 ip source 192.168.1.200 ip destination 192.168.1.254.
    192.168.1.254 (par exemple) reçoit le paquet / datagramme et renvoie le datagramme suivant : port source : x, port destination : 55000, ip source : 192.168.1.254, ip destination : 172.16.1.92.
    PFSENSE voit le paquet / datagramme arriver sur sa carte réseau 192.168.1.200 mais le "drop"

    On laisse de côté le cas de dhcp, mais vu le port indiqué c'est la cas. Ce test suppose que 192.168.1.200 est l'interface wan de Pfsense et que PC A est connecté à une interface Lan ou Opt. Si c'est bien le cas et si les bonnes règles sont aux bon endroits, cela devrait fonctionner.



  • Le switch catalyst 3560-C de chez cisco est bien un switch de niveau 3.

    192.168.1.200 est bien l'interface WAN de pfsense et le PC A est bien connecté (à travers le switch) à une interface LAN de pfsense.

    Le problème est vraiment lié à la non transmission par pfsense des paquets provenant du réseau de la box destinés au port X1 du PC A de son interface WAN à son interface LAN si le pfsense à "NATé" une requête provenant du port X1 du PC A.



  • Comment avez vous traité le routage ? L'adresse du Pc appartient à un réseau qui n'est pas connu de Pfsense. A moins que vous fassiez autre chose que du routage ?



  • Bonsoir,

    Je me suis peut être mal exprimé dans mes messages précédents, le problème n'est à priori pas un problème de routage puisque dans des conditions "normales" chacun de mes appareils peut communiquer (ping) avec n'importe quelle autre machine (j'ai effectivement crée plusieurs routes statiques sur mes appareils de niveau 3).

    Mon problème - à mon avis - est du à ma mauvaise connaissance des options de pfsense ou alors c'est un comportement voulu par les développeurs.

    Je vais tenter d'expliquer clairement la situation avec deux exemples :

    Exemple 1 : Le cas ou ça marche normalement.

    1. PC "A" envoie un paquet |port source=67;port destination = 67; ip source=172.16.1.92; ip destination = 192.168.1.254|
    2. Le paquet arrive sur l'interface LAN de pfsense (172.16.0.1).
    3. Pfsense transforme le paquet en : |port source=32000;port destination = 67; ip source=192.168.1.200; ip destination = 192.168.1.254|
    4. Pfsense fait suivre le paquet sur ton interface WAN.
    5. WS2012 reçoit le paquet et forge un paquet de réponse : |port source=67;port destination = 32000; ip source=192.168.1.254; ip destination = 192.168.1.200|
    6. Le paquet arrive sur l'interface WAN de pfsense.
    7. Pfsense se souvient qu'il avait 'NATé' la requête de PC "A" et retransmet au PC "A" le paquet suivant : |port source=67;port destination = 67; ip source=192.168.1.254; ip destination = 172.16.0.92|
      8. PC "A" reçoit les données et tout le monde est content.

    Exemple 2 : Le cas ou ça marche pas comme je pense que ça le devrait.

    1. PC "A" envoie un paquet |port source=67;port destination = 67; ip source=172.16.1.92; ip destination = 192.168.1.254|
    2. Le paquet arrive sur l'interface LAN de pfsense (172.16.0.1).
    3. Pfsense transforme le paquet en : |port source=32000;port destination = 67; ip source=192.168.1.200; ip destination = 192.168.1.254|
    4. Pfsense fait suivre le paquet sur ton interface WAN.
    5. WS2012 reçoit le paquet et forge un paquet de réponse : |port source=67;port destination = 67; ip source=192.168.1.254; ip destination = 172.16.0.92|
    6. Le paquet arrive sur l'interface WAN de pfsense.
    7. Pfsense drop le paquet.

    J'ai pu vérifier ce comportement sur d'autres ports : Aucune machine du réseau de la box ne peut envoyer sur le côté de LAN du pfsense un paquet qui contiendrait comme ip de destination l'ip du PC "A" si le port de destination fait l'objet d'une correspondance NAT/PAT dans le pfsense (port 67 pour l'exemple du dessus).

    Merci d'avance  :)



  • Jusqu'au point 5 tout est identique ou bien entre les deux tests un élément de configuration change ?
    DHCP dans une configuration routée n'est pas sans problème avec les brodcasts. On a du mal à démêler le spécifique (d'ACP) du général dans votre problème .



  • Bonsoir,

    J'utilise la fonction relai DHCP de mon 3560 mais le problème n'est pas là vu que ce "comportement" se produit quel que soit le port utilisé (d'autant plus que si je désactive le "NAT" l'échange DHCP se produit sans soucis).
    Je cite ici mon constat avec mon serveur DHCP pour "expliciter" le problème mais ce dernier n'est assurément pas lié au protocole DHCP en lui même.

    Jusqu'au point 5 les deux tests sont identiques.

    Merci d'avance  :)



  • Jusqu'au point 5 les deux tests sont identiques.

    Quel élément provoque des résultats de test différents ? La configuration de nat outbound ?
    Si c'est le cas il faut comprendre qie par défaut et construction de Pfsense il n'est utile pratiquement pour les machines qui sont à l'origine d'une connexion sortante ET qui doivent utiliser une ip autre que celle de wan. Tous les flux de Lan ou opt x qui quitte Pfsense par wan sont translatés avec l'ip wan automatiquement. Entre les autres interfaces ils sont routés.



  • Quel élément provoque des résultats de test différents ? La configuration de nat outbound ?

    Non, dans chacun de mes tests* la configuration de NAT outbound est la même, ce qui provoque des résultats différents c'est l'IP à laquelle WS2012 décide de répondre.

    *Tests du post "Reply #6 on: September 13, 2014, 12:18:29 pm"



  • Ce fil est difficile à comprendre.

    Un serveur DHCP serait situé entre le routeur (box) du FAI et le WAN de pfSense, et serait serveur DHCP pour des réseaux internes au firewall pfSense.
    C'est assez incompréhensible !
    Autant il est aisé de placer un serveur DHCP principal dans le LAN et des serveurs DHCP relay dans des réseaux routés au LAN.

    La zone WAN est normalement une zone réduite au routeur et à l'interface WAN : une machine placée dans cette zone n'est pas protégée !



  • @jdh:

    Ce fil est difficile à comprendre.

    A qui le dis tu !!

    Depuis le début j'essaye de faire abstraction d'une infrastructure réseau complètement aberrante et de comprendre le problème. Je crois ne pas encore y être parvenu.



  • @Détail:

    Quel élément provoque des résultats de test différents ? La configuration de nat outbound ?

    Non, dans chacun de mes tests* la configuration de NAT outbound est la même, ce qui provoque des résultats différents c'est l'IP à laquelle WS2012 décide de répondre.

    *Tests du post "Reply #6 on: September 13, 2014, 12:18:29 pm"

    Et qu'est ce qui fait que WS2012 "décide" de répondre à une adresse différente ?
    Si je regarde les informations données, dans les deux cas c'est la même machine source (PC A). Je fini par me dire que Pfsense n'a rien à voir dans cette histoire, dans cette galère.

    Reprenons:
    le cas où cela fonctionne

    1. WS2012 reçoit le paquet et forge un paquet de réponse : |port source=67;port destination = 32000; ip source=192.168.1.254; ip destination = 192.168.1.200|

    Le cas où cela ne fonctionne pas

    1. WS2012 reçoit le paquet et forge un paquet de réponse : |port source=67;port destination = 67; ip source=192.168.1.254; ip destination = 172.16.0.92|

    Le port destination en sortie de ws2012 est différent. Pourquoi et que vient faire Pfsense ici ?
    Vous nous dites que cela ne dépend pas du protocole, que dhcp ou pas cela ne change rien à l'affaire. En sommes nous bien certain ?



  • Salut salut

    @ all

    j'avoue que moi aussi j'en perds mon latin a lire le fil du post, j'ai décroché au début.

    @detail

    Pouvez vous reprendre ou faire un resumé étapes par étape point par point avec de vrai schéma s'il vous plait, j'ai defois du mal (c'est peut de le dire defois) pour comprendre les problématiques sans ces derniers car la plus part du temps ils me permettent de cibler plus facilement la sources ou la cause.
    en reprenant le model du topic en haut de section s il vous plait.

    Cordialement.



  • Bonsoir,

    Désolé de cette réponse tardive, je vais essayer de détailler ceci au mieux au cours du week end.



  • Bonsoir à tous,

    J'espère que ce message sera assez clair pour que vous puissiez cerner le problème.

    –-

    Topologie du réseau lors des tests

    Configuration initiale des différents équipements

    • Mise en place d'un relais DHCP sur le switch 3560 pour transmettre en unicast au Windows serveur 2012 les requêtes émises par le PC A.
    • Le pfSense NAT automatiquement.

    Problème rencontré

    • Le PC n'obtient aucune réponse "DHCP OFFER" malgré les nombreuses requêtes "DHCP DISCOVER".

    Constat général issu des premiers tests effectués

    • Les requêtes "DHCP DISCOVER" arrivent bien au Windows serveur.
    • Les réponses "DHCP OFFER" du Windows serveur arrivent bien jusqu'à l'interface WAN (192.168.1.200) du pfSense mais ne vont pas plus loin.

    Analyse des trames échangées au niveau des couches 3 et 4

    • Les requêtes "DHCP DISCOVER" reçues par le Windows Serveur sont construites de la façon suivante :
      IP source : WAN pfSense
      IP destination : 192.168.1.254
      Port source : port aléatoire.
      Port destination : 67.

    • Les réponses "DHCP OFFER" reçues au niveau de l'interface WAN pfSense sont construites de la façon suivante :
      IP source : 192.168.1.254
      IP destination : 172.16.1.1
      Port source : 67.
      Port destination : 67.

    Première observation

    Le serveur DHCP utilise les informations contenues dans la donnée couche 7 pour savoir à qui adresser sa réponse "DHCP OFFER" (puisqu'il répond directement au switch 3560 et non au pfSense).

    Première hypothèse

    Peut être que pfSense ne laisse pas passer le "DHCP OFFER" à cause d'un problème de NAT.

    Changement effectué sur le pfSense

    • Règle "NO-NAT" si le paquet à pour port source "67" (donc les paquets relayés par mon 3560 via sa fonction de relais DHCP).

    Constat lié à ce changement

    PC A obtient une IP, la communication DHCP s'effectue sans soucis entre mon Windows serveur et PC A.

    Conclusion de ces premiers tests

    • Si le NAT est inactif, les "DHCP OFFER" arrivent au PC A.
    • Si le NAT est actif, les "DHCP OFFER" n'arrivent pas au PC A.

    Hypothèse

    Peut être que lorsque le pfSense "NAT/PAT", il fait en sorte que le port source du paquet "PATé" (côté LAN) ne soit pas joignable autrement que par un paquet correspondant au port "PATé" (côté WAN).

    Exemple pour clarifier la phrase du dessus :

    Si 172.16.1.1 construit le paquet suivant :
    IP source = 172.16.1.1
    IP destination = 192.168.1.254
    Port source = 67
    Port destination = 67

    Et que le pfSense transforme le paquet lors de la phase de NAT/PAT en :
    IP source = 192.168.1.200
    IP destination = 192.168.1.254
    Port source = 34000
    Port destination = 67

    Alors LA SEULE FAÇON pour qu'un paquet provenant du réseau 192.168.1.0 /24 soit transmis à 172.16.1.1:67 est de l'envoyer à 192.168.1.200:34000. Si le paquet est transmis à 172.16.1.1:67 directement il sera bloqué par le pfSense.

    Tests effectués pour vérifier l'hypothèse

    J'ai installé un client UDP sur le PC A, un serveur UDP sur une machine du réseau 192.168.1.0 /24 (non présente sur le schéma de ma topologie) et j'ai effectué les tests suivants (NAT activé au niveau du pfSense).

    Envoi d'un paquet construit de la façon suivante par le PC A :
    IP source = 172.16.1.92
    IP destination = 192.168.1.50
    Port Source = 150
    Port destination = 9050

    Le pfSense va donc transformer le paquet lors de la phase de NAT/PAT en :
    IP source = 192.168.1.200
    IP destination = 192.168.1.50
    Port Source = 35000 (exemple)
    Port destination = 9050

    J'ai alors testé les 3 cas suivants

    Si la machine 192.168.1.50 forge un paquet ayant pour destination : 192.168.1.200:35000, alors le PC A (172.16.1.92) recevra le paquet sur sa carte réseau.
    Si la machine 192.168.1.50 forge un paquet ayant pour destination : 172.16.1.92:[!150], alors le PC A (172.16.1.92) recevra le paquet sur sa carte réseau.
    Si la machine 192.168.1.50 forge un paquet ayant pour destination : 172.16.1.92:150, alors le paquet sera bloqué par le pfSense.

    J'espère que ces exemples vous auront permis de bien cerner le problème.

    Ma question est donc la suivante

    Est il normal que pfSense "verrouille les ports NAT/PATés" de la sorte ?

    Merci d'avance !



  • Salut salut

    Question :

    Le pourquoi du serveur en direct sur la box (peu importe le point de sortie) et pas derrière le pf ce qui serait à mon sens plus logique ?
    Sauf si vous ayez autres choses d'implantés sur le segment de box, je n'en vois pas l'utilité, de plus je trouve cela dangereux.

    Faire simple évite des erreurs.
    Faire compliquer c'est se rajouter des problèmes.
    Surtout si l'on me maitrise pas tous les concepts.

    Cordialement.



  • J'ignore si un routeur faisant du NAT est autorisé ou possible entre un serveur DHCP et un serveur DHCP relay.
    Je présume que ce n'est pas possible !

    Je répète, normalement, il ne devrait rien y avoir entre une Box et le WAN d'un firewall.

    Je ne suis pas sûr de l'intérêt de ce test : je suis sûr que le DHCP serveur en LAN fonctionnerait !



  • En cherchant G/DHCP Relay NAT, on voit que le problème est largement connu et semble insoluble

    p.e. http://ccielab.ro/2010/08/dhcp-relay-server-and-nat-case-study/

    Et comme c'est générique, pfSense (comme firewall = routeur + NAT) ne risque pas de faire exception …



    • Les requêtes "DHCP DISCOVER" reçues par le Windows Serveur sont construites de la façon suivante :
      IP source : WAN pfSense

    Ce paquet dhcp discover n'est pas correct. L'ip source doit être 0.0.0.0 sauf si c'est un proxy (relai dhcp) qui transmet la requête ce qui n'est pas le cas de Pfsense. Je n'aurai pas dû vous croire lorsque vous avez assuré que dhcp n'est pas en cause. Je pense aussi que c'est sans solution.



  • Après avoir parcouru la RFC2131 (qui traite DHCP), je ne pense pas aisé de faire fonctionner un schéma tel celui choisi.
    (Ce ne doit pas être impossible mais cela nécessite des choses difficile à fournir !)

    Non seulement vous laissez une machine entre Box et WAN, et vous voudriez qu'elle apporte un rôle qui pourrait parfaitement fonctionner simplement s'il était placé ailleurs !
    Cela fait trop d'erreurs .. et 10 jours de fil !

    Pour moi c'est STOP.



  • Bonjour à tous,

    Le pourquoi du serveur en direct sur la box (peu importe le point de sortie) et pas derrière le pf ce qui serait à mon sens plus logique ?
    Sauf si vous ayez autres choses d'implantés sur le segment de box, je n'en vois pas l'utilité, de plus je trouve cela dangereux.

    Faire simple évite des erreurs.
    Faire compliquer c'est se rajouter des problèmes.
    Surtout si l'on me maitrise pas tous les concepts.

    La topologie présentée n'est pas celle que j'utilise mais c'est dans cette configuration que j'ai rencontré le problème.
    J'ai pensé qu'il serait intéressant d'en comprendre la cause.

    Ce paquet dhcp discover n'est pas correct. L'ip source doit être 0.0.0.0 sauf si c'est un proxy (relai dhcp) qui transmet la requête ce qui n'est pas le cas de Pfsense.

    L'IP source est l'IP WAN de pfsense puisqu'il NAT la requête.

    Je n'aurai pas dû vous croire lorsque vous avez assuré que dhcp n'est pas en cause

    Pourtant ce problème se produit avec n'importe quel protocole (au moins ceux basés sur UDP) - indépendamment de DHCP et du port 67 (voir la fin de mon message précédent :  Tests effectués pour vérifier l'hypothèse).
    J'ai découvert ce problème avec DHCP mais les tests décrits à la fin de mon message précédent montrent bien que le protocole DHCP et ses ports associés n'ont rien de spécifique là dedans.

    Non seulement vous laissez une machine entre Box et WAN, et vous voudriez qu'elle apporte un rôle qui pourrait parfaitement fonctionner simplement s'il était placé ailleurs !

    Je ne cherche pas à "faire fonctionner en conditions réelles" la topologie présentée ici, je pense juste qu'il est intéressant de comprendre "pourquoi ça ne marche pas".



  • (Je fais rarement du DHCP relay, mais je l'ai fait.)

    DHCP relay fonctione sur réseaux routés "standard".
    Donc on peut essayer avec du NAT.
    Mais face au non-fonctionnement, il y a lieu de chercher pourquoi.
    On trouve aisément plusieurs liens qui montre que c'est difficile, on peut lire la RFC qui donne des précisions utiles.
    Il faut retenir que DHCP + NAT n'est absolument pas une bonne idée.
    On n'est pas obligé d'y passer 10 jours …
    On peut quand même éviter la situation scabreuse d'une machine entre Box et WAN ...



  • salut salut

    @all

    je rejoins jdh sur son expertise. Cela est une vrai fausse bonne idée d'avoir un serveur entre la box et le pare-feu sauf si seulement on veut s'en servir de mine et de faille de sécurité pour soit même et mettre un gros panneau à de vrai vilains " ici c'est bon pour faire des grosses bétises c'est moi qui aurais des soucis pas vous avec la justice entre autre…"

    @détail

    faire simple = faire éfficace
    faire compliqué = avoir des soucis et plus encore perdre du temps pour rien donc perte d'argents (aie c'est un coup bas)

    Cordialement.



  • Bonsoir,

    Merci pour vos réponses  :)

    @détail

    faire simple = faire éfficace
    faire compliqué = avoir des soucis et plus encore perdre du temps pour rien donc perte d'argents (aie c'est un coup bas)

    Je suis bien d'accord là dessus, c'est juste que je cherche à comprendre le "pourquoi ça ne marche pas dans telle configuration".

    Il faut retenir que DHCP + NAT n'est absolument pas une bonne idée.

    Certainement (du moins DHCP + NAT pfSense, je n'ai pas testé avec une autre solution), mais le problème va bien plus loin que DHCP (voir "Tests effectués pour vérifier l'hypothèse"), DHCP est seulement le premier qui a mis en évidence le problème.



  • Salut salut

    Je comprends votre démarche, avoir trouvé une solution fonctionnelle,c'est le but du forum.
    Je ne suis pas sur que vous trouvez plus d'aide dans le sens de votre recherche, car vous avez eu une solution et que vous l'avez mise en place.

    Personnellement je ne suis pas sur que cela vienne expressément de pf, qui s'appuie un os revu et corrigé pour en faire un appliance (si je ne trompe pas sur le terme)
    Après, nous vous avons fait des recommandations sur la structure de votre réseau en prenant en compte les aspects technique de pf, et de vos actifs sité, suivez les.
    Comme je vous les ai dit, vous ouvrez la boite de Pendor avec les risques qui en découle.

    Je trouve aussi que le temps mis sur ce fil pour une problématique simple, a assez durée et pour ma part je ne répondrais plus.

    Cordialement.


Log in to reply