Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Écrire qui doit joindre quoi, sur quel protocole et pour quelle raison. « Autoriser le serveur Web vers la base en TCP sur son port dédié » est vérifiable ; « autoriser tout pour que cela marche » ne définit aucune limite. Créer des alias explicites, avec un responsable et une description.
Les règles d’interface pfSense traitent habituellement le trafic à son entrée sur l’interface et sont stateful : une connexion autorisée possède un état permettant les réponses. Les règles flottantes et de groupe ont leur propre place dans l’ordre de traitement ; toujours examiner l’ensemble, pas seulement l’onglet où l’on vient d’ajouter une règle.
Éviter de confondre port source et port destination. Un client utilise souvent un port source éphémère. Pour une publication, vérifier aussi la traduction NAT et la destination effective vue après traduction.
Une connexion déjà établie peut continuer après une modification de règle selon son état existant. Pour valider une nouvelle politique, créer une nouvelle connexion ou supprimer uniquement les états concernés lorsque l’impact est compris. Vider tous les états peut interrompre appels, VPN et sessions métier.
Regrouper les règles par fonction : administration, infrastructure, applications, sorties puis refus. Ajouter des séparateurs et des descriptions plutôt que multiplier les exceptions anonymes. Réexaminer périodiquement les alias qui désignent d’anciennes machines.
Réception : une matrice de tests doit présenter au moins un accès autorisé et un accès refusé pour chaque zone. Tester IPv6 séparément. Le NAT, un proxy DNS ou l’absence de réponse au ping ne constituent pas une preuve suffisante de filtrage.
Scénario fictif : autoriser les postes d’un VLAN à interroger uniquement leur DNS privé. Créer auparavant des alias lisibles et vérifier leur contenu.
| Champ | Exemple / choix | Pourquoi |
|---|---|---|
| Action | Pass | Autorise le flux ; Block ignore, Reject répond lorsque applicable |
| Interface | Interface d’entrée des postes | Une règle LAN se lit du point de vue d’un paquet entrant dans pfSense |
| Address Family | IPv4, IPv6 ou les deux selon plan | Ne pas oublier une voie IPv6 parallèle |
| Protocol | TCP/UDP pour DNS classique | DNS peut utiliser les deux ; ce n’est pas seulement UDP |
| Source | Alias des postes ou réseau de cette interface | Éviter any si le besoin est limité |
| Source port | Any | Les ports clients sont généralement éphémères |
| Destination | Alias du DNS autorisé | Ne pas ouvrir le port 53 vers toutes les machines |
| Destination port | 53 | Service précis |
| Log | Pendant validation puis selon besoin | Éviter de journaliser inutilement chaque requête en permanence |
| Description | Qui → quoi → pourquoi | Facilite les audits et les alertes |
Save enregistre ; Apply Changes applique les règles en attente. Vérifier l’état du rechargement et refaire une requête. Ne pas empiler des règles en cours de modification sans savoir lesquelles sont actives.
Les règles d’interface sont généralement évaluées de haut en bas jusqu’à la première correspondance. Les règles flottantes, groupes, mécanismes automatiques et options quick ont un ordre spécifique : les examiner si le résultat contredit la liste de l’interface. Une règle autorisant tout placée avant les restrictions les rend inefficaces.
Une connexion déjà établie peut conserver son état après modification. Pour tester une révocation, fermer la connexion ou supprimer seulement l’état ciblé après identification. Vider toute la table peut interrompre appels, tunnels et sessions métier. Un compteur à zéro ne prouve pas qu’une règle est inutile : la fonctionnalité peut n’être utilisée qu’occasionnellement.
Pour une zone d’atelier : DNS et NTP vers services désignés, déploiement vers serveur précis, accès Web nécessaire, refus vers réseaux internes sensibles, puis refus implicite du reste. L’ordre exact dépend de la liste et des exceptions. Définir un alias couvrant tous les réseaux internes concernés, y compris VPN et IPv6 ; les seules plages RFC1918 ne décrivent pas forcément tout l’interne.
Pour une zone serveurs exposés : permettre les mises à jour et les flux applicatifs nécessaires, limiter la base à son port et son serveur, refuser les consoles de gestion. Les réponses d’une connexion autorisée sont gérées par les états ; ajouter un « any vers any » de retour est généralement inutile et dangereux.
Gateway impose une politique de routage et peut détourner des flux internes ; laisser le routage normal sans besoin multi-WAN. Schedule lie la règle à un calendrier, à tester avec les connexions existantes. Les limites de connexions, états, connexions par source ou débit peuvent limiter un abus, mais une IP peut représenter de nombreux utilisateurs derrière un NAT. Les drapeaux TCP et types d’état demandent une compréhension du protocole ; conserver les valeurs supportées par défaut hors cas documenté.
Floating / Quick permettent une politique transversale avec une sémantique différente. Ne pas y dupliquer toutes les règles simples d’interface pour « centraliser » sans analyser l’ordre complet. Une politique doit rester lisible et testable.
Réaliser un test positif depuis la source autorisée et un test négatif depuis une autre zone. Lire logs et état pour vérifier source réelle, destination et règle. Ajouter une description et une justification à toute exception. Après migration d’adresse, chercher aussi alias, NAT, VPN, DNS et configurations d’applications ; modifier une seule règle peut laisser une ancienne exposition.
En retour arrière, restaurer la règle ou l’ordre précédent depuis l’accès de secours ; ne pas ouvrir globalement WAN. Retirer les règles temporaires et faire un nouvel export de configuration après validation.