Installer et configurer OPNsense dans Proxmox VE : WAN + WAN backup, LAN, DMZ et tunnel WireGuard site-a-site

OPNsense est un pare-feu open source dérivé de FreeBSD, maintenu par Deciso depuis 2015. Fork de pfSense, il se distingue par une interface web moderne, un rythme de mises à jour soutenu et une communauté active. Ce guide décrit la mise en place d’OPNsense dans une VM Proxmox, avec une architecture réseau composée de :

1. Prérequis et hypothèses

Matériel et réseau

Pour reproduire cette architecture, l’hote Proxmox doit disposer d’au minimum trois interfaces réseau physiques (NIC). La documentation officielle de Proxmox VE recommande l’usage de bridges Linux pour relier les VM aux réseaux physiques. Chaque bridge correspond à un domaine de diffusion L2 distinct, ce qui garantit une séparation nette des flux.

Un switch ménageable est recommandé pour segmenter LAN et DMZ en VLAN sur un trunk 802.1Q. Les cartes réseau Intel (famille I210, I350, X520) sont privilégiées par la communauté FreeBSD et OPNsense pour leur stabilité et leurs pilotes natifs performants.

Coté Proxmox VE, la version 8.x est conseillée (Debian 12 Bookworm). Nous nous assurons que la virtualisation matérielle (VT-x/AMD-V) est activée dans le BIOS/UEFI du serveur.

Plan d’adressage (exemple)

2. Schéma d’architecture

Le schéma ci-dessous illustre la topologie logique de l’installation. L’hôte Proxmox expose trois bridges Linux à la VM OPNsense, qui segmente ensuite le trafic entre les différentes zones.

3. Configuration réseau cote Proxmox : bridges et segmentation

La configuration réseau de l’hôte Proxmox constitue le socle de toute l’architecture. Le principe fondamental est simple : un bridge Linux par domaine de diffusion L2. Proxmox VE utilise nativement les bridges Linux (nommes vmbrX) pour connecter les VM au réseau physique. La documentation officielle Proxmox détaille cette approche dans la section Network Configuration.

# ================================================================
# Proxmox VE - /etc/network/interfaces
# Adaptez les noms d'interface selon le matériel
# (eno1/eno2/eno3, enp1s0/enp2s0/enp3s0, etc.)
# ================================================================
auto lo
iface lo inet loopback
# --- NIC1 : WAN (pas d'IP sur l'interface physique) ---
auto eno1
iface eno1 inet manual
auto vmbr-wan
iface vmbr-wan inet manual
bridge-ports eno1
bridge-stp off
bridge-fd 0
# Pas d'adresse IP : ce bridge est exclusivement
# reserve au trafic WAN de la VM OPNsense.
# --- NIC2 : WAN backup (4G/5G, second FAI) ---
auto eno2
iface eno2 inet manual
auto vmbr-wan2
iface vmbr-wan2 inet manual
bridge-ports eno2
bridge-stp off
bridge-fd 0
# Meme logique : pas d'IP cote Proxmox.
# --- NIC3 : trunk interne (LAN + DMZ en VLAN) ---
auto eno3
iface eno3 inet manual
auto vmbr-trunk
iface vmbr-trunk inet static
address 192.168.10.254/24
gateway 192.168.10.1
bridge-ports eno3
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20
# L'IP 192.168.10.254 sert de management Proxmox
# via le VLAN LAN. La gateway pointe vers OPNsense.

# Appliquer la configuration réseau sans redémarrage
ifreload -a
# Verifier les bridges actifs
bridge link
bridge vlan show
ip -br link

4. Création de la VM OPNsense dans Proxmox

Télécharger l’ISO OPNsense

Nous nous rendons sur la page de téléchargement officielle d’OPNsense (opnsense.org/download). On sélectionne l’image DVD au format amd64 avec le moteur de chiffrement OpenSSL. Le fichier téléchargé est compresse en .bz2 et doit être extrait avant usage.

# ================================================================
# Déposer l'ISO dans le stockage local de Proxmox
# ================================================================
cd /var/lib/vz/template/iso
# Télécharger l'ISO (remplacez l'URL par la version courante)
wget https://mirror.dns-root.de/opnsense/releases/25.1/OPNsense-25.1-dvd-amd64.iso.bz2
# Extraire l'archive
bunzip2 OPNsense-25.1-dvd-amd64.iso.bz2
# Vérifier la présence du fichier
ls -lh OPNsense-*.iso

Créer la VM en ligne de commande (qm)

La création en CLI offre un contrôle précis et la possibilité de scripter le déploiement. OPNsense, basé sur FreeBSD, supporte les pilotes VirtIO de manière fiable depuis plusieurs versions. La communauté recommande néanmoins de garder e1000 sous le coude pour les rares cas de régression.

# ================================================================
# Création de la VM OPNsense (VMID 120)
# ================================================================
VMID=120
# Créer la VM avec les ressources de base
qm create $VMID \
--name opnsense \
--memory 4096 \
--cores 2 \
--cpu host \
--ostype other
# Disque système (20 Go minimum, VirtIO SCSI)
qm set $VMID \
--scsihw virtio-scsi-pci \
--scsi0 local-lvm:20
# Ordre de boot et ISO
qm set $VMID \
--boot order=scsi0 \
--ide2 local:iso/OPNsense-25.1-dvd-amd64.iso,media=cdrom
# Console série (utile pour le debug pre-GUI)
qm set $VMID \
--serial0 socket \
--vga serial0

# ================================================================
# Interfaces réseau : 4 vNIC VirtIO
# ================================================================
# net0 = WAN (bridge vmbr-wan, pas de VLAN)
qm set $VMID --net0 virtio,bridge=vmbr-wan
# net1 = WAN backup (bridge vmbr-wan2, pas de VLAN)
qm set $VMID --net1 virtio,bridge=vmbr-wan2
# net2 = LAN (bridge vmbr-trunk, VLAN 10)
qm set $VMID --net2 virtio,bridge=vmbr-trunk,tag=10
# net3 = DMZ (bridge vmbr-trunk, VLAN 20)
qm set $VMID --net3 virtio,bridge=vmbr-trunk,tag=20

# ================================================================
# Démarrer la VM
# ================================================================
qm start $VMID

Pour visualiser la configuration complète de la VM :

# Afficher la configuration de la VM
qm config 120

5. Installation d’OPNsense dans la VM

Au démarrage de la VM sur l’ISO, OPNsense lance un environnement live. Un prompt vous propose de démarrer l’assignation manuelle des interfaces. Voici la séquence d’installation :

# ================================================================
# Retirer l'ISO après installation (depuis Proxmox)
# ================================================================
qm set 120 --ide2 none
# Vérifications en console OPNsense (shell FreeBSD)
ifconfig # Lister les interfaces et leurs IP
netstat -rn # Table de routage
ping -c3 8.8.8.8 # Test de connectivité WAN

6. Affectation des interfaces dans OPNsense

Une fois l’installation terminée et l’accès a la GUI établi, la première tache consiste à déclarer toutes les interfaces réseau. Dans le menu Interfaces > Assignments, les quatre interfaces virtuelles (vtnet0 a vtnet3) doivent apparaitre. On assigne comme suit :

Pour chaque interface, rendez-vous dans Interfaces > [NomInterface] pour activer l’interface et définir sa configuration IP. Nous pouvons activer le serveur DHCP sur le LAN (Services > ISC DHCPv4 > [LAN]) si les postes en ont besoin. Sur la DMZ, il est préférable de configurer les adresses IP de manière statique, ou de limiter le DHCP à un nombre très restreint de baux.

On pense à appliquer les modifications et à vérifier depuis la console OPNsense que chaque interface est bien active :

# Vérifier l’état des interfaces (console OPNsense)
ifconfig vtnet0 # WAN
ifconfig vtnet1 # WAN_BACKUP
ifconfig vtnet2 # LAN
ifconfig vtnet3 # DMZ

7. Multi-WAN : failover entre WAN principal et WAN de secours

Le Multi-WAN est l’un des atouts majeurs d’OPNsense. Le mécanisme repose sur la surveillance active des passerelles (gateways) par le service dpinger, qui envoie des requêtes ICMP régulières vers une IP de référence (monitor IP). Lorsqu’une passerelle est déclarée indisponible (perte de paquets, latence excessive), le groupe de passerelles bascule automatiquement sur le lien de secours. La documentation OPNsense précise que cette technologie s’appuie sur le routage base sur les politiques (policy-based routing), integré au firewall pf.

7.1 Vérifier et configurer les passerelles

Rendez-vous dans System > Gateways > Configuration. Si les interfaces WAN sont configurées en DHCP, les passerelles sont normalement créées automatiquement. On vérifie les points suivants pour chaque passerelle :

7.2 Créer un groupe de passerelles (Gateway Group)

Dans System > Gateways > Group, on crée un nouveau groupe :

7.3 Activer le basculement par defaut

Deux réglages supplémentaires sont indispensables au bon fonctionnement du failover :

7.4 Appliquer le groupe via les règles firewall (policy-based routing)

Le failover ne s’active pas « tout seul » : il faut l’appliquer explicitement dans les règles firewall des interfaces internes. Rendez-vous dans Firewall > Rules > LAN, on édite la règle principale (par exemple « LAN net > any ») et on défini le champ Gateway sur le groupe WAN_FAILOVER. On fait de même pour les règles de la DMZ si les serveurs DMZ doivent aussi bénéficier du failover.

7.5 NAT sortant en Multi-WAN

C’est le point de friction le plus fréquent en dual-WAN. Par défaut, OPNsense génère des règles NAT sortant uniquement pour l’interface WAN principale. Lors d’un basculement, le trafic sort par WAN_BACKUP mais la règle de traduction d’adresse peut manquer.
Pour corriger ce problème :

# ================================================================
# Exemple de règles NAT Outbound (resume)
# ================================================================
# Source Interface NAT Address
# 192.168.10.0/24 WAN WAN address
# 192.168.10.0/24 WAN_BACKUP WAN_BACKUP address
# 192.168.20.0/24 WAN WAN address
# 192.168.20.0/24 WAN_BACKUP WAN_BACKUP address

8. Configurer une DMZ sécurisée

Une DMZ n’est pas un second LAN. C’est une zone à risque élevé : les machines qui y résident sont exposées à Internet (par exemple un serveur web ou un reverse proxy). Le principe de sécurité fondamental est le suivant : la DMZ peut accéder à Internet de manière contrôlée, mais elle ne doit jamais pouvoir initier une connexion vers le LAN, sauf exception explicite et justifiée.

8.1 Règles firewall pour la DMZ

On construi les règles de la DMZ selon une logique de refus implicite (implicit deny) : tout ce qui n’est pas explicitement autorisé est bloqué. Voici un modèle de règles, à adapter :

L’ordre des règles est déterminant : OPNsense (via pf) les évalue de haut en bas et s’arrête à la première correspondance. La règle de blocage DMZ vers LAN doit figurer avant toute règle « allow to any » pour être effective.

Pour créer des exceptions granulaires (par exemple : un serveur DMZ qui doit interroger une base de données sur le LAN), on ajoute une règle au-dessus de la règle de blocage, en spécifiant l’IP source, l’IP destination et le port exact.

8.2 Publication de services : NAT entrant (Port Forward)

Pour exposer un service hébergé en DMZ (par exemple un serveur web HTTPS), on configure une redirection de port :

Pour renforcer la sécurité de ce type d’exposition, il faut envisager l’ajout d’un reverse proxy (HAProxy par exemple, plugin disponible dans OPNsense) ou d’un WAF (Web Application Firewall). On limite les IP source autorisées via des alias si le service n’est destiné qu’a un public restreint.

8.3 Alias : simplifier la gestion des règles

OPNsense permet de créer des alias (Firewall > Aliases) pour regrouper des adresses IP, des ports ou des sous-réseaux. Par exemple :

• Private_Networks : alias contenant 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
• DMZ_Webservers : alias contenant les IP des serveurs web en DMZ.
• Web_Ports : alias contenant les ports 80 et 443.

9. Tunnel WireGuard site-à-site vers un réseau distant

WireGuard est un protocole VPN moderne, intégré au noyau FreeBSD depuis la version 13 (et donc nativement supporte par OPNsense). Son code minimaliste (environ 4 000 lignes) et ses performances élevées en font un choix pertinent pour les tunnels site-à-site, en particulier en environnement virtualisé ou la réduction de l’overhead CPU est appréciable.

Dans notre scenario, le tunnel relie le LAN local (192.168.10.0/24) au réseau distant (172.16.50.0/24) via un réseau de transit 10.99.0.0/30.

9.1 Installer et activer WireGuard

Depuis OPNsense 24.1, WireGuard est intégré au système de base. Pour l’utilisation d’une version antérieure, il faudra installer le plugin via System > Firmware > Plugins en recherchant os-wireguard.

Activation du service : VPN > WireGuard > Settings > General, on coche « Enable WireGuard » puis on Apply.

9.2 Créer l’instance WireGuard locale

Dans VPN > WireGuard > Instances, on clique sur « + » pour ajouter une nouvelle instance :

9.3 Déclarer le peer (site distant)

Dans VPN > WireGuard > Peers, ajoutez un nouveau peer :

Les Allowed IPs ont un double role dans WireGuard : elles définissent à la fois les routes (quels réseaux sont accessibles via ce peer) et le filtrage (seuls les paquets provenant de ces sous-réseaux sont acceptés en retour). La documentation OPNsense insiste sur l’importance de ne pas utiliser 0.0.0.0/0 dans un tunnel site-à-site, sauf si vous souhaitez explicitement router tout le trafic par le tunnel.

9.4 Assigner l’interface wg0 et configurer le firewall

Pour bénéficier de règles firewall dédiées au tunnel, il est recommandé d’assigner l’interface WireGuard :

On configure ensuite les règles firewall :

9.5 Règle de normalisation (MSS clamping)

Un point souvent négligé : les tunnels VPN réduisent la MTU effective. Sans ajustement, certaines sessions TCP (HTTPS notamment) peuvent échouer silencieusement. La documentation officielle OPNsense recommande de créer une règle de normalisation :

9.6 Vérification du tunnel

# ================================================================
# Diagnostic WireGuard (console OPNsense / shell FreeBSD)
# ================================================================
# Etat du tunnel et dernière poignée de main
wg show
# Vérifier que le port UDP 51820 est en écoute
sockstat -4 -l | grep 51820
# Table de routage (vérifier les routes via wg0)
netstat -rn | grep wg
# Test de connectivité vers le peer
ping -c3 10.99.0.2
# Test de connectivité vers le réseau distant
ping -c3 172.16.50.1

Dans la sortie de wg show, on vérifie que le champ latest handshake affiche un horodatage récent et que les compteurs transfer montrent du trafic dans les deux sens. Si le handshake n’a pas lieu, on vérifie la règle firewall WAN (port UDP 51820) et les clés publiques échangées.

10. Tests et validation

Avant de déclarer l’infrastructure en production, une série de tests méthodiques permet de valider chaque composant de l’architecture.

10.1 Connectivite par zone

10.2 Test du failover WAN

Pour valider le basculement automatique :

10.3 Commandes utiles cote Proxmox

# ================================================================
# Diagnostic réseau sur l'hote Proxmox
# ================================================================
# Etat des interfaces et bridges
ip -br link
ip -br addr
# Détail des bridges et VLAN
bridge link
bridge vlan show
# Configuration de la VM OPNsense
qm config 120
# Surveillance des logs réseau
journalctl -f -u networking

11. Sécurité et durcissement

La mise en place de l’architecture n’est que la première étape. Le durcissement de l’ensemble est indispensable pour atteindre un niveau de sécurité satisfaisant.

Administration OPNsense : On restreindra l’accès à la GUI et au SSH d’OPNsense au seul réseau LAN (ou mieux : à un VLAN d’administration dédié). On désactivera la règle anti-lockout par défaut et on la remplacera par une règle explicite limitée aux postes d’administration identifiés.

DMZ : On appliquera le principe du moindre privilège. Chaque serveur DMZ ne doit avoir accès qu’aux ressources strictement nécessaires à son fonctionnement. La règle « deny DMZ vers LAN » doivra être explicite et positionnée en haut de la liste. Les exceptions doivront être documentées.

WireGuard : On maintiendra les Allowed IPs au strict nécessaire. On évitera 0.0.0.0/0 dans un tunnel site-à-site. On activera le keepalive uniquement si l’un des endpoints est derrière un NAT. Et on surveillera le tunnel via les logs et le monitoring de la passerelle WireGuard.

Multi-WAN : On choisissera des monitor IP fiables et distinctes pour chaque passerelle. On vérifiera régulierement que le NAT sortant couvre les deux interfaces WAN. Et on Testera le failover périodiquement.

Proxmox : On ne mélangera jamais un bridge WAN et un bridge interne. Le bridge WAN ne devra porter aucune adresse IP cote Proxmox. On Maintiendra un accès hors bande (IPMI, console physique, port de management dédié) pour administrer l’hyperviseur en cas de panne de la VM OPNsense.

Mises a jour : On planifiera les mises à jour d’OPNsense via System > Firmware > Updates et celles de Proxmox VE via apt update && apt dist-upgrade. On Prendra un snapshot de la VM avant chaque mise à jour majeure et on fera des backup de la VM via le système de de backup de Proxmox ou via autre solution comme VEEM ou Proxmox Backup Server.

12. Points de friction connus et arbitrages

VirtIO ou e1000 : performance contre prudence

FreeBSD (et donc OPNsense) supporte bien les pilotes VirtIO, qui offrent des performances réseau supérieures et un overhead CPU réduit par rapport à l’emulation e1000. La majorité des déploiements fonctionnent sans problème avec VirtIO. Toutefois, certains retours de la communaute (forums Proxmox et OPNsense) mentionnent des régressions ponctuelles avec VirtIO dans des configurations spécifiques (Open vSwitch sur le WAN, high throughput > 1 Gbps).

Failover actif mais plus d’accès Internet

Ce symptome est presque toujours lié au NAT sortant ou au DNS. Lors du basculement vers WAN_BACKUP, si aucune règle NAT n’existe pour cette interface, le trafic sort mais avec une adresse source non traduite, ce qui rend les réponses impossibles. De même, si le resolver DNS d’OPNsense n’est pas configuré pour suivre le changement de passerelle, les requêtes DNS échouent alors que le lien est fonctionnel.

WireGuard : tunnel établi mais pas de trafic

Si wg show affiche un handshake valide mais que le trafic ne passe pas, il faudra vérifier trois points : les Allowed IPs du peer (doivent inclure le réseau distant), les règles firewall sur l’interface WG_SITE, et la règle de normalisation (MSS clamping). L’absence de MSS clamping est une cause fréquente d’échec des connexions TCP à travers un tunnel.

Conclusion

Nous virtualisons OPNsense sous Proxmox VE car c’est une solution éprouvée, adaptée pour les homelabs.

Par contre il faudra prendre le temps de tester chaque composant de manière isolée (connectivité WAN, failover, isolation DMZ, tunnel WireGuard) avant de les combiner. Documenter l’architecture et les règles firewall. Deplus en cas de doute, la documentation officielle d’OPNsense et les forums de la communauté sont des ressources précieuses pour croiser les informations et résoudre les problèmes spécifiques à chaque environnement.

C’était Zérosécu, et comme je dis toujours, la cybersécurité est moins cher que gratuit.

J’apporte la plus grande attention et le plus grand soin à chaque article, mais si toutefois, si vous repérez une erreur, faites-moi signe !

Note de les droits d’auteur (images): Les visuels intégrés peuvent provenir de la documentation officiels d’OPNsense, de Proxmox ou Wireguard, et sont utilisés à des fins d’illustration et d’analyse conformément au droit de citation.

Sources et références: OPNsense – Documentation Multi-WAN / Failover | OPNsense – Gateway Groups / Multi WAN | OPNsense – WireGuard Site-to-Site Setup | OPNsense – WireGuard Road Warrior Setup | OPNsense – WireGuard Selective Routing | OPNsense – Security Zones (zones de confiance) | Proxmox VE – Network Configuration (bridges Linux, VLAN) | Pro Custodibus – OPNsense WireGuard Site to Site