OPNsense s'est imposé comme la référence des firewalls open source en environnement professionnel. Forké depuis pfSense en janvier 2014 par la société néerlandaise Deciso, ce pare-feu s'appuie sur HardenedBSD pour offrir une couche de sécurité supplémentaire par rapport à un FreeBSD standard. Avec ses mises à jour mensuelles prévisibles, son API REST complète et son interface Bootstrap moderne, OPNsense répond aux exigences des PME, des MSP et des laboratoires de sécurité. Selon les données Deciso, plus de 300 000 installations actives tournent dans le monde en 2026. Ce guide couvre l'intégralité du déploiement : choix du matériel, installation sur bare metal ou VM, configuration des interfaces WAN et LAN, mise en place des règles firewall, segmentation VLAN, VPN WireGuard et OpenVPN, protection IDS/IPS avec Suricata, haute disponibilité CARP et load balancing HAProxy. Que vous remplaciez un Cisco ASA vieillissant ou que vous construisiez votre premier réseau sécurisé, ce guide vous accompagne pas à pas.

Présentation d'OPNsense : Historique, Architecture et Différences avec pfSense

OPNsense est né d'un désaccord sur la gouvernance et la transparence du développement de pfSense. En 2014, Ad Schellevis et Jos Schellevis (Deciso) ont forké pfSense 2.1.5 pour créer un projet intégralement open source sous licence Apache 2.0. La différence fondamentale avec pfSense réside dans la base OS : OPNsense utilise HardenedBSD, un fork de FreeBSD qui intègre des protections supplémentaires comme SafeStack, ASLR renforcé et PIE (Position Independent Executables) activé par défaut. Cette base durcie réduit significativement la surface d'attaque exploitable par un attaquant qui aurait réussi à contourner les règles firewall.

L'architecture interne d'OPNsense repose sur le framework MVC (Model-View-Controller) avec Phalcon PHP, une rupture nette avec l'approche monolithique de pfSense. Chaque composant fonctionnel est un plugin distinct, ce qui facilite les mises à jour partielles et réduit le risque d'effet de bord lors des montées de version. Le gestionnaire de packages utilise le format firmware-opnsense-plugin-*, avec plus de 180 plugins officiels disponibles dans les dépôts Deciso.

Le cycle de release mensuel est l'une des forces majeures d'OPNsense. Les versions suivent le schéma YY.M.patch — par exemple 24.7.3 pour la troisième correction de juillet 2024. Chaque release inclut les patchs de sécurité FreeBSD de la période, ce qui garantit une fenêtre d'exposition aux CVE réduite. En comparaison, pfSense Community Edition n'a pas de calendrier de release fixe, ce qui peut laisser des vulnérabilités connues non corrigées pendant plusieurs semaines. Pour un comparatif exhaustif entre les deux solutions, consultez notre article dédié à OPNsense vs pfSense.

OPNsense intègre nativement ZFS comme système de fichiers, ce qui offre des capacités de snapshot et de récupération après corruption que les systèmes UFS ne peuvent pas égaler. Un snapshot automatique est créé avant chaque mise à jour majeure, permettant un rollback en cas de problème. L'API REST complète (documentée via Swagger) ouvre la porte à l'automatisation avec Ansible, Terraform ou des scripts Python — une fonctionnalité critique pour les équipes DevSecOps.

Matériel Recommandé pour OPNsense en Production

Le choix du matériel conditionne directement les performances de votre firewall, notamment le débit de traitement des paquets et la capacité à faire tourner des fonctionnalités gourmandes comme Suricata IDS ou le VPN. Les recommandations suivantes couvrent les configurations les plus courantes.

Configuration minimale (PME jusqu'à 50 utilisateurs, débit 100 Mbps) : processeur x86-64 avec 2 cœurs minimum (Intel Atom C3000 ou équivalent), 4 Go de RAM DDR4, 60 Go SSD mSATA ou M.2, 2 interfaces réseau Intel (chipset i350 ou i210 recommandé pour le support natif FreeBSD). Les cartes réseau Realtek sont à éviter en production : leur driver FreeBSD est moins stable et présente des fuites mémoire connues sous forte charge.

Configuration recommandée (PME jusqu'à 200 utilisateurs, débit 1 Gbps avec IDS) : Intel Core i5 ou Xeon D-1500 (4 cœurs minimum), 8 à 16 Go RAM, SSD NVMe 120 Go, carte réseau Intel 4 ports (i350-T4 ou équivalent), alimentation redondante si criticité élevée. Pour le IPS inline avec Suricata à 1 Gbps, comptez minimum 8 Go RAM car le moteur charge les règles ET Open en RAM au démarrage.

Matériel certifié Deciso : la gamme DEC700/DEC3800 offre des appliances pré-optimisées pour OPNsense avec support constructeur. Pour les laboratoires ou les petites structures, les plateformes PC Engines APU3 (AMD GX-412TC, 4 Go RAM soudée, 3 ports Intel) sont excellentes jusqu'à 500 Mbps.

Prérequis réseau : minimum 2 interfaces physiques (WAN + LAN), idéalement 3 ou 4 pour une DMZ ou une interface management séparée. Les ports IPMI ou iDRAC sont recommandés pour la gestion out-of-band en production. Si vous virtualisez OPNsense (VMware ESXi, Proxmox, Hyper-V), utilisez des interfaces VMXNET3 ou virtio-net plutôt qu'E1000 pour de meilleures performances.

Téléchargement, Création de l'USB Bootable et Installation

Le téléchargement de l'image OPNsense s'effectue depuis opnsense.org — choisissez l'image dvd (ISO) pour un démarrage depuis CD/USB, ou vga pour une installation standard. Les images sont disponibles en 64-bit uniquement (i386 n'est plus supporté depuis la version 21.1). Vérifiez systématiquement la signature SHA-256 avant d'écrire l'image.

Création de l'USB bootable sur Linux ou macOS :

# Identifiez votre clé USB
lsblk  # Linux
diskutil list  # macOS

# Écriture de l'image (remplacez sdX par votre device)
dd if=OPNsense-24.7-dvd-amd64.iso of=/dev/sdX bs=4M status=progress conv=fsync

# Vérification SHA-256
sha256sum OPNsense-24.7-dvd-amd64.iso

Sur Windows, utilisez Rufus en mode DD image (et non mode ISO) pour éviter les problèmes de boot FreeBSD avec les partitions FAT32.

Procédure d'installation step-by-step :

Au démarrage, le menu loader FreeBSD apparaît — attendez ou appuyez sur Entrée. Le système démarre sur un live CD avec le compte installer (mot de passe opnsense) ou root (mot de passe opnsense). Tapez installer pour lancer l'installateur TUI.

1. Welcome : choisissez "Install (ZFS)" — c'est l'option recommandée depuis OPNsense 21.1. UFS reste disponible mais ZFS offre les snapshots automatiques pré-mise à jour.

2. Sélection disque ZFS : choisissez votre SSD cible. Pour la haute disponibilité, vous pouvez créer un miroir RAID-Z1 si vous disposez de deux disques identiques. Attention : le RAID logiciel consomme du CPU.

3. Configuration réseau initiale : l'installateur vous demandera d'assigner vos interfaces. Identifiez WAN et LAN par leurs adresses MAC (vérifiez avec ifconfig -a en shell avant de lancer l'installateur).

4. Mot de passe root : choisissez un mot de passe fort — ce compte est votre dernier recours en cas de perte d'accès à l'interface web.

5. L'installation prend 3 à 10 minutes selon les performances du disque. Le système redémarre automatiquement — retirez la clé USB.

Configuration Initiale : Interfaces, DHCP et DNS Unbound

Après le premier démarrage, accédez à l'interface web via https://192.168.1.1 (adresse LAN par défaut). Ignorez l'avertissement de certificat auto-signé — vous le remplacerez par un certificat valide ultérieurement. Connectez-vous avec root et le mot de passe défini à l'installation.

Assistant de démarrage (Wizard) : OPNsense propose un wizard au premier démarrage. Il couvre le hostname, le domaine, les DNS primaires/secondaires, la configuration WAN (DHCP/Static/PPPoE) et LAN. Pour une connexion PPPoE (fibre Free/Orange), sélectionnez PPPoE et entrez vos identifiants opérateur.

Configuration WAN statique :

Interfaces → WAN
Type de configuration : Static IPv4
Adresse IPv4 : x.x.x.x/prefix
Passerelle : y.y.y.y (créer une nouvelle entrée gateway)

DNS Unbound (résolveur local) : OPNsense utilise Unbound comme résolveur DNS par défaut — plus sécurisé que le forwarder DNS classique car il résout directement depuis les serveurs racines. Activez DNSSEC dans Services → Unbound DNS → Général pour valider les réponses DNS. Les options avancées permettent de blacklister des domaines malveillants via des listes tierces (style Pi-hole).

DHCP Server : configurez le serveur DHCP dans Services → DHCPv4 → LAN. Définissez la plage, le masque, la passerelle et les serveurs DNS. Utilisez les Static Mappings pour assigner des IP fixes aux serveurs et équipements réseau critiques — plus fiable que les baux DHCP réservés.

Le pare-feu OPNsense est stateful par défaut — il maintient une table d'états (pf) qui permet de suivre les connexions établies et d'autoriser automatiquement le trafic de retour sans règle explicite.

Règles Firewall : États, Alias, NAT et Règles Floating

Les règles firewall OPNsense sont basées sur pf (Packet Filter), l'outil de filtrage FreeBSD. Contrairement à iptables Linux, pf utilise un modèle first-match-wins : la première règle qui correspond s'applique. Cette logique requiert d'ordonner les règles du plus spécifique au plus général.

Création d'alias : les alias sont des objets nommés qui regroupent des IPs, réseaux ou ports. Ils sont essentiels pour maintenir des règles lisibles. Créez-les dans Firewall → Alias :

Alias "ADMIN_HOSTS" : Type Host, valeurs 10.0.1.10, 10.0.1.11
Alias "WEB_PORTS" : Type Ports, valeurs 80, 443
Alias "MGMT_SUBNET" : Type Network, valeurs 10.0.100.0/24

Règles LAN typiques :

Action: Pass | Interface: LAN | Source: LAN net | Dest: Any | Port: Any
  → Règle permissive par défaut pour les sorties LAN (à affiner)

Action: Block | Interface: LAN | Source: LAN net | Dest: This Firewall
  → Bloque l'accès direct à l'interface firewall depuis LAN (sauf admin)

Action: Pass | Interface: LAN | Source: ADMIN_HOSTS | Dest: This Firewall | Port: 443, 22
  → Autorise uniquement les hôtes admin à gérer le firewall

NAT (Network Address Translation) : le NAT sortant est configuré dans Firewall → NAT → Outbound. Le mode "Automatic outbound NAT" génère des règles automatiques pour toutes les interfaces. Passez en mode "Manual" pour des cas avancés (plusieurs IPs WAN, SNAT vers des IPs spécifiques).

Port Forward (DNAT) : pour exposer un serveur interne :

Firewall → NAT → Port Forward
Interface : WAN
Protocol : TCP
Dest port range : 443
Redirect target IP : 192.168.1.50 (serveur web interne)
Redirect target port : 443
Cochez "Add associated filter rule"

Règles Floating : les règles floating s'appliquent à toutes les interfaces et peuvent utiliser les directions in, out ou any. Elles sont idéales pour les règles globales de blocage (blocklist IP, limitation de débit) et les règles QoS. Les règles floating sont évaluées avant les règles d'interface.

Pour un SIEM comme Wazuh, il est recommandé de configurer l'export syslog OPNsense vers le SIEM pour centraliser les logs firewall.

VLAN 802.1Q : Segmentation Réseau sur Trunk Switch

La segmentation VLAN est fondamentale pour isoler les zones réseau (serveurs, postes de travail, IoT, invités) et limiter la propagation latérale en cas de compromission. OPNsense gère nativement les VLAN 802.1Q sur les interfaces physiques.

Création d'une interface VLAN dans OPNsense :

Interfaces → Other Types → VLAN → Add
Parent Interface : em1 (interface physique trunk)
VLAN tag : 20
Description : SERVERS

Puis : Interfaces → Assignments
Assigner le VLAN nouvellement créé comme interface SERVERS
Activer l'interface, configurer IP statique 10.0.20.1/24

Configuration switch Cisco IOS pour trunk OPNsense :

interface GigabitEthernet0/1
 description TRUNK-OPNSENSE
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,100
 switchport trunk native vlan 999
 spanning-tree portfast trunk
!

Configuration switch HP/Aruba (ProCurve) :

vlan 20
 name "SERVERS"
 tagged GigabitEthernet1/0/1

Après création des VLAN, ajoutez des règles firewall inter-VLAN selon le principe du moindre privilège : par défaut, bloquez tout trafic entre VLAN, puis autorisez explicitement les flux légitimes (serveur LDAP → postes, imprimantes → serveur impression, etc.). Cette approche micro-segmentation réduit drastiquement la surface d'attaque latérale — un poste compromis dans le VLAN postes ne peut pas atteindre les serveurs directement.

La combinaison OPNsense VLAN + SIEM pour la détection d'anomalies inter-VLAN constitue une architecture de défense en profondeur efficace pour les PME.

VPN WireGuard et OpenVPN : Accès Distants Sécurisés

OPNsense supporte WireGuard nativement depuis la version 21.7 (juillet 2021), intégré directement dans le kernel FreeBSD via le module if_wg. WireGuard est devenu le standard de référence pour les VPN grâce à sa simplicité de configuration, ses performances supérieures et sa surface de code réduite (moins de 4000 lignes de code C vs 400 000 pour OpenVPN).

Configuration WireGuard serveur dans OPNsense :

VPN → WireGuard → Local
Nom : WG-VPN-SERVER
Listen Port : 51820
Tunnel Address : 10.10.0.1/24
Générer les clés avec le bouton dédié (Curve25519)

Ajout d'un peer (client) WireGuard :

VPN → WireGuard → Peers
Public Key : [clé publique du client]
Allowed IPs : 10.10.0.2/32
Endpoint : (laisser vide pour les clients mobiles)

Sur le client (Linux) :

[Interface]
PrivateKey = [clé privée client]
Address = 10.10.0.2/32
DNS = 10.0.1.1

[Peer]
PublicKey = [clé publique OPNsense]
AllowedIPs = 0.0.0.0/0  # full tunnel
Endpoint = votre-ip-wan:51820
PersistentKeepalive = 25

OpenVPN reste pertinent pour la compatibilité avec des clients anciens ou pour les VPN site-à-site complexes. OPNsense propose un wizard OpenVPN dans VPN → OpenVPN → Servers. Choisissez TLS 1.3, cipher AES-256-GCM et auth SHA-512 pour les meilleures pratiques de sécurité. La création d'une CA interne et des certificats clients s'effectue dans System → Trust.

Pour les VPN split-tunnel, définissez IPv4 Remote Networks dans OpenVPN avec uniquement les sous-réseaux internes à router via le VPN, réduisant la charge sur le serveur OPNsense et préservant la bande passante.

IDS/IPS avec Suricata : Détection et Prévention d'Intrusions

OPNsense intègre Suricata pour la détection (IDS) et la prévention (IPS) d'intrusions. En mode IDS, Suricata analyse le trafic en copie et génère des alertes sans bloquer. En mode IPS inline, il s'insère dans le chemin réseau et peut dropper des paquets malveillants en temps réel.

Installation et configuration initiale :

Services → Intrusion Detection → Download
Téléchargez les règles ET Open (Emerging Threats Open) — gratuites
Ou ET Pro (payant) pour des règles plus récentes

Configuration IPS inline :

Services → Intrusion Detection → Settings
Mode : IPS (Inline)
Interface : WAN (et LAN pour détection interne)
Cochez "Promiscuous mode"

Les règles ET Open couvrent les catégories : botnet C2, exploitation, scan, malware, phishing, policy. Désactivez les catégories non pertinentes (peer2peer si vous n'utilisez pas P2P) pour réduire les faux positifs et préserver les performances.

En mode IPS sur 1 Gbps, un CPU avec 4 cœurs physiques est recommandé. Suricata utilise AF_PACKET (Linux) ou netmap (FreeBSD) pour des performances optimales — configurez les workers Suricata à 2-4 selon les cœurs disponibles.

Les alertes Suricata sont visibles dans Services → Intrusion Detection → Alerts et peuvent être exportées vers un SIEM Wazuh via syslog pour corrélation et investigation. Pour un scanner de vulnérabilités complémentaire, consultez notre guide sur Nessus et Greenbone.

Haute Disponibilité avec CARP et Configuration pfsync

CARP (Common Address Redundancy Protocol) est l'équivalent FreeBSD de VRRP/HSRP pour la haute disponibilité. Il permet à deux firewalls OPNsense de partager des IP virtuelles (VIP) avec un mécanisme de failover automatique en cas de panne.

Architecture HA recommandée : deux machines identiques (master + backup), connectées via une interface dédiée pour la synchronisation des états pfsync. Le réseau pfsync synchronise la table d'états pf en temps réel, permettant au backup de reprendre les connexions actives sans interruption lors d'un failover.

Configuration sur le master :

Interfaces → Virtual IPs → Add
Type : CARP
Interface : WAN
IP : [VIP WAN]
Virtual IP password : [mot de passe partagé fort]
VHID : 1 (unique par groupe CARP)
Advertising Frequency : 1/0 (Base/Skew)

Sur le backup, configurez le même VHID avec un Skew de 100 (plus élevé = priorité plus basse). Le master avec le Skew le plus bas gagne.

pfsync pour synchronisation des états :

Interfaces → pfsync
Activer pfsync
Synchronization interface : (interface dédiée HA, ex: em2)
pfsync peer IP : [IP du backup sur ce réseau]

La synchronisation de configuration (XMLSync) permet de répliquer la configuration complète du master vers le backup automatiquement via System → High Availability → Synchronize. Sélectionnez les éléments à synchroniser (firewall rules, aliases, users, certificates).

HAProxy pour Load Balancing et SSL Termination

Le plugin HAProxy pour OPNsense transforme votre firewall en reverse proxy et load balancer de production. Il est idéal pour distribuer le trafic HTTPS entre plusieurs serveurs web, gérer la terminaison SSL/TLS et rediriger le trafic selon des ACL avancées.

Services → HAProxy → Settings
Cochez "Enable HAProxy"

Services → HAProxy → Real Servers
Nom : WEB01 | IP : 192.168.1.10 | Port : 80 | Mode : Active
Nom : WEB02 | IP : 192.168.1.11 | Port : 80 | Mode : Active

Services → HAProxy → Virtual Services (Frontend)
Listen Address : 0.0.0.0:443
SSL offloading : activé (certificat Let's Encrypt via ACME)
Default Backend : WEB-POOL

L'intégration avec le plugin ACME (Let's Encrypt) permet de renouveler automatiquement les certificats SSL/TLS et de les utiliser dans HAProxy pour la terminaison SSL. Cette configuration centralise la gestion TLS et décharge les serveurs backend.

Logs, Tableaux de Bord et Mises à Jour

OPNsense propose un tableau de bord configurable avec des widgets : utilisation CPU/RAM, table d'états, trafic par interface, alertes Suricata récentes, statut VPN. Les logs firewall sont accessibles dans Firewall → Log Files → Live View avec filtrage en temps réel.

La mise à jour d'OPNsense s'effectue depuis System → Firmware → Updates. Le processus crée automatiquement un snapshot ZFS avant la mise à jour — en cas de problème, rebootez en sélectionnant le snapshot précédent dans le menu loader ZFS. Les mises à jour mineures (24.7.1 → 24.7.2) prennent 2-5 minutes, les majeures (24.1 → 24.7) 10-20 minutes avec redémarrage obligatoire.

À retenir

  • OPNsense repose sur HardenedBSD avec ZFS, offrant sécurité renforcée et snapshots automatiques pré-mise à jour
  • WireGuard est intégré nativement depuis la version 21.7 — préférez-le à OpenVPN pour les nouveaux déploiements VPN
  • Le mode IPS inline Suricata requiert minimum 8 Go RAM et 4 cœurs CPU pour un débit de 1 Gbps
  • CARP + pfsync permet une haute disponibilité active/passive avec failover transparent des connexions existantes

Questions fréquentes sur OPNsense

OPNsense peut-il remplacer un firewall Cisco ASA en entreprise ?

Oui, OPNsense peut remplacer un Cisco ASA pour les PME jusqu'à quelques centaines d'utilisateurs. Il offre des fonctionnalités comparables : stateful inspection, VPN IPsec/SSL, IDS/IPS, haute disponibilité CARP. La différence principale est l'absence de support constructeur garanti — Deciso propose des contrats de support, mais ils ne sont pas comparables aux TAC Cisco. Pour les environnements très critiques ou soumis à des contraintes réglementaires strictes (ANSSI CSPN), évaluez soigneusement avant de migrer. Pour les PME et les MSP, le rapport fonctionnalités/coût d'OPNsense est imbattable.

Quelle est la différence entre OPNsense CE et la version Business Edition ?

OPNsense Community Edition (CE) est entièrement gratuite et open source sous licence Apache 2.0. La Business Edition (vendue par Deciso) offre des mises à jour décalées et testées plus longuement (N-1 version), un support contractuel SLA, des plugins entreprise supplémentaires et une garantie de stabilité pour les environnements de production critiques. Pour la majorité des déploiements PME, la CE est amplement suffisante avec ses mises à jour mensuelles régulières.

Comment migrer de pfSense vers OPNsense sans interruption de service ?

La migration directe de pfSense vers OPNsense n'est pas supportée (formats de configuration incompatibles). La procédure recommandée est : 1) Documenter toutes les règles, NAT, VPN et VLAN pfSense. 2) Déployer OPNsense en parallèle sur un hardware séparé. 3) Reconfigurer manuellement les règles en profitant de la migration pour les rationaliser. 4) Tester en environnement non-prod. 5) Planifier une fenêtre de maintenance pour le switch DNS/IP. La migration prend typiquement 4 à 8 heures pour une configuration PME standard. Utilisez le wizard OPNsense et les alias pour recréer les règles plus proprement qu'elles ne l'étaient sur pfSense.

Besoin d'aide pour déployer OPNsense en production ?

Ayi NEDJIMI accompagne les entreprises dans l'architecture et le déploiement de firewalls open source OPNsense. Audit de l'existant, dimensionnement matériel, migration depuis pfSense ou Cisco ASA, formation équipes IT.

Demander un devis gratuit