Règles firewall pfSense : isoler plusieurs LAN et une DMZ

Ajouter une DMZ ou un réseau invité à pfSense ne sert à rien si les règles laissent tout passer, ou bloquent tout sans que l'on sache pourquoi. Tout tient dans trois principes : le sens, l'ordre et le refus par défaut.

Par la rédaction de Pixelabs · 12 octobre 2026

Le pare-feu (firewall) de pfSense décide ce qui passe d'un réseau à l'autre. Avec un seul LAN, la configuration par défaut suffit souvent ; dès qu'une DMZ ou un réseau invité s'ajoute, il faut écrire ses propres règles. Ce tutoriel explique comment le firewall pfSense lit ses règles, puis construit un jeu de règles pour trois réseaux internes.

Une règle mal placée peut couper l'accès à l'interface d'administration. Travaillez d'abord sur un lab et sauvegardez la configuration avant toute modification en production.

Comment pfSense lit ses règles

La documentation Netgate pose quelques principes qu'il faut connaître avant d'écrire la première règle.

• Filtrage à l'entrée : les règles d'un onglet d'interface s'appliquent au trafic qui entre par cette interface. Le trafic initié depuis le LAN est filtré par les règles du LAN, pas par celles du WAN.
• Premier match : sur un onglet d'interface, les règles sont lues de haut en bas et la première qui correspond s'applique ; l'évaluation s'arrête là. Les règles les plus permissives vont donc en bas.
• Filtrage avec état : quand une connexion correspond à une règle pass, pfSense crée une entrée dans la table d'états, et les réponses reviennent automatiquement. Inutile d'écrire la règle retour.
• Refus par défaut : tout ce qui ne correspond à aucune règle est bloqué silencieusement.

Les onglets n'ont pas tous le même poids. Netgate indique l'ordre de traitement des règles de niveau 3 : d'abord les règles Floating, puis les règles des groupes d'interfaces, enfin les règles de chaque interface. Un blocage dans un groupe ne peut donc pas être annulé par une règle d'onglet d'interface.

Ce que contient pfSense par défaut

La dernière ligne surprend souvent : une DMZ fraîchement créée ne peut même pas résoudre un nom DNS. C'est le comportement attendu d'une politique de refus par défaut, que Netgate présente comme la bonne pratique : n'autoriser que le strict nécessaire.

Le lab : trois réseaux internes

Si vous partez de zéro, installez d'abord pfSense dans VirtualBox et ajoutez une carte par réseau. Une fois les interfaces affectées et nommées, leurs onglets apparaissent sous Firewall > Rules avec leur nom descriptif.

Étape 1 : un alias pour les réseaux privés

Netgate recommande les alias pour garder un jeu de règles court. Créez sous Firewall > Aliases un alias de type réseau, par exemple RESEAUX_PRIVES, contenant les trois blocs RFC 1918 : 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Une seule règle pourra ainsi refuser tous les réseaux internes, présents et futurs.

Étape 2 : les règles de la DMZ

Sur l'onglet DMZ, ajoutez les règles dans cet ordre exact :

L'ordre fait tout. Une requête DNS correspond à la règle 1 et passe. Une connexion vers le LAN ne correspond pas à la règle 1, correspond à la règle 2 et est rejetée. Une connexion vers Internet n'est ni du DNS vers pfSense ni une destination privée : elle atteint la règle 3. Inversez les règles 2 et 3, et la DMZ joint le LAN.

Quelques champs méritent attention dans l'éditeur de règle :

• Protocol vaut TCP par défaut. Netgate signale l'erreur classique : n'écrire que des règles TCP, puis ne plus pouvoir passer l'ICMP ou le DNS. Choisissez Any quand vous voulez tout le trafic.
• DMZ subnets est une macro qui désigne les réseaux directement attachés à l'interface. Attention, WAN subnets ne signifie pas « Internet » mais seulement le réseau de l'adresse WAN.
• This firewall (self) désigne toutes les adresses de pfSense sur toutes ses interfaces.
• Description documente la règle (52 caractères au plus) : c'est ce que vous relirez dans six mois.

Étape 3 : les invités et le LAN

L'onglet INVITES reprend exactement le même schéma, avec la source « INVITES subnets ». Si un portail captif avec authentification RADIUS est actif sur ce réseau, la règle 1 (DNS) est indispensable : sans résolution DNS, la page de connexion ne s'affiche jamais.

Côté LAN, la règle par défaut « allow LAN to any » laisse déjà passer le trafic vers la DMZ. Pour aller plus loin, Netgate conseille de remplacer cette règle permissive par des autorisations précises, et de réserver l'accès à l'administration de pfSense à un alias d'hôtes de confiance avant de désactiver l'anti-lockout.

Ne désactivez pas la règle anti-lockout (System > Advanced) avant d'avoir créé et testé la règle qui vous garde l'accès à l'interface web : sinon, vous vous enfermez dehors.

Block ou reject ?

Block jette le paquet sans réponse ; le client attend l'expiration de son délai. Reject répond par un TCP RST ou, pour l'UDP, un ICMP « unreachable ». Netgate recommande block sur le WAN et reject sur les interfaces internes.

Vérifier que les règles font ce que vous croyez

• Depuis la DMZ, testez un nom DNS, un site web, puis une adresse du LAN : seule la dernière doit échouer, immédiatement.
• Sur Firewall > Rules, la colonne States affiche pour chaque règle le nombre d'états créés et le trafic ; le survol montre les évaluations et les paquets. Une règle à zéro ne sert à rien ou est masquée par une règle plus haute.
• Sous Status > System Logs, onglet Firewall, pfSense journalise par défaut les paquets bloqués par la règle de refus par défaut. Cochez Log sur une règle précise pour suivre son trafic.

Voir aussi la configuration de pfSense, le comparatif OPNsense vs pfSense et la rubrique réseau et pare-feu.

Questions fréquentes