[pfSense] Troubleshooting / Dépannage de ses règles de NAT
30/06/2020
La gestion du NAT peut parfois poser problème.
Dans cet article, nous traitons des problèmes les plus fréquemment rencontrés avec la gestion du NAT sous pfSense.
Il existe principalement 3 types de NAT (Network Address Translation) sous pfSense :
Pour approfondir le fonctionnement du NAT sous pfSense, vous pouvez consulter notre article dédié [pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense.
Avant toute autre analyse, il est important de vérifier que la règle de redirection de port soit correctement configurée.
Il faut vérifier notamment les éléments suivants :
Enfin, il faut également avoir en tête que le filtrage s'effectue après la règle de redirection de port. Ainsi, si l'on n'a pas choisi la création automatique d'une règle de filtrage (Add associated filter rule), il faut créer une règle avec la bonne adresse IP de destination, c'est-à-dire l'adresse IP locale du serveur cible.
Il s'agit d'une erreur couramment rencontrée.
Il faut créer la règle de filtrage sur l'interface d'arrivée du paquet réseau (soit l'interface WAN dans le cas d'une redirection de port depuis Internet vers le réseau local) et il faut garder en tête que la translation d'adresse à déjà eu lieu et que c'est donc avec l'adresse IP de destination translatée (l'adresse IP finale) et le port de destination translaté (le port final) qu'il faut configurer la règle de filtrage.
Un autre point à prendre en considération : la redirection de trafic peut être correctement effectuée par pfSense, mais le serveur cible peut avoir un pare-feu local d'installé qui bloque le trafic. Il convient donc de vérifier ce point également.
Il faut s'assurer que le serveur cible soit bien en écoute sur le port de destination.
S'il s'agit d'un port TCP, on peut utiliser l'outil de test intégré à pfSense et accessible depuis le menu Diagnostics > Test Port :
En cas de connexion réussie :
En cas d'échec :
Si pfSense n'est pas la passerelle par défaut du serveur cible, alors les paquets ne seront pas routés correctement. Il y a deux solutions par rapport à ce problème :
Si vous souhaitez implémenter une règle de NAT sortant, dans le cas d'une redirection de port depuis Internet vers le réseau local, la configuration à réaliser serait la suivante :
Il faudra également passer le mode d'Outbound NAT d'Automatic vers Hybrid (ou Manual).
Exemple de configuration obtenue :
Il s'agit ici d'une erreur très courante lorsque l'on souhaite tester une configuration de redirection de port : faire les tests depuis le réseau local lui-même.
Par défaut, la redirection de port ne fonctionnera que pour les connexions provenant de l'extérieur du réseau.
Si après tous ces tests et toutes ces vérifications, la redirection de ports ne fonctionne toujours pas, vous pouvez relire nos articles [pfSense] Comprendre et analyser ses règles de routage et [pfSense] Troubleshooting / Dépannage de ses règles de filtrage.
La démarche a suivre sera très similaire à celle détaillée précédemment pour les règles de redirection de port.
Le premier élément à avoir en tête est que les règles d'Outbound NAT se configurent sur l'interface de sortie du firewall. Tandis que pour les règles de redirection de port, c'est l'inverse : elles se configurent sur l'interface d'arrivée du firewall.
Le deuxième élément est qu'il est nécessaire de configurer autant de règles de NAT sortant qu'il y a de réseaux locaux.
Une bonne indication démontrant qu'il existe un problème de NAT sortant sera de voir des paquets quitter pfSense avec une adresse IP source en dehors du sous-réseau de l'interface ; par exemple, voir des paquets réseaux avec une adresse IP source du LAN sur l'interface WAN de pfSense indique qu'il y a une anomalie de NAT. Ces éléments se voient aisément à l'aide de l'outil "Packet Capture" accessible depuis le menu Diagnostics > Packet Capture :
L'utilisation de l'outil "Packet Capture" fera l'objet d'un article dédié.
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Comprendre et analyser ses règles de routage
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.
Dans cet article, nous traitons des problèmes les plus fréquemment rencontrés avec la gestion du NAT sous pfSense.
La gestion du NAT sous pfSense (généralités)
Il existe principalement 3 types de NAT (Network Address Translation) sous pfSense :
- Port forward : pour la gestion de la redirection de port par adresse IP ; on parle de D-NAT (Destination NAT), c'est-à-dire une modification de l’adresse IP de destination.
- 1:1 NAT : NAT un-pour-un pour la redirection de tout le trafic d'une adresse IP vers une autre ; on parle également de D-NAT (Destination NAT), c'est-à-dire une modification de l’adresse IP de destination.
- Outbound : les règles de NAT pour le trafic sortant ; dans ce cas, on part de S-NAT (Source NAT), c'est-à-dire une modification de l'adresse IP source.
Pour approfondir le fonctionnement du NAT sous pfSense, vous pouvez consulter notre article dédié [pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense.
Problèmes de port forward (redirection de port)
Règle de redirection de port incorrecte
Avant toute autre analyse, il est important de vérifier que la règle de redirection de port soit correctement configurée.
Il faut vérifier notamment les éléments suivants :
- Interface : s'assurer que ce soit la bonne : celle sur laquelle les paquets réseaux arrivent ; il s'agit de l'interface d'entrée, soit le WAN pour une redirection de port depuis Internet vers le réseau local par exemple.
- Protocol : TCP, UDP, ICMP, ... ; si vous avez un doute entre TCP et UDP, choisir "TCP/UDP".
- Source : il est très rare de devoir la préciser ; elle devrait être laissée à sa valeur par défaut, c'est-à-dire "*" ou "any".
- Dest. Address : il s'agit de l'adresse de destination recevant les paquets devant être translatés ; cette adresse IP est portée par le pfSense. Dans le cas d'une redirection de port depuis Internet vers le réseau local, il s'agit donc de l'adresse IP côté WAN.
- Dest. Ports : le port ou la plage de ports de destination recevant les paquets devant être translatés ; il s'agit donc bien du port d'écoute sur le pfSense, pas du port de destination sur le serveur cible (qui peuvent être similaires ou différents).
- NAT IP : l'adresse IP translatée ; c'est-à-dire l'adresse IP de destination finale vers laquelle le trafic doit être redirigé par pfSense. Dans le cas d'une redirection de port depuis Internet vers le réseau local, il s'agira donc de l'adresse IP locale du serveur cible.
- NAT Ports : le port ou la plage de ports de destination finale recevant les paquets ; il s'agit donc bien du port d'écoute du serveur cible final, pas du port d'écoute du pfSense (ils peuvent être similaires ou différents).
Enfin, il faut également avoir en tête que le filtrage s'effectue après la règle de redirection de port. Ainsi, si l'on n'a pas choisi la création automatique d'une règle de filtrage (Add associated filter rule), il faut créer une règle avec la bonne adresse IP de destination, c'est-à-dire l'adresse IP locale du serveur cible.
Règle de filtrage incorrecte ou manquante
Il s'agit d'une erreur couramment rencontrée.
Il faut créer la règle de filtrage sur l'interface d'arrivée du paquet réseau (soit l'interface WAN dans le cas d'une redirection de port depuis Internet vers le réseau local) et il faut garder en tête que la translation d'adresse à déjà eu lieu et que c'est donc avec l'adresse IP de destination translatée (l'adresse IP finale) et le port de destination translaté (le port final) qu'il faut configurer la règle de filtrage.
Un pare-feu est présent sur le serveur cible
Un autre point à prendre en considération : la redirection de trafic peut être correctement effectuée par pfSense, mais le serveur cible peut avoir un pare-feu local d'installé qui bloque le trafic. Il convient donc de vérifier ce point également.
Le service sur le serveur cible n'est pas en écoute sur le bon port réseau
Il faut s'assurer que le serveur cible soit bien en écoute sur le port de destination.
S'il s'agit d'un port TCP, on peut utiliser l'outil de test intégré à pfSense et accessible depuis le menu Diagnostics > Test Port :
En cas de connexion réussie :
Connexion TCP réussie
En cas d'échec :
Connexion TCP échouée
pfSense n'est pas la passerelle par défaut du serveur cible
Si pfSense n'est pas la passerelle par défaut du serveur cible, alors les paquets ne seront pas routés correctement. Il y a deux solutions par rapport à ce problème :
- définir pfSense comme passerelle par défaut sur le serveur cible ;
- configurer une règle d'Outbound NAT (NAT sortant) afin que l'adresse IP source du trafic reçue par le serveur cible soit l'adresse IP du pfSense ; cette solution peut poser des problèmes d'affinité de session côté serveur, elle est donc à manier avec prudence.
Si vous souhaitez implémenter une règle de NAT sortant, dans le cas d'une redirection de port depuis Internet vers le réseau local, la configuration à réaliser serait la suivante :
- Interface : votre interface locale sur laquelle est rattachée le serveur cible (LAN, DMZ, OPT, ...) ;
- Protocol : TCP, UDP, ICMP, ... ; si vous avez un doute entre TCP et UDP, choisir "TCP/UDP" ;
- Source : dans notre cas pris en exemple, choisir any ;
- Destination : choisir "Network" et indiquer l'adresse IP du serveur cible ; indiquer "32" pour le champ masque afin de ne cibler que le trafic à destination de ce serveur et, enfin, préciser le port réseau de destination sur lequel le serveur est en écoute.
Il faudra également passer le mode d'Outbound NAT d'Automatic vers Hybrid (ou Manual).
Exemple de configuration obtenue :
Exemple de règle d'Outbound NAT pour un serveur cible n'ayant pas pfSense comme passerelle par défaut
Tester depuis le réseau local directement au lieu de le faire depuis l'extérieur
Il s'agit ici d'une erreur très courante lorsque l'on souhaite tester une configuration de redirection de port : faire les tests depuis le réseau local lui-même.
Par défaut, la redirection de port ne fonctionnera que pour les connexions provenant de l'extérieur du réseau.
Si après tous ces tests et toutes ces vérifications, la redirection de ports ne fonctionne toujours pas, vous pouvez relire nos articles [pfSense] Comprendre et analyser ses règles de routage et [pfSense] Troubleshooting / Dépannage de ses règles de filtrage.
Problèmes d'Outbound NAT (NAT sortant)
La démarche a suivre sera très similaire à celle détaillée précédemment pour les règles de redirection de port.
Le premier élément à avoir en tête est que les règles d'Outbound NAT se configurent sur l'interface de sortie du firewall. Tandis que pour les règles de redirection de port, c'est l'inverse : elles se configurent sur l'interface d'arrivée du firewall.
Le deuxième élément est qu'il est nécessaire de configurer autant de règles de NAT sortant qu'il y a de réseaux locaux.
Une bonne indication démontrant qu'il existe un problème de NAT sortant sera de voir des paquets quitter pfSense avec une adresse IP source en dehors du sous-réseau de l'interface ; par exemple, voir des paquets réseaux avec une adresse IP source du LAN sur l'interface WAN de pfSense indique qu'il y a une anomalie de NAT. Ces éléments se voient aisément à l'aide de l'outil "Packet Capture" accessible depuis le menu Diagnostics > Packet Capture :
L'utilisation de l'outil "Packet Capture" fera l'objet d'un article dédié.
Pour aller plus loin
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Comprendre et analyser ses règles de routage
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense & OPNsense
2 commentaires
Ahmat - 06/11/2023 à 22:36:16
Bonjour
J'ai un problème de connexion internet dans mon LAB j'ai configure un pfsense et j'ai ajouter deux interfaces sans compté pour WAN, une interface pour LAN et l'autre pour la DMZ, j'arrive avoir l'internet du coté LAN et pas du coté DMZ.
Aidez-moi à résoudre ce problème.
Guillaume - 08/11/2023 à 07:53:01
Bonjour @Ahmat :
Avez-vous ajouté les règles de filtrage nécessaires sur votre interface DMZ ? Cela se fait depuis le menu Firewall > Rules > onglet DMZ.
Il vous faut, par exemple, une règle autorisant le trafic depuis la DMZ (source : DMZnet) vers Internet (destination : any).
Cordialement,
Guillaume
--
Provya
Flux RSS des commentaires de cet article