Comprendre l'ordre dans lequel les règles de NAT et de filtrage sont appliquées est important lorsque l'on configure son firewall.

Dans cet article nous détaillons l'ordre dans lequel pfSense applique ses règles de filtrage, de translation de port et de NAT et l'impact que cela a sur l'écriture de nos règles.

1. L'ordre de traitement - schéma global

Un bon schéma étant souvent plus parlant qu'un long texte, l'ordre de traitement des paquets réseaux par pfSense peut se résumer par le schéma suivant :



Ce schéma de fonctionnement présente le cheminement suivi pour le trafic sortant (quittant le réseau local à destination d'Internet) et pour le trafic entrant (depuis Internet vers le réseau local ou une DMZ). Le cheminement est exactement le même dans les deux sens.

Pour chacune des étapes, si aucune règle n'existe, alors celle-ci sera simplement ignorée et pfSense passera à la suivante.

Prenons le cas d'un paquet réseau quittant le LAN à destination d'Internet. En suivant les numéros présents sur notre schéma, l'ordre de traitement détaillé est le suivant :

1. tcpdump : réalisé sur l'interface LAN (accessible via l'outil "Packet Capture" du menu "Diagnostics" de pfSense). Lorsque la capture est effectuée sur l'interface LAN (pour un paquet quittant le LAN à destination d'Internet), aucun traitement n'a encore été effectué par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet "brut" tel qu'il est émis par l'ordinateur. Le détail du fonctionnement de l'outil Packet Capture fera l'objet d'un prochain article.
2. Port forward ou 1:1 NAT configurés sur l'interface LAN. On configure rarement des règles de redirection de ports (port forward) ou de NAT 1 pour 1 (1:1 NAT) sur l'interface LAN, mais nous rencontrerons des règles de NAT équivalentes lorsque nous utilisons un proxy ou des redirecteurs DNS. Dans ces cas-là, on parle également de "DNAT" pour Destination NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP de destination.
3. Règles de filtrage configurées pour l'interface LAN. Les règles de filtrage sont appliquées dans l'ordre suivant : règles de floating, règles de groupe d'interfaces, puis finalement les règles de l'interface elle-même.
4. 1:1 NAT ou règles d'Outbound NAT configurés sur l'interface WAN. Dans ce cas-là, on parle de "SNAT" pour Source NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP source. C'est à cette étape que le paquet réseau prend comme adresse IP source l'adresse IP de l'interface WAN de pfSense.
5. Règles de filtrage de type floating dans le sens "out" pour l'interface WAN. C'est un cas très spécifique. Pour un usage de base, c'est rarement utilisé. Ces règles de floating peuvent être très utiles lorsque l'on souhaite configurer de la priorisation de trafic sur un environnement multi-VLAN. Il faut garder en tête qu'à cette étape, le NAT sortant (Outbound NAT) a déjà été appliqué et que les adresses IP source des paquets ne sont donc plus les adresses IP privées du LAN, mais l'adresse IP de l'interface WAN (ou celle qui a été configurée dans les règles d'Outbound NAT).
6. tcpdump : réalisé sur l'interface WAN. À ce stade, tous les traitements ont été effectués par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet tel qu'il est transmis vers Internet (ou vers le routeur de l'opérateur, par exemple)

L'outil tcpdump est toujours le premier et le dernier à voir le trafic, en fonction de l'interface sur laquelle il est effectué et de la direction du trafic.
Ainsi, dans le cas d'un trafic du LAN vers le WAN, un tcpdump exécuté sur l'interface LAN verra les paquets réseaux tel qu'ils sont émis par l'ordinateur
Un tcpdump exécuté sur l'interface WAN verra les paquets modifiés par pfSense tel qu'ils sont transmis en sortie de pfSense.
Il s'agit donc d'un outil de diagnostique très pratique dans le suivi de l'acheminement et du traitement des paquets réseaux.

Nous avons pris dans notre exemple le cas d'une architecture simple avec une interface LAN et une interface WAN. Le principe de fonctionnement est exactement le même sur une architecture disposant d'un plus grand nombre d'interfaces réseaux. Les étapes suivies seront toujours les mêmes.

2. Impact sur la configuration de ses règles

Ainsi, pour une interface donnée, les règles de NAT s'appliquent toujours avant les règles de filtrage. C'est la raison pour laquelle il faut adapter ses règles de filtrage avec les bonnes adresses IP sources/destinations.

Prenons un exemple : nous souhaitons rediriger le trafic arrivant sur le port 80 de l'adresse IP publique de notre firewall vers le port 80 d'un serveur local. Le schéma réseau ressemble à celui-ci :



Dans cet exemple, nous allons créer une règle de redirection de port (port forward) depuis le menu Firewall > NAT, puis onglet Port Forward (onglet par défaut) :



Nous cliquons sur le bouton "Add" ; les champs à compléter sont les suivants :

• Disabled : permet de désactiver la règle sans la supprimer. Nous laissons cette case décochée.
• No RDR (NOT) : permet de désactiver la redirection pour le trafic correspondant à cette règle. Cette option sera très peu utilisée dans la pratique. On préférera filtrer/affiner nos règles de redirection via des règles de filtrage.
• Interface : l'interface d'arrivée des paquets. Dans notre exemple, il s'agit de l'interface WAN.
• Protocol : le protocole concerné. Dans notre exemple, nous choisissons TCP.
• Source : il est rarement nécessaire de préciser la source sur une redirection de port pour du trafic entrant. Nous laissons ces champs vides.
• Destination : l'adresse IP de destination sur laquelle le trafic externe arrive. Soit, dans notre cas, l'adresse IP de notre WAN. Nous choisissons donc "WAN Address".
• Destination port range : le port réseau de destination. Dans notre cas, nous souhaitons rediriger le trafic arrivant sur le port 80. Nous pouvons ainsi choisir "HTTP" dans la liste déroulante ou choisir "Other" et indiquer 80 dans le champ Custom.
• Redirect target IP : il s'agit de l'adresse IP privée vers laquelle nous souhaitons rediriger le trafic. Dans notre exemple : 192.168.1.10.
• Redirect target port : le port d'écoute de la machine locale. Il s'agit généralement du même port que celui indiqué précédemment. Dans notre cas "HTTP".
• Description : un champs purement informatif.
• No XMLRPC Sync : cocher cette case pour ne pas synchroniser cette règle vers les autres membres CARP.
• NAT reflection : il s'agit d'un mode avancé permettant à un client interne d'accéder à une ressource interne en passant par son adresse IP externe. Notre exemple ne porte pas sur cet usage, nous laissons la valeur par défaut, "Use system default", ce qui revient à choisir "Disable".
• Filter rule association : cette option permet de laisser pfSense générer la règle de filtrage nécessaire pour le fonctionnement de notre redirection de port. Pour un utilisateur avancé, nous recommandons de choisir "None" et de configurer par soi-même la règle de filtrage afin d'être certains de la positionner là où on le souhaite parmi nos autres règles et de pouvoir la personnaliser si nécessaire. Par simplicité, pour notre exemple, nous laissons le choix par défaut "Add associated filter rule".

Exemple de résultat obtenu :



Sur notre interface WAN, une règle a été créée (si nous avons choisi "None" pour l'option Filter rule association, alors il faut créer soi-même cette règle) :



Nous constatons que l'adresse IP Destination de notre règle de filtrage est l'adresse IP privée (ici, 192.168.1.10). La raison est que le NAT est appliqué avant le filtrage. Ainsi, l'adresse IP de destination du paquet réseau a été modifiée par le firewall et correspond à ce stade à l'adresse IP privée de destination. Le filtrage doit donc bien porter sur l'adresse IP privée de destination.

Il nous reste à penser à cliquer sur "Apply Changes" aussi bien sur la page de gestion des règles de filtrage que sur celle de gestion des règles de NAT.
La redirection de port est en place.

Voila, vous savez maintenant parfaitement l'ordre que suit pfSense pour le traitement des paquets réseaux (NAT, filtrage, routage, etc.).
Nous verrons dans un prochain article la puissante de l'outil "packet capture" intégré à pfSense et la méthodologie d'utilisation que nous proposons pour faire ses analyses réseau.

Pour aller plus loin

[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS
Tous nos articles classés par thème
Voir un article au hasard


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