Exécuter OPNsense comme VM pare-feu sur Proxmox

D'abord la réponse : quand un pare-feu virtuel a du sens

Faire tourner OPNsense comme guest Proxmox est un schéma éprouvé, viable en production, avec un profil clair de quand c'est le bon choix :

Faites-le quand le rôle du pare-feu est de protéger le parc virtuel : une VM OPNsense comme passerelle pour vos autres guests vous donne le routage inter-VLAN, une vraie DMZ, la terminaison VPN et l'IDS/IPS pour tout ce qui se trouve derrière, plus les dividendes de la virtualisation : snapshot avant chaque mise à jour, restauration de config en quelques minutes, et pas de second châssis à louer. Sur un seul serveur dédié hébergeant de nombreuses VM, c'est l'architecture naturelle.

Réfléchissez à deux fois quand le pare-feu doit être indépendant de l'hyperviseur (si OPNsense est le périmètre pour une infrastructure au-delà de cet hôte, chaque redémarrage de Proxmox emporte votre réseau avec lui) ou quand vous avez besoin de chaque gigabit avec des offloads matériels, où le bare metal (ou le passthrough de carte réseau) garde encore l'avantage.

Une règle d'architecture à poser d'emblée, apprise à la dure par tous ceux qui l'ont ignorée : ne rendez jamais l'interface de gestion propre de l'hôte Proxmox dépendante de la VM OPNsense. Le SSH/UI web de l'hôte doit rester joignable par son propre chemin ; sinon une VM pare-feu qui ne démarre plus vous verrouille hors de l'hyperviseur même depuis lequel vous la répareriez. (Le KVM-over-IP est le filet de sécurité, mais ne concevez pas votre architecture pour en avoir besoin.)

Architecture réseau sur un serveur dédié

Cela s'appuie directement sur le modèle de bridges de notre guide réseau Proxmox. OPNsense devient simplement un guest avec une patte dans deux (ou plusieurs) bridges :

• WAN : une carte réseau virtuelle sur vmbr0 (le bridge public), configurée avec une IP publique supplémentaire attribuée à votre serveur, en respectant la politique MAC du fournisseur, exactement comme pour tout guest en bridge. Sur notre réseau, les IP supplémentaires sont incluses avec le serveur et cela fonctionne d'emblée.
• LAN : une carte réseau virtuelle sur un bridge interne (bridge-ports none, un switch sans uplink, par ex. vmbr1). Chaque guest qui doit vivre derrière le pare-feu s'y connecte et utilise l'adresse LAN d'OPNsense comme passerelle.
• Plus de segments : soit davantage de bridges internes, soit (plus propre à grande échelle) un seul bridge interne compatible VLAN, où OPNsense prend un trunk et route entre les segments taggés. Cela donne une DMZ, un réseau de gestion et un lab, tous filtrés en un seul point.

L'hôte Proxmox lui-même garde son IP de gestion sur vmbr0 (ou mieux, une interface de gestion dédiée), pas derrière la VM OPNsense, selon la règle ci-dessus. Les guests bénéficient d'une défense en profondeur : notre pare-feu de périphérie réseau en amont, OPNsense à la frontière du segment, et des règles sur l'hôte lui-même dans chaque guest où c'est justifié.

La configuration de VM qui fonctionne

La communauté (et le HOWTO de virtualisation bien tenu à jour sur le forum officiel d'OPNsense) a convergé vers une recette ; c'est en s'en écartant qu'on trouve les bugs mystérieux :

Honnêteté sur le dimensionnement : les recommandations matérielles officielles d'OPNsense plafonnent leurs paliers à "750+ Mbit/s" pour la spec "recommended" à 8 GB, et ne publient aucun chiffre exact pour un gigabit virtualisé ; la recette 2–4 vCPU / 4–8 GB est une recommandation établie par la communauté, confortable pour router un gigabit avec un ruleset normal. La RAM de la state-table est rarement le problème (environ 1 KB par état de connexion) ; l'IDS/IPS Suricata, lui, l'est : l'inspection inline est gourmande en CPU et c'est ce qui pousse une petite VM pare-feu vers 4+ cœurs.

La note sur l'offloading qui vous épargne un week-end

Douleur historique : les cartes VirtIO combinées à l'offload matériel des checksums sur des guests FreeBSD provoquaient des paquets perdus et une connectivité cassée. L'OPNsense moderne livre déjà la bonne réponse : l'offloading checksum/TSO/LRO matériel est désactivé par défaut (Interfaces → Settings). Le conseil concret en 2026 est donc : vérifiez que ces cases restent cochées ("disable") et ne les "optimisez" pas en les réactivant sur les interfaces VirtIO. Si une VM OPNsense fait passer le trafic bizarrement (certains sites chargent, d'autres restent bloqués), ce réglage est le suspect numéro un.

Installation, en condensé

1. Uploadez l'ISO d'installation d'OPNsense (série actuelle : 26.1 ; le projet livre deux versions majeures par an, en janvier et juillet) vers Proxmox et démarrez la VM dessus.
2. Connectez-vous en tant que installer, installez sur disque en choisissant ZFS, redémarrez.
3. À la console, assignez les interfaces : les cartes VirtIO apparaissent comme vtnet0, vtnet1… Faites-les correspondre à WAN/LAN via les adresses MAC affichées dans le panneau matériel de Proxmox (rendez-les mémorablement distinctes à la création de la VM ; votre futur vous dira merci).
4. Réglez WAN sur votre IP publique/passerelle attribuée et LAN sur votre plage interne (par ex. 10.0.0.1/24), puis ouvrez l'interface web depuis un guest sur le bridge LAN (ou via un tunnel SSH à travers l'hôte) et lancez l'assistant de configuration.
5. Premières étapes après l'assistant : mettre à jour vers la version actuelle, installer os-qemu-guest-agent, prendre votre premier snapshot.

C'est dans l'exploitation au quotidien que le format VM brille : snapshot → mise à jour → vérification → suppression du snapshot transforme les versions majeures semestrielles d'OPNsense d'un risque de maintenance en un non-événement, et PBS sauvegarde tout le pare-feu chaque nuit comme n'importe quel autre guest.

Et pfSense ?

La même recette s'applique presque mot pour mot à pfSense, également FreeBSD, également à l'aise avec VirtIO. Entre les deux : pfSense CE reste vivant (2.8.x actuel, 2.9 en développement) aux côtés du pfSense Plus commercial, tandis que la cadence prévisible de deux versions majeures par an d'OPNsense, son modèle entièrement ouvert et son interface moderne en ont fait la recommandation par défaut dans le monde du self-hosting ces dernières années. Si vous en connaissez déjà un, utilisez-le ; si vous partez de zéro, ce guide a choisi OPNsense délibérément.

Questions fréquentes

Faut-il faire du passthrough d'une carte réseau physique vers OPNsense plutôt que d'utiliser VirtIO ?

Optez par défaut pour VirtIO : c'est la recommandation actuelle de la communauté, cela garde la VM entièrement virtuelle (snapshots, migration, pas de bricolage avec l'IOMMU), et cela route un gigabit sans souci. Le passthrough PCI justifie sa complexité dans deux cas : chercher le débit maximal avec des offloads matériels sur des liens multi-gigabit, ou vouloir isoler physiquement le câble WAN de la pile réseau de l'hyperviseur. En cas de passthrough, la VM perd la migration à chaud et le confort des snapshots. Vous abandonnez alors précisément les raisons de virtualiser.

OPNsense protège-t-il aussi l'hôte Proxmox ?

Pas dans cette architecture. Et ce n'est pas souhaitable. Le plan de gestion de l'hôte reste sur son propre chemin (délibérément pas derrière la VM pare-feu), protégé à la place par le pare-feu de périphérie en amont, ses propres règles, et en n'exposant jamais l'interface web (port 8006) publiquement. Router le trafic de l'hôte lui-même via un guest qu'il héberge crée une dépendance circulaire avec exactement un mode de défaillance : le verrouillage total. Les guests derrière OPNsense ; l'hôte à côté, durci indépendamment.

Quelle performance perd-on par rapport au bare metal ?

Pour du simple routage/NAT à l'échelle du gigabit sur des cœurs modernes : assez peu pour que le confort de VirtIO l'emporte : les paliers de spec officiels placent même du matériel modeste dans la classe "750+ Mbit/s", et une VM correctement configurée se situe dans cette fourchette. Les coûts honnêtes apparaissent aux extrêmes : le débit multi-gigabit (l'overhead par paquet du réseau paravirtualisé s'accumule ; envisagez le passthrough) et l'IDS/IPS (l'inspection de Suricata est la vraie facture CPU, où qu'elle tourne). Mesurez votre propre situation avant d'optimiser, et voyez le benchmark de la rédaction ci-dessus.

Peut-on faire tourner cela en haute disponibilité ?

CARP (le failover façon VRRP d'OPNsense) fonctionne virtualisé, mais réfléchissez à ce que cela apporte réellement sur un seul hôte : deux VM pare-feu sur le même hyperviseur partagent chaque mode de défaillance matérielle, donc le CARP intra-hôte couvre surtout les fenêtres de mise à jour, que les snapshots gèrent déjà. Une vraie HA de pare-feu signifie des VM OPNsense sur deux hôtes avec les segments LAN qui les traversent (VLAN sur du réseau privé, ou VXLAN via Proxmox SDN), ce qui vaut le coup quand les guests derrière justifient une architecture de niveau cluster en général.

Déployer sur Serverside

Tout ce dont ce schéma a besoin est inclus ici avec un serveur dédié Proxmox : des IP publiques supplémentaires pour la patte WAN, du réseau privé qui porte vos VLAN entre hôtes pour les architectures multi-serveurs, une mitigation DDoS toujours active en amont de tout le dispositif, et le KVM-over-IP comme filet contre le verrouillage. Proxmox est préinstallé ; l'ISO d'OPNsense n'est qu'à un upload.

Complétez avec l'approfondissement réseau Proxmox sur lequel repose cette architecture, les stratégies de sauvegarde pour la VM pare-feu elle-même, et (pour l'alternative WireGuard-native au niveau routage) notre guide site-à-site VyOS.