Provya

Expertise pfSense

Sommaire des articles  -  Liens & Actualités  -  Firewall pour pfSense

[pfsense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense

icon 19/11/2019

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 :

Schéma de traitement NAT et filtrage par pfSense - Provya


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 :

Schéma réseau de redirection d'un port entrant sous pfSense - Provya


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

Menu Firewall > NAT - Port Forward - pfSense - Provya


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 :

Exemple de configuration d'une redirection de port sous pfSense - Provya


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

Exemple d'une règle de filtrage pour une redirection de port sous pfSense - Provya


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.


Retrouvez nos services et firewall pour pfSense & OPNsense



Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Soho pour pfSense et OPNsense         Firewall pro-Maxi pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

15 commentaires

artorix - 20/11/2019 à 19:01:41

Bonjour,
un grand merci pour les explications accessibles aux gens qui n'ont pas fait d'études informatique.
ps : les cartes wi-fi Atheros que j'ai commandé chez vous (il y a quelques temps) fonctionnent nickel sur mon vieux Thinkpad, et tout aussi bien sur un Fujitsu plus moderne.
bonne continuation.

@répondre #lien

Diogo78 - 04/05/2020 à 01:20:34

Bonjour,

Merci beaucoup pour cet article qui est très pertinent.
Cependant dans mon cas, je souhaite NAT l'interface LAN vers le réseau lan.
exemple le trafic venant de la patte WAN je souhaite qu'il soit natté par l'interface LAN (lab de fin d'étude) mais je n'y arrive pas :/

J'ai pourtant cherché mais je n'arrive pas à comprendre pourquoi ça ne fonctionne pas.

J'ai analysé le trafic, la source ip est toujours celle de ma machine coté WAN :/

si vous pouvez m'aider, merci d'avance,

cordialement,

@répondre #lien

Guillaume - 04/05/2020 à 08:38:26

@Diogo78 :
Bonjour,

Vous devez configurer une règle d'Outbound NAT. Il faut que le mode d'Outbound NAT soit en hybride ou en manuel (sûrement hybride dans votre cas).
Il vous reste à configurer une règle avec les paramètres suivants :
- interface : LAN
- source : any
- destination : le subnet de votre LAN
- adresse : Interface Address

Cordialement,

Guillaume
--
Provya

@répondre #lien

hay - 01/10/2020 à 15:39:06

@Guillaume :

bonjour
j'ai une ip publique que je veut natter avec mon lan , j'ai suivi votre commentaire mais hélas, ça ne marche pas .

par contre avec NAT 1:1 ça marche
cordialement

@répondre #lien

Guillaume - 02/10/2020 à 07:46:56

@hay :
Bonjour,

Je ne comprends pas ce que vous voulez faire.

Cordialement,

Guillaume
--
Provya

@répondre #lien

Guigui - 02/12/2020 à 14:06:02

bonjour,

sur mon pfsence, j'ai 2 VPN et j'aimerais mettre en place du NAT pour que les flux recu dans un VPN soit renvoyer vers l'autre VPN :
MVPN1 -> PfSense -> MVPN2.
Penez vous que cela soit possible ?

Guillaume

@répondre #lien

Guillaume - 03/12/2020 à 18:20:38

@Guigui :
Bonjour Guillaume,

Oui, bien-sûr, c'est possible.

S'il s'agit de deux VPN sur lesquels vous avez la main, le plus simple est d'annoncer les réseaux de part et d'autre.
Si vous n'avez pas la main sur les VPN ou qu'il y a une contrainte de type overlap, le plus simple est de recourir à du NAT.

Cordialement,

Guillaume
--
Provya

@répondre #lien

Pascal MELOT - 14/01/2021 à 22:31:54

Bonsoir,

Est-ce avec une règle outbound NAT que l'on peut obliger UNE ip (ou une partie) du LAN à sortir par une passerelle particulière (quand on a plusieurs accès WAN) ?

Merci
Pascal

@répondre #lien

Guillaume - 15/01/2021 à 10:46:21

@Pascal MELOT :
Bonjour Pascal,

Non, ce n'est pas avec une règle de NAT.

C'est avec une règle de filtrage, configurée sur l'interface LAN, sur laquelle vous ferez correspondre pour le champ "Source" l'adresse IP (ou la plage d'adresses IP) que vous voulez orienter vers une passerelle particulière, puis dans les options avancés de la règle de filtrage (bouton "Display Advanced"), vous choisirez la passerelle que vous souhaitez (champ "Gateway").

Cordialement,

Guillaume
--
Provya

@répondre #lien

Pablo - 20/07/2021 à 17:12:23

Bonjour Guillaume,

Je comprend pas pourquoi l'ordre de lecture des règles de NAT change entre un flux allant du WAN vers le LAN (SNAT > DNAT) et flux allant du LAN vers le WAN (DNAT > SNAT).

Il y a une raison particulière au niveau réseau ?

@répondre #lien

Guillaume - 21/07/2021 à 15:48:02

@Pablo :
Bonjour Pablo,

Non, l'ordre de lecture des règles de NAT ne change pas entre un flux LAN > WAN et un flux WAN > LAN.

Si vous reprenez le schéma présent au début de notre article, le DNAT est effectué à l'étape 2 ("NAT LAN") pour un flux LAN > WAN ; ce qui correspond à l'étape "NAT WAN" pour un flux WAN > LAN.

Le SNAT, quant à lui, est effectué à l'étape 4 ("NAT WAN") pour un flux LAN > WAN ; ce qui correspond à l'étape "NAT LAN" pour un flux WAN > LAN.

Cordialement,

Guillaume
--
Provya

@répondre #lien

Pablo - 21/07/2021 à 16:19:35

@Guillaume : Ok je saisis mieux le concept !

J'avais cru comprendre que dans le schéma, le NAT LAN était lié à une application d'inbound rule et que le NAT WAN était lié à une application d'outbound rule.

Mais pas du tout, dans les deux cas c'est d'abord une inbound rule puis une outbond rule.

Merci c'est clair maintenant

@répondre #lien

Christophe - 13/06/2024 à 18:07:08

Un tcpdump sur une interface interne de tunel IPSec (enc0) semble montrer que l'ordre en sortie est avant tout un tcpdump et donc probablement translation puis régles. Cela semble confirmer avec les traces /var/log/filter.log. Mon analyse vous semble telle correcte ?

@répondre #lien

Guillaume - 17/06/2024 à 17:39:38

Bonjour @Christophe,

Je ne comprends pas dans quel cadre vous réalisez le test ? Sur un VPN IPsec natté ? Ou dans le cas d'un port forward configuré sur enc0 ?

Cordialement,

Guillaume
--
Provya

@répondre #lien

icon Flux RSS des commentaires de cet article