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

ccnet

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

Détail

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.

ccnet

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 ?

Détail

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.

PC "A" envoie un paquet |port source=67;port destination = 67; ip source=172.16.1.92; ip destination = 192.168.1.254|
Le paquet arrive sur l'interface LAN de pfsense (172.16.0.1).
Pfsense transforme le paquet en : |port source=32000;port destination = 67; ip source=192.168.1.200; ip destination = 192.168.1.254|
Pfsense fait suivre le paquet sur ton interface WAN.
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 paquet arrive sur l'interface WAN de pfsense.
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.

PC "A" envoie un paquet |port source=67;port destination = 67; ip source=172.16.1.92; ip destination = 192.168.1.254|
Le paquet arrive sur l'interface LAN de pfsense (172.16.0.1).
Pfsense transforme le paquet en : |port source=32000;port destination = 67; ip source=192.168.1.200; ip destination = 192.168.1.254|
Pfsense fait suivre le paquet sur ton interface WAN.
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 paquet arrive sur l'interface WAN de pfsense.
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 :)

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