Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Troubleshooting / Dépannage de ses règles de NAT

icon 30/06/2020 - Aucun commentaire

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.


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 :

Menu Diagnostics > Test Port - pfSense - Provya


En cas de connexion réussie :

Test connexion TCP avec succès - pfSense - Provya

Connexion TCP réussie


En cas d'échec :

Test connexion TCP en échec - pfSense - Provya

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 configuration Outbound NAT pfSense - Provya

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 :

Menu Diagnostics > Packet Capture pfSense - Provya


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.

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Troubleshooting / Dépannage de ses règles de filtrage

icon 02/05/2019 - Aucun commentaire

Des difficultés pour comprendre pourquoi sur votre pfSense telle ou telle règle de filtrage ne fonctionne pas comme prévu ?
Alors, cet article est fait pour vous ! ;-)

En nous inspirant de la page Firewall Rule Troubleshooting (en anglais) issue de la documentation officielle de pfSense, nous proposons ici un guide rapide et en français sur la méthodologie à suivre pour le dépannage des règles de filtrage de pfSense.



Activer et vérifier les logs !

La première chose à faire est d'activer la journalisation (log) sur la ou les les règle(s) posant problème. Pour cela, éditez votre règle de filtrage et dans la partie "Extra Options" cochez la case Log packets that are handled by this rule.

log packets firewall pfSense


Pensez à sauvegarder, puis à appliquer le changement.


Pour visualiser les logs, se rendre dans le menu Status > System Logs, puis cliquez sur l'onglet Firewall.

Vous visualiserez tous les paquets correspondants à une règle de firewall pour laquelle la journalisation est activée, ainsi que les paquets bloqués par défaut par pfSense (car ils ne correspondaient à aucune règle d'autorisation de trafic).

Exemple :

firewall logs pfSense


Si vous cliquez sur l'icône d'action ( action block pfSense ou action pass pfSense ) tout à gauche de la ligne, cela affichera un popup vous indiquant quelle règle a autorisé ou interdit ce paquet.

Exemple :

détails logs rules pfSense


Sur cette capture d'écran, on peut voir que c'est une règle présente sur l'interface re1 qui autorise le trafic TCP depuis le réseau 192.168.0.0/24 vers n'importe quelle destination sur le port 443 et que la description associée à cette règle est "Trafic Web HTTPS".



S'assurer que la règle est configurée sur la bonne interface

Pour choisir l'interface sur laquelle configurer une règle de filtrage, il faut raisonner du point de vue du firewall et comprendre qu'il applique ses règles de filtrage sur l'interface sur laquelle il reçoit les paquets.
Par exemple, pour configurer un filtrage d'un flux réseau provenant du LAN et à destination du WAN, alors le firewall va recevoir les paquets réseaux sur son interface LAN ; c'est donc sur l'interface LAN qu'il faut configurer le filtrage voulu.

Pour filtrer les flux réseaux en provenance d'Internet et à destination de votre LAN, alors le firewall va recevoir les paquets réseaux sur son interface WAN ; c'est donc sur l'interface WAN qu'il faut configurer le filtrage voulu.

Techniquement, pfSense réalise un filtrage de type ingress.



Vérifier l'ordre de ses règles

Les règles de filtrage sont appliquées dans un ordre bien précis. Les règles sont analysées les unes après les autres du haut vers le bas. La première règle qui correspond à tous les critères qui l'emporte : l'action associée est appliquée et les règles suivantes sont ignorées (sauf pour les règles "floating").

La vérification des règles de filtrage est réalisée dans l'ordre suivant :
  1. Règles "floating" : ce sont les règles analysées en premier ;
  2. Règles de groupe d'interfaces : second jeu de règles à être analysé. Cela comprend le groupe "IPsec" et "OpenVPN" ;
  3. Règles de l'interface : les règles configurées sur l'interface (LAN, WAN, OPT1, ...) ne sont analysées qu'en dernier.

Il est important d'avoir cet ordre en tête car si vous recherchez quelle règle va s'appliquer à quel trafic réseau, vous devrez suivre ce cheminement.

L'interface floating a un mode de fonctionnement particulier : l'analyse des règles suit le processus de la dernière règle qui correspond à tous les critères l'emporte (alors que pour les groupes d'interfaces et pour les interfaces, c'est le fonctionnement inverse : la première règle qui correspond à tous les critères l'emporte).

Pour avoir un mode de fonctionnement suivant la logique de la première règle correspondant à tous les critères qui l'emporte sur l'interface floating, il est nécessaire de cocher la case "Quick" des règles concernées.

Enfin, pour être exhaustif, l'ordre de traitement complet (mais simplifié) des paquets réseau par pfSense est le suivant :
  • règles d'Outbound NAT
  • règles de translation de ports (Port Forwards)
  • règles de NAT pour le load-balancing
  • règles reçues dynamiquement par les clients OpenVPN et par RADIUS pour IPsec
  • règles automatiques internes (obtenues par diverses sources comme snort, DHCP, ...)
  • règles définies par l'utilisateur (sur l'interface floating, sur les interfaces de groupes et pour chaque interface)
  • règles automatiques pour les VPN



Vérifier le protocole

Dans la configuration des règles de filtrage, il faut définir le protocole de transport utilisé. Il s'agit généralement de TCP, UDP ou ICMP.
Vous pouvez rencontrer d'autres protocoles également si vous administrez des VPN ou avez une configuration pfSense en haute disponibilité.

Une erreur classique est de configurer une règle avec le protocole UDP à la place de TCP ou inversement.
Dans le doute, vous pouvez essayer de configurer votre règle avec la valeur TCP/UDP.



Translation de port & NAT

Lorsque l'on configure des règles de NAT entrant (port forward et 1:1 NAT), il faut se rappeler que le NAT s'applique avant les règles de filtrage. Ainsi, les règles de filtrage sont à appliquer sur les adresses IP privées de destination.



Port source et port destination

Quand vous configurez vos règles de filtrage, il faut garder en tête que généralement uniquement le port source ou le port destination doit être précisé, rarement les deux.
Dans la majorité des cas, le port source n'a pas d'intérêt.
Par exemple, pour configurer un accès SSH à un serveur, vous devrez uniquement préciser le port destination : 22 / TCP. Le port source du client sera aléatoire.



Penser à réinitialiser la table d'état si nécessaire

Si une nouvelle règle bloquant du trafic vient tout juste d'être créée, il est possible qu'un état existant dans la table d'état permette toujours au trafic de passer.

Pour être certain d'éliminer cette hypothèse, il faut réinitialiser la table d'état depuis le menu Diagnostics > States, onglet Reset States.

Dans la même logique, il est important de procéder à une réinitialisation de la table d'état lorsque l'on configure des règles de priorisation de trafic. Voir à ce sujet notre article dédié : [pfSense] Configurer la priorisation de trafic avec CBQ.



Trafic ne pouvant pas être filtré

Le trafic réseau entre deux équipements se trouvant sur le même réseau (sur le LAN, par exemple) ne pourra pas être filtré par le firewall car le trafic entre ces deux équipements ne passera jamais par le firewall. Ce trafic est transmis directement d'un équipement à l'autre par le switch.
Si vous avez besoin de mettre en place du filtrage entre deux équipements se trouvant sur votre réseau local, alors vous devrez créer 2 réseaux locaux distincts (soit physiquement, soit logiquement par la mise en place de VLAN). Ce sera souvent le cas pour séparer son réseau de téléphonie sur IP du reste de son réseau local ou encore pour isoler des serveurs du reste du LAN (en créant une DMZ, par exemple).



Règle "pass" automatiquement associée au Port Forward

Par défaut, lorsque l'on crée une règle de translation de port (Port Forward), pfSense propose de créer une règle d'autorisation du trafic. Cela va entrainer un bypass des autres règles de filtrage.
D'une façon générale, nous déconseillons de laisser cette option de création d'une règle automatique. Il vaut mieux la créer manuellement afin de bien comprendre comment et où la créer dans sa stratégie de filtrage complète.



Routage asymétrique

Dernier cas que nous souhaitions aborder : le routage asymétrique. Le routage asymétrique se produit dans le cas où le chemin aller est différent du chemin retour (ex : aller via A > B > C ; puis retour via C > D > A).
Ce cas peut se repérer à travers la présence de trafic comme TCP:A, TCP:SA, ou TCP:RA qui se retrouve bloqué dans les logs.
Si vous rencontrez un problème de routage asymétrique avec votre pfSense, nous vous recommandons la lecture de la documentation officielle sur le sujet : Troubleshooting Blocked Log Entries due to Asymmetric Routing.

Vous avez maintenant toutes les armes en main pour faire un troubleshooting efficace de vos règles de filtrage !



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Configurer ses VLAN
[pfSense] Comprendre la gestion des interfaces réseaux


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :