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

ccnet

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 .

Détail

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

ccnet

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.

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"

jdh

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 !

ccnet

@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.

ccnet

@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

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

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 ?

Tatave

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.

Détail

Bonsoir,

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

Détail

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 !

Tatave

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.

jdh

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 !

jdh

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 …

ccnet

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.

jdh

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.

Détail

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".

jdh

(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 ...

Tatave

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.

Détail

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.

Tatave

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.