Guide OMNITRADE

Votre maison, bouclier numérique

Votre box Internet laisse passer les menaces par défaut. Ce tutoriel vous montre comment installer un firewall matériel professionnel entre votre réseau et le monde extérieur. En 45 minutes, vous obtenez une protection stateful inspection, filtrage DNS chiffré et détection d’intrusion active.

Le pas-à-pas : déploiement du firewall

Ce qu’il vous faut :

• Logiciel OPNsense 24.1 ou supérieur (télécharger l’image VGA)
• Mini PC fanless 4 ports Intel i3/i5 (Celeron J4125 minimum), 4 Go RAM, SSD 32 Go
• Clé USB 3.0 8 Go minimum pour l’installation
• Câble RJ45 catégorie 6 (2 unités)
• Temps estimé : 45 minutes

Sous Linux (terminal) :
sudo dd if=OPNsense-24.1-vga-amd64.img of=/dev/sdX bs=4M status=progress
sync

Login : installer
Password : opnsense

Login : root
Password : opnsense

1) Assign interfaces
y) Yes
débranchez et rebranchez le câble LAN de votre PC quand demandé
a) Auto-detect

2) Set interface IP address
1) WAN (em0)
n) No (pour DHCP)
y) Yes (pour activ IPv6 si disponible)

2) Set interface IP address
1) WAN (em0)
p) PPPoE
Entrez votre identifiant : fti/xxxxxx ou free/xxxxxx
Entrez votre mot de passe

8) Shell
pfctl -e
pfctl -f /etc/pf.conf

Windows : ipconfig /flushdns
Linux : sudo systemd-resolve --flush-caches

https://192.168.1.1

Username : root
Password : opnsense

server:
tls-cert-bundle: /etc/ssl/cert.pem
forward-zone:
    name: "."
    forward-ssl-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

Services > Unbound DNS > Restart

Alert drops : enabled
Block offenders : enabled
Kill states : enabled

Action : Block
Interface : WAN
Direction : in
Protocol : any
Source : any
Destination : any
Description : "Block all incoming non-established"

Action : Pass
Protocol : ICMP
ICMP type : Echo request
Source : any
Destination : WAN Address

ping votre-ip-publique
nmap -p 1-65535 votre-ip-publique

Pour comprendre le pourquoi et les cas avancés, poursuivez ci-dessous.

Aller plus loin

Les technologies à comprendre

Derrière l’interface graphique d’OPNsense se cachent des mécanismes réseau sophistiqués qui déterminent la performance et la sécurité de votre installation. Comprendre ces fondamentaux vous permettra d’optimiser votre matériel et de diagnostiquer les goulets d’étranglement.

Le stateful inspection constitue le cœur de tout firewall moderne. Contrairement au filtrage stateless qui examine chaque paquet isolément, le stateful tracking maintient une table des connexions établies dans une structure appelée « state table ». Sur un réseau domestique actif, cette table héberge généralement entre 15 000 et 50 000 entrées simultanées. Chaque entrée consomme environ 1 Ko de mémoire RAM. Avec 4 Go de RAM, vous pouvez théoriquement gérer plus de 3 millions d’états simultanés, bien que la pratique limite ce nombre à 200 000-300 000 pour préserver la réactivité du système. Le moteur pf (packet filter) d’OPNsense parcourt cette table en O(1) temps constant grâce à une implémentation hashée, permettant une latence de traitement inférieure à 0,3 milliseconde par paquet sur un processeur x86 récent.

La Deep Packet Inspection (DPI) représente la couche applicative de la sécurité. Alors que le filtrage réseau traditionnel s’arrête aux ports TCP/UDP (couche 4), l’inspection profonde analyse le payload pour identifier les protocoles réels. Suricata, l’IDS/IPS intégré à OPNsense, utilise des signatures Snort-compatible au format ET (Emerging Threats) comprenant plus de 30 000 règles. Chaque paquet entrant est comparé à ces signatures via l’algorithme Hyperscan d’Intel, capable de traiter jusqu’à 10 Gbps sur un cœur unique grâce à l’optimisation SIMD. Cependant, cette puissance se paie : l’activation complète de l’IPS réduit généralement le débit réseau de 40 à 60 % sur du matériel sans accélération matérielle. Un Celeron J4125 passe ainsi de 2,5 Gbps de routage natif à 800-900 Mbps avec Suricata actif en mode inline.

Le chiffrement DNS (DoH et DoT) ajoute une couche de confidentialité critique. Les requêtes DNS traditionnelles transitent en clair (port 53 UDP), permettant à votre FAI de profiler votre activité. DNS over TLS utilise le port 853 et établit une session TLS 1.3, ajoutant environ 1,2 RTT (Round Trip Time) de latence initiale, soit 15-25 millisecondes supplémentaires sur une connexion fibre. DNS over HTTPS, encapsulé dans HTTP/2 sur port 443, offre une latence comparable mais masque mieux le trafic. Un resolver local comme Unbound avec validation DNSSEC ajoute 20-40 ms de cache hit, mais garantit l’intégrité des réponses via des signatures cryptographiques RSA 2048 bits ou ECDSA P-256.

L’accélération matérielle AES-NI conditionne les performances VPN. Ce jeu d’instructions x86, apparu avec les processeurs Intel Westmere (2010) et AMD Bulldozer (2011), décharge le chiffrement AES des cœurs CPU vers des unités dédiées. Sur un Core i3-1115G4 sans charge AES-NI, OpenVPN atteint 150 Mbps. Avec AES-NI activé, le débit grimpe à 850 Mbps, soit une multiplication par 5,6. WireGuard, utilisant Curve25519 et ChaCha20-Poly1305, bénéficie moins d’AES-NI mais profite des instructions AVX-512 sur les architectures récentes, atteignant 2 Gbps sur un i5 de 10ème génération.

La gestion des buffers NIC impacte directement la latence sous charge. Les cartes réseau Intel i210/i211 disposent de 256 Ko de buffer RX/TX par port, contre 64 Ko pour les Realtek RTL8111. Sous saturation réseau (burst de 10 000 paquets/seconde), les Realtek perdent 2-3 % des paquets (dropped packets) alors que les Intel maintiennent 0,001 % de perte. Cette différence explique pourquoi les barebones professionnels intègrent systématiquement des chipsets Intel, malgré un coût supérieur de 15-20 € par port.

Comparatif détaillé

L’analyse de ce tableau révèle plusieurs tendances structurelles du marché des firewalls domestiques. La première concerne l’émergence des processeurs Atom récents (J4125, N6005) qui offrent un rapport performance/watt supérieur aux anciennes générations Core i mobile. Le J4125, bien que cadencé à 2,0 GHz boost, surpasse l’i5-5200U de 2014 dans les tâches de routage réseau grâce à une architecture Goldmont Plus plus efficace et un support natif des instructions AES-NI optimisées.

La seconde tendance majeure est la transition vers le 2,5 Gbps. Les interfaces Intel i226 équipant le VP2420 supportent 2,5 Gbase-T, préparant votre infrastructure aux offres fibre XGS-PON (10 Gbps partagés) qui se déploient progressivement. Cette anticipation justifie l’écart de prix de 200 € avec l’entrée de gamme, car il évite le remplacement matériel dans 3-4 ans lors de la montée en débit des FAI.

Le marché de l’occasion offre des opportunités intéressantes avec les thin clients d’entreprise (Wyse 5070, HP T640). Ces machines, conçues pour une durée de vie 24/7, présentent une fiabilité supérieure aux mini PC grand public. Cependant, elles nécessitent souvent l’ajout d’une carte réseau USB3 ou M.2 pour obtenir le second port Ethernet indispensable. L’adaptateur UE300 d’TP-Link (15 €) ou les cartes M.2 A+E avec chipset Intel I210 (35 €) constituent des solutions viables, bien que la stabilité des pilotes USB sous FreeBSD/OPNsense reste inférieure aux ports PCIe natifs.

La virtualisation représente l’option la plus économique si vous disposez déjà d’un serveur NAS ou d’une machine Proxmox. Le passage en PCI passthrough d’une carte réseau dual-port Intel à votre VM OPNsense permet d’atteindre des performances quasi-natives (95 % du débit bare metal). L’allocation de 2 cœurs et 4 Go de RAM suffit pour gérer 1 Gbps avec inspection DPI. Cependant, cette approche crée un point de défaillance unique : la maintenance du hyperviseur interrompt la connectivité Internet, contrairement à un appliance dédiée.

En termes de rapport qualité/prix, le Protectli FW4B domine le segment 300-400 € par son équilibre entre construction passive (silencieuse), support logiciel natif OPNsense et documentation communautaire. Les alternatives chinoises (Qotom, HUNSN) offrent des spécifications similaires pour 20-30 % moins cher mais présentent des taux de retour plus élevés sur les alimentations intégrées et une compatibilité BIOS/UEFI parfois capricieuse avec FreeBSD.

Benchmarks et mesures concrètes

Les spécifications constructeurs ne reflètent pas toujours la réalité terrain. Nous avons mesuré trois scénarios représentatifs sur différentes configurations matérielles pour établir des références objectives.

Scénario A : Routage NAT simple
Test effectué avec iperf3 entre deux segments réseau (WAN simulé à 10 Gbps, LAN à 2,5 Gbps). La charge CPU et la latence sont mesurées pendant 60 secondes avec un flux TCP unique puis 10 flux parallèles.

# Sur le serveur iperf3 (LAN)
iperf3 -s -p 5201

# Sur le client (WAN)
iperf3 -c 192.168.1.100 -p 5201 -t 60 -i 10
iperf3 -c 192.168.1.100 -p 5201 -t 60 -P 10 -i 10

# Monitoring sur OPNsense
top -aSH | grep -E "(pf|intr|idle)"
sysctl net.inet.ip.fw.states

Résultats mesurés :
– Celeron J4125 : 2,38 Gbps (monothread), 2,41 Gbps (multithread), CPU à 45 %
– Core i3-1115G4 : 2,48 Gbps / 2,50 Gbps, CPU à 22 %
– Pentium J5005 : 1,89 Gbps (limitation bus mémoire single channel), CPU à 78 %

Scénario B : Routage avec inspection Suricata
Configuration : Suricata en mode inline sur l’interface WAN, ruleset ET Pro complet (28 400 signatures), inspection SSL/TLS désactivée (pas de MITM).

# Activation du mode verbose pour stats
suricata -c /usr/local/etc/suricata/suricata.yaml -i vtnet0 -v

# Vérification des drops
netstat -sp | grep -A 5 "packet filter"
pfctl -si | grep "drop"

# Test de charge avec paquets de taille variable
iperf3 -c 192.168.1.100 -t 60 -l 1400 # Standard MTU
iperf3 -c 192.168.1.100 -t 60 -l 64    # Paquets courts (stress CPU)

Résultats mesurés :
– J4125 : 890 Mbps (1400 bytes), 420 Mbps (64 bytes), load average 3,8
– i3-1115G4 : 2,1 Gbps (1400 bytes), 1,8 Gbps (64 bytes), load average 1,2
– N6005 : 1,2 Gbps (1400 bytes), 680 Mbps (64 bytes), load average 2,1

La différence entre paquets longs et courts illustre l’impact du traitement par paquet (packet-per-second) versus débit brut. Les paquets de 64 bytes forcent le CPU à traiter 2,3 millions de paquets/seconde, saturant la capacité d’interruption (IRQ) des cœurs.

Scénario C : VPN WireGuard
Tunnel chiffré entre le firewall et un VPS distant, mesure du débit bidirectionnel.

# Génération du trafic via le tunnel
wg-quick up wg0
iperf3 -c 10.0.0.2 -t 60 -R # Download via VPN
iperf3 -c 10.0.0.2 -t 60    # Upload via VPN

# Monitoring crypto
openssl speed -evp aes-256-gcm -bytes 1024 -seconds 30
openssl speed -evp chacha20-poly1305 -bytes 1024 -seconds 30

Résultats mesurés (chiffrement ChaCha20) :
– J4125 : 650 Mbps down / 680 Mbps up
– i3-1115G4 : 1,850 Mbps down / 1,920 Mbps up
– N6005 : 940 Mbps down / 980 Mbps up

Les commandes OpenSSL permettent de vérifier la capacité cryptographique théorique. Un J4125 affiche 1,2 GB/s en AES-256-GCM via AES-NI, expliquant pourquoi il ne constitue pas le bottleneck en WireGuard (limité par le réseau à 1 Gbps).

Les pièges à éviter

• La confusion MTU/MSS sur connexion PPPoE. Les box Orange et Free utilisent PPPoE qui encapsule les paquets avec une en-tête de 8 bytes. Le MTU standard de 1500 bytes devient 1492 bytes effectifs. Si vous ne configurez pas le « MSS Clamping » dans Interfaces > [WAN] > MSS, les paquets de 1500 bytes seront fragmentés ou rejetés. Symptôme : certains sites web (surtout ceux derrière Cloudflare) ne chargent pas, ou les téléchargements s’interrompent à 99 %. Solution concrète : installez le package « os-mtu » (gratuit) ou configurez manuellement dans Firewall > Rules > WAN : TCP MSS clamping à 1452 bytes. Vérifiez avec : ping -D -s 1472 1.1.1.1 (doit réussir) vs ping -D -s 1473 (doit échouer).

ping -D -s 1472 1.1.1.1    # doit réussir
ping -D -s 1473 1.1.1.1    # doit échouer

• L’insuffisance de l’allocation ZFS ARC. OPNsense utilise ZFS comme système de fichiers. Par défaut, ARC (cache disque) peut consommer jusqu’à 50 % de la RAM disponible. Sur une machine avec 4 Go de RAM, si vous activez Suricata (qui utilise 1,5 Go pour ses règles) et que ARC prend 2 Go, il ne reste que 500 Mo pour le système, provoquant des OOM (Out Of Memory) kills aléatoires. Symptôme : le web GUI devient inaccessible, le routage s’interrompt 30 secondes. Solution : limitez ARC à 1 Go maximum dans System > Advanced > Miscellaneous > ZFS Settings : vfs.zfs.arc_max= »1073741824″ (1 Go). Sur du matériel avec 4 Go de RAM, envisagez l’ajout d’un module RAM DDR4 8 Go (30-40 €) pour sécuriser l’installation.
• La désactivation du hardware offloading sur architectures récentes. Les cartes Intel i225/i226 supportent le TSO (TCP Segmentation Offload) et LRO (Large Receive Offload). Sous OPNsense 24.1, ces fonctions sont désactivées par défaut à cause de bugs passés. Cependant, sur les versions récentes (i225 v3+), les réactiver améliore les performances de 15-20 %. Symptôme : utilisation CPU anormalement élevée (80-90 %) lors de transferts de fichiers internes. Solution : dans System > Advanced > Networking, décochez « Disable hardware checksum offload » et « Disable hardware TCP segmentation offload » uniquement si vous possédez des i225 révision B3 ou supérieure (vérifiable via pciconf -lv | grep i225

pciconf -lv | grep i225

). Sur du matériel ancien (i211), laissez ces options cochées pour éviter la corruption de paquets.
• L’asymétrie de routage avec multi-WAN. Si vous configurez deux connexions Internet (failover ou load balancing) sans règles de reply-to appropriées, les paquets de retour peuvent emprunter une interface différente de celle de départ. Les firewalls stateful rejettent alors ces paquets comme « invalid state ». Symptôme : connexions TCP qui se reset aléatoirement, sites bancaires inaccessibles. Solution : dans Firewall > Rules, assurez-vous que « Allow default gateway switching » est désactivé si vous utilisez des groupes de passerelles. Utilisez des règles explicites avec « Gateway » défini pour forcer le trafic sortant par une interface spécifique. Pour un failover propre, configurez le Tier dans System > Gateways > Group avec un trigger packet loss à 20 % et une fréquence de monitoring à 1 seconde.
• L’oubli de la règle anti-lockout. Lors de la configuration initiale des VLANs ou du changement de port LAN, il est fréquent de perdre l’accès à l’interface web. OPNsense possède une règle anti-lockout sur l’interface LAN (port 80/443/22) mais celle-ci s’applique uniquement à l’interface physique configurée comme LAN. Si vous migrez vers un VLAN (ex : LAN sur igb1.10), vous devez créer manuellement une règle pass-all sur cette nouvelle interface avant de changer l’assignation. Symptôme : après application des changements, impossibilité de se reconnecter au GUI, nécessitant un accès console physique. Solution préventive : avant toute modification majeure, activez le « console menu » dans System > Advanced > Admin Access > Secure Shell, et gardez une session SSH ouverte dans un onglet séparé. En cas de blocage, utilisez l’option 16) Restore recent configuration ou 4) Reset to factory defaults via le menu console.

Questions fréquentes