Le débat OPNsense vs pfSense ne se règle plus par "celui qu'on a connu en 2015". Depuis le rachat de Netgate par EQT en 2024 et l'accélération de Deciso sur OPNsense, les trajectoires se sont écartées. Le firewall qu'on choisit en 2026 conditionne ce qu'on opère pour cinq à dix ans : périmètre, plugins, automatisation, audits.
Sur le papier les deux partagent la même base : FreeBSD, pf, IPFW, packages, web GUI. En pratique, les choix éditoriaux divergent. OPNsense livre des releases fixes deux fois par an et des correctifs de sécurité toutes les deux semaines. pfSense scinde son offre en CE (Community Edition) et Plus, ce dernier étant le canal qui reçoit les nouveautés en premier, en lien direct avec le hardware Netgate. Le résultat : deux produits techniquement proches, deux modes de gouvernance opposés.
On a opéré les deux. Voici ce qu'on regarde côté ops avant de trancher.
Plan de l'article
- Histoire courte des deux projets
- Licence, modèle économique, gouvernance
- Cadence de releases et durcissement
- Interface et expérience administrateur
- VPN : WireGuard, IPsec, OpenVPN
- Plugins et écosystème
- API et infrastructure as code
- Hardware et performance
- Recommandation selon le profil
Histoire courte des deux projets
pfSense est né en 2004, fork de m0n0wall, porté ensuite par Netgate. Il a longtemps dominé le marché du firewall open source pour le SOHO et la PME. La séparation entre pfSense Community Edition (libre) et pfSense Plus (lié au hardware Netgate ou licence séparée) a clarifié le modèle commercial mais introduit une asymétrie : les fonctionnalités neuves arrivent d'abord sur Plus, parfois plusieurs mois avant CE.
OPNsense est un fork de pfSense, démarré en 2015 par Deciso B.V. (Pays-Bas). Depuis, le projet a réécrit une grande partie de l'interface, modernisé le backend en MVC, intégré une infrastructure de plugins propre, et adopté HardenedBSD comme base au lieu de FreeBSD vanilla. La cadence de releases est calée sur janvier et juillet de chaque année.
L'écart est aujourd'hui structurel.
Licence, modèle économique, gouvernance
OPNsense : 2-Clause BSD, une seule codebase, pas de version "premium" verrouillée. Les services payants existent (support business, formation Deciso, certifications), mais ils n'enferment pas de fonctionnalités. Tout ce qu'on installe en home lab tourne identiquement en prod chez un ISP.
pfSense : double licence. CE en Apache 2.0 mais avec un retard fonctionnel assumé. Plus est livré sous EULA Netgate, gratuit sur appliance Netgate ou par licence séparée. Les fonctionnalités notables (par exemple les améliorations multi-WAN avancées, certains modes ZFS, certaines optimisations performances) atterrissent d'abord sur Plus.
Côté ops, le modèle pfSense se justifie quand on achète l'appliance Netgate avec support officiel. Hors de ce cadre, on installe CE et on accepte le retard. OPNsense n'impose pas ce choix : le binaire qu'on télécharge est le binaire complet.
Cadence de releases et durcissement
OPNsense publie deux versions majeures par an, en janvier et juillet. Entre les majeures, des correctifs (security et bugfix) sortent toutes les deux semaines. La traçabilité est claire : changelog publié, CVE référencés, communications officielles.
pfSense Plus a accéléré récemment, mais CE reste plus lent. Plusieurs CVE FreeBSD ont mis des semaines avant d'arriver dans CE en 2025. Pour un firewall en bordure de prod, ce délai est un risque.
Côté hardening, OPNsense s'appuie sur HardenedBSD : ASLR, PIE, mitigations contre les exploits userland. pfSense reste sur FreeBSD vanilla. Pour un firewall qui voit du trafic public, l'écart est concret. Les pratiques de hardening complémentaires côté pile filtrage restent les mêmes : règles strictes, segmentation, IDS. On peut consulter notre guide nftables avancé pour la philosophie générale, transposable côté pf.
Interface et expérience administrateur
L'UI OPNsense est moderne. Menu latéral hiérarchique, recherche globale, dark mode, widgets dashboard configurables, légendes claires. La modification d'une règle se fait avec une form bien étiquetée, pas un labyrinthe d'onglets.
L'UI pfSense a vieilli. Elle reste lisible pour qui la connaît, mais tout administrateur qui débarque la trouve datée. La logique d'organisation par menus (System, Interfaces, Firewall, Services, Status, Diagnostics) est éprouvée mais peu modulable.
Pour une équipe qui fait tourner du firewall en multi-site avec plusieurs admins, l'UI compte. Une UI claire réduit les erreurs de saisie de règles, qui sont la principale cause d'incidents firewall en prod (NIST le documente, comme le font les retours post-mortem internes).
VPN : WireGuard, IPsec, OpenVPN
WireGuard est le critère qui a basculé beaucoup d'opérationnels.
OPNsense : WireGuard intégré au kernel, géré nativement comme une interface réseau. Configuration depuis l'UI, peering, NAT, routage, tout est exposé proprement. La piste idéale pour un VPN site-à-site moderne.
pfSense : historiquement, WireGuard est arrivé en package, puis a été retiré pour problèmes de stabilité, puis réintroduit. Sur Plus, l'intégration s'est améliorée, mais sur CE, la fonctionnalité reste fragile. C'est documenté, ce n'est pas un FUD anti-pfSense.
IPsec est mature des deux côtés (strongSwan-based). OpenVPN tient le terrain sur les deux, avec un léger avantage UX côté OPNsense pour la génération de certificats et profils clients.
Plugins et écosystème
OPNsense gère ses plugins via un repository officiel intégré. Crowdsec, Suricata IDS, Zenarmor, Tinc, FRR, ACME, mod_security, le catalogue est large. Le tooling est cohérent : install, update, uninstall, tout en CLI ou UI.
pfSense gère également des packages, mais l'inventaire est plus restreint et moins maintenu sur CE. Plus garde un avantage sur certains addons commerciaux.
Pour intégrer un IDS de production, notre article Suricata IDS reste valide sur les deux. Pour les listes IP de blocage côté firewall, le plugin OPNsense Crowdsec est un raccourci utile.
API et infrastructure as code
C'est probablement le critère qui décide en 2026 pour une équipe DevOps.
OPNsense expose une API REST documentée et stable. On peut déclarer ses règles, ses interfaces, ses VPN dans un repo Git, les pousser via un module Ansible communautaire ou un provider Terraform. Les pipelines CI peuvent valider les configs avant déploiement, ce qui rejoint la philosophie Terraform IaC ou Ansible config management.
pfSense n'a pas d'API officielle complète sur CE. Un plugin tiers pfSense-API existe mais n'est pas supporté. Plus a une API pfSense Plus REST, mais avec sa propre courbe d'apprentissage et sa licence.
Côté ops, si la cible est de gérer dix firewalls par pipeline GitOps, OPNsense est le choix par défaut.
Hardware et performance
Sur un même hardware, les performances pf brut sont comparables. Les écarts viennent du tuning kernel, des drivers réseau, et du nombre de règles. Quelques ordres de grandeur, validés sur du matériel x86 standard :
| Profil hardware | Throughput typique | Sessions simultanées |
| Mini PC quad-core 8 Go RAM, 2.5 GbE | 1.5 à 2 Gbps | 50 000 |
| Serveur Xeon 16c 32 Go RAM, 10 GbE | 8 à 10 Gbps | 500 000 |
| Serveur Epyc 32c 64 Go RAM, 25 GbE | 18 à 22 Gbps | 1 M+ |
Pour pousser au-delà, on bascule sur des accélérations DPDK ou XDP, qui ne sont pas natives dans pf/pfSense. Sur ce périmètre, des solutions comme FRRouting + nftables sur Linux ou des appliances dédiées prennent le relais.
Côté hardware Netgate, leurs SG-1100, SG-2100, SG-3100 et XG-7100 sont conçus pour pfSense et fournissent un support cohérent. Pour OPNsense, Deciso vend des appliances "DEC" similaires.
Recommandation selon le profil
| Profil | Recommandation |
| Home lab, self-hosted | OPNsense (UI, WireGuard, plugins) |
| PME 50 à 500 postes | OPNsense, sauf engagement Netgate existant |
| Multi-site GitOps | OPNsense (API REST native) |
| Appliance Netgate déjà en place | pfSense Plus (cohérence support) |
| Audit sécurité strict | OPNsense (HardenedBSD, cadence patches) |
| Migration depuis pfSense CE vieillissant | OPNsense (import config partiellement automatique) |
Sur les déploiements qu'on opère pour nos clients, OPNsense gagne 8 cas sur 10 en 2026. Les exceptions sont des contextes où le client a déjà du hardware Netgate amorti, du support Plus payé, et aucun besoin d'API ou de WireGuard moderne.
Pièges et opérations
Quelques points à anticiper, communs aux deux pf-based.
Backup config. Les deux exposent un export XML complet. À versionner dans Git. Sans ça, une restauration post-crash demande une reconfiguration manuelle.
Update. Toujours faire un snapshot ZFS du firewall (les deux supportent ZFS) avant un upgrade majeur. Rollback est trivial avec un dataset cloné.
Multi-WAN. Les deux gèrent. La logique gateway groups est plus claire côté OPNsense, mais le tuning des poids et seuils reste un exercice manuel.
Filtrage L7. Ni l'un ni l'autre n'est une appliance NGFW Palo Alto ou Fortinet. Pour de l'analyse applicative profonde, il faut adjoindre un IDS comme Suricata ou un proxy filtrant en amont.
IPv6. Les deux supportent v6 nativement, mais le tuning pf reste exigeant. Voir nos retours sur le déploiement IPv6 pour le contexte d'ensemble.
Sur les firewalls en bordure de DC ou en site multi-VLAN qu'on opère, le passage à OPNsense après un audit pf/pfSense est désormais la trajectoire qu'on recommande dans la majorité des cas. Si vous opérez encore un parc pfSense CE et que vous voulez chiffrer le coût d'un passage OPNsense (audit règles, plan de migration, tests), on peut auditer votre périmètre réseau et cadrer la bascule avant que vous engagiez le projet.
Sources
- OPNsense official documentation : architecture, plugins, sécurité, releases.
- pfSense documentation - Netgate : référence officielle CE et Plus.
- HardenedBSD project : base sécurisée d'OPNsense, mitigations userland.
- pfSense Plus vs CE - Netgate : positionnement officiel des deux éditions pfSense.
- WireGuard official documentation : référence kernel et userspace, à recouper avec les implémentations FreeBSD.
- FreeBSD pf documentation : base commune pf, qu'OPNsense et pfSense étendent.
