Editions ENI Livres | Vidéos | e-Formations
Automatisation et commandes utiles
Automatiser l’administration de pfSense
L’interface web de pfSense suffit tant qu’il n’y a qu’un pare-feu à administrer. Dès que le parc grandit, elle devient un facteur de dérive : deux équipements censés porter la même politique finissent par diverger, sans que personne sache exactement où ni depuis quand.
L’automatisation répond à ce problème. Elle consiste à décrire la configuration attendue dans des fichiers, à les versionner, puis à les appliquer aux équipements. La configuration cesse d’être le résultat d’une suite de clics pour devenir un artefact relu, testé et reproductible.
Ce chapitre couvre trois voies complémentaires : le pilotage déclaratif avec Ansible, l’API REST du paquet communautaire, et le déploiement d’instances dans le cloud. Il se termine par un mémento des commandes shell utiles au diagnostic quotidien.
1. Ce que l’automatisation apporte
Trois bénéfices justifient l’investissement initial.
-
La reproductibilité : la même description produit la même configuration, sur le pare-feu de production comme sur celui de recette.
-
La traçabilité : chaque modification passe par un commit, donc par un auteur, une date et une justification.
-
La réversibilité :...
Piloter pfSense avec Ansible
1. Deux approches à ne pas confondre
Deux mécanismes permettent de piloter pfSense depuis un serveur d’automatisation, et ils sont indépendants l’un de l’autre. Les confondre est la première cause d’échec.
|
Critère |
Collection Ansible |
API REST |
|
Canal |
SSH vers le pare-feu |
HTTPS vers le pare-feu |
|
Ce qu’il faut installer sur pfSense |
Rien |
Le paquet REST API |
|
Ce qu’il faut installer sur le serveur |
La collection pfsensible.core |
Rien de particulier |
|
Exécution |
Modules Python lancés sur pfSense |
Requêtes HTTP depuis n’importe quel langage |
|
Usage typique |
Politique déclarative, idempotente |
Intégration applicative, scripts |
La collection Ansible n’a pas besoin de l’API REST. Les modules pfsensible.core se connectent en SSH, s’exécutent directement sur le pare-feu et modifient config.xml. Installer le paquet API pour faire tourner un playbook est un travail inutile.
2. Prérequis
Vérifiez que le serveur Ansible peut joindre chaque nœud pfSense en SSH. L’accès SSH s’active depuis Système - Avancé - Secure Shell, en cochant Enable Secure Shell.
Utilisez le compte root ou un compte disposant des mêmes droits. Les modules doivent s’exécuter en root pour modifier la configuration, et pfSense ne dispose pas de sudo par défaut. Le paquet pfSense-pkg-sudo peut être installé si vous préférez passer par un compte nominatif.
Installez la collection sur le serveur de contrôle, en épinglant la version compatible avec pfSense 2.7.2 :
ansible-galaxy collection install 'pfsensible.core:<0.7.0' L’épinglage est indispensable. La version 0.7.0 a refondu la façon dont les modules lisent la configuration et n’est annoncée compatible qu’à partir de pfSense 2.8.0. Sans contrainte de version, ansible-galaxy récupère la dernière publiée, donc une version incompatible, et le playbook échoue dès la première tâche.
3. Arborescence du projet
Le projet ci-dessous sépare l’inventaire, les variables et les playbooks. Cette organisation n’a rien d’obligatoire, mais elle facilite la relecture et permet de faire évoluer les règles sans toucher...
L’API REST de pfSense
1. Quelle API pour quelle édition ?
La situation mérite d’être posée clairement, car elle est source de confusion.
L’édition Community ne dispose d’aucune API officielle. Netgate en propose une sur pfSense Plus, mais elle n’est pas disponible sur CE. Pour automatiser un pare-feu en édition Community, il faut donc installer un paquet tiers.
Le seul projet actif aujourd’hui est pfSense REST API, développé par Jared Hendrickson et hébergé sur le dépôt pfrest. Il expose plus de deux cents points d’accès REST, ainsi qu’une interface GraphQL depuis sa version 2.2.
FauxAPI, souvent cité comme alternative, ne doit plus être utilisé : son dépôt a été archivé en lecture seule par son auteur en juin 2026, et sa dernière version validée visait pfSense 2.4. Elle ne fonctionne pas sur les versions actuelles.
Attention également à ne pas confondre les deux branches du paquet REST API. La branche 1, nommée pfSense-pkg-API, expose ses ressources sous /api/v1/ ; la branche 2, nommée pfSense-pkg-RESTAPI, les expose sous /api/v2/ avec un modèle de données entièrement redessiné. Il n’existe pas de mise à jour directe de l’une vers l’autre. Ce chapitre utilise la branche 2.
2. Installer le paquet
Connectez-vous en SSH sur pfSense, ou ouvrez la console.
Installez la version correspondant exactement à votre version de pfSense. Pour du CE 2.7.2, la dernière version compatible est la v2.4.3 :
pkg-static -C /dev/null add \
https://github.com/pfrest/pfSense-pkg-RESTAPI/releases/download/\
v2.4.3/pfSense-2.7.2-pkg-RESTAPI.pkg Le numéro de version dans le nom du fichier est celui de pfSense, pas celui du paquet, et il doit correspondre au chiffre près. Ne remplacez pas le numéro de version du paquet par latest : vous récupéreriez une version 2.5 ou supérieure, qui ne prend plus en charge pfSense 2.7.2 et laisse l’interface web en erreur.
Vérifiez l’installation. Le paquet ajoute une entrée dans le menu Système - REST API et installe un utilitaire en ligne de commande :
pkg-static info | grep RESTAPI
pfsense-restapi...Déployer pfSense dans le cloud
1. Préconfigurer une installation
pfSense ne prend en charge ni Kickstart ni cloud-init. Il reste néanmoins possible de préparer une installation reproductible :
-
en partant d’un modèle de machine virtuelle exporté au format OVF ou OVA, déjà configuré ;
-
en injectant un fichier config.xml dans le répertoire /conf lors de la première installation, ce qui applique une configuration complète au premier démarrage ;
-
en confiant la configuration post-installation à Ansible, une fois l’accès SSH établi.
La seconde méthode est la plus radicale : elle permet de livrer un pare-feu déjà configuré, mais elle suppose de maîtriser la structure du fichier de configuration, qui évolue d’une version majeure à l’autre.
2. Appliances Netgate
Les appliances Netgate sont livrées avec pfSense Plus préinstallé et bénéficient d’optimisations matérielles, notamment pour l’accélération cryptographique. Elles peuvent être réinstallées avec une image officielle téléchargée depuis le portail Netgate, ce qui suppose un compte client.
Sauvegardez la configuration depuis Diagnostics - Sauvegarde et restauration avant toute réinstallation. Prévoyez également...
Superviser après le déploiement
L’automatisation ne s’arrête pas au déploiement. Une configuration appliquée sans supervision est une configuration dont personne ne sait si elle produit l’effet attendu.
Quatre points méritent une surveillance continue :
-
L’état des interfaces et la charge du pare-feu, en processeur, en mémoire et en nombre d’états.
-
La disponibilité des services critiques : VPN, résolution DNS, NAT, répartition de charge.
-
La synchronisation du cluster, un basculement inattendu signalant souvent un incident sous-jacent.
-
La conservation des journaux, pour l’audit comme pour l’analyse a posteriori.
1. Avec Zabbix
-
Activez SNMP sur pfSense et collectez la charge, la mémoire et le débit par interface.
-
Construisez un modèle dédié couvrant les interfaces, les passerelles et l’état CARP.
-
Déclenchez une alerte sur le changement de rôle CARP ou sur la perte d’une passerelle.
2. Avec Prometheus et Grafana
Installez un exportateur sur le pare-feu, ou interrogez l’API REST depuis un collecteur externe.
Configurez Prometheus pour venir chercher les métriques à intervalle régulier.
Importez un tableau de bord Grafana et branchez-le sur la source de données Prometheus.
Les données les plus utiles au quotidien sont...
Commandes shell utiles
L’interface web couvre l’essentiel de l’administration, mais le shell reste irremplaçable pour le diagnostic. pfSense repose sur FreeBSD et met à disposition tout l’outillage système et réseau de cette plateforme.
Activez l’accès SSH depuis Système - Avancé - Secure Shell, en cochant Enable Secure Shell.
Les commandes de cette partie ont été vérifiées sur pfSense CE 2.7.2. Certaines dépendent de paquets qui ne sont pas installés par défaut, ce qui est signalé au cas par cas. D’autres varient entre versions majeures : les chemins des baux DHCP notamment changent à partir de pfSense 2.8, qui remplace le serveur ISC par Kea.
1. Analyse de trafic avec tcpdump
tcpdump est l’outil de référence pour observer le trafic en temps réel. Sur pfSense, les noms d’interface sont ceux de FreeBSD : em0, em1, igb0, vtnet0 selon le matériel. La correspondance avec les noms logiques WAN et LAN se lit dans Interfaces - Affectations.
# Tout le trafic d'une interface
tcpdump -i em0
# Un port precis, sans resolution de noms
tcpdump -n -i em0 port 80
# Croiser un hote et un port
tcpdump -n -i em1 host 192.168.1.57 and port 80
# Enregistrer pour analyse ulterieure dans Wireshark
tcpdump -n -i em0 -w /tmp/capture.pcap
# Relire un fichier de capture
tcpdump -n -r /tmp/capture.pcap Les filtres suivants répondent à des besoins de diagnostic courants.
# Uniquement les demandes d'ouverture de connexion
tcpdump -n 'tcp[tcpflags] & tcp-syn != 0'
# Trafic chiffre vers un sous-reseau
tcpdump -n -i em0 dst net 10.0.0.0/8 and port 443
# Afficher le contenu en clair
tcpdump -A -n -i em0 port 80
# Trafic IPv6, et messages ICMPv6
tcpdump -n -i em0 ip6
tcpdump -n -i em0 icmp6 L’option -n désactive la résolution inverse des adresses. Sans elle, chaque paquet déclenche une requête DNS, ce qui ralentit l’affichage et fausse la lecture des horodatages. Prenez l’habitude de la mettre systématiquement.
2. Tests de connectivité
ping -c 4 8.8.8.8
ping -6 -c 4 2001:4860:4860::8888
traceroute 1.1.1.1
traceroute6...Synthèse du chapitre
Ce chapitre a présenté trois façons de sortir de l’administration manuelle de pfSense, et le mémento de commandes qui reste nécessaire quand il faut comprendre ce qui se passe réellement.
La collection Ansible pfsensible.core convient à la gestion déclarative d’un parc : elle se connecte en SSH, ne demande aucun paquet supplémentaire sur le pare-feu et garantit l’idempotence. L’API REST du paquet communautaire convient à l’intégration applicative, depuis n’importe quel langage, au prix de l’installation d’un paquet tiers et d’une attention constante aux versions. Le déploiement cloud, enfin, ne concerne aujourd’hui que pfSense Plus.
La contrainte commune à ces trois voies est la compatibilité des versions. Le paquet REST API, la collection Ansible et pfSense évoluent à leur propre rythme, et une combinaison non validée échoue de façon peu explicite. Figer les versions dans un fichier de dépendances, et les revoir à chaque montée de version du pare-feu, évite l’essentiel des difficultés.
Enfin, l’automatisation ne dispense pas de la supervision. Une configuration appliquée sans être observée n’est pas une configuration maîtrisée : c’est seulement une configuration...