OPNsense draaien als firewall-VM op Proxmox

Eerst het antwoord: wanneer een virtuele firewall zin heeft

OPNsense als Proxmox-guest draaien is een goed beproefd patroon dat productierijp is, met een duidelijk profiel van wanneer het de juiste keuze is:

Doe het wanneer de taak van de firewall is om het virtuele landschap te bewaken: een OPNsense-VM als gateway voor je andere guests geeft je inter-VLAN-routing, een volwaardige DMZ, VPN-terminatie en IDS/IPS voor alles erachter, plus het dividend van virtualisatie: snapshot voor elke upgrade, configuratie binnen minuten herstellen, en geen tweede chassis om te huren. Op één dedicated server met veel VM's is dit het voor de hand liggende ontwerp.

Denk twee keer na wanneer de firewall onafhankelijk van de hypervisor moet zijn (als OPNsense de perimeter is voor infrastructuur buiten deze host, trekt elke Proxmox-reboot je netwerk mee naar beneden) of wanneer je elke laatste gigabit nodig hebt met hardware-offloads, waar bare metal (of NIC-passthrough) nog altijd de overhand heeft.

Eén ontwerpregel vooraf, op de harde manier geleerd door iedereen die hem oversloeg: maak de eigen beheerinterface van de Proxmox-host nooit afhankelijk van de OPNsense-VM. De SSH/web-UI van de host moet via zijn eigen pad bereikbaar blijven; anders sluit een firewall-VM die niet opstart je buiten precies de hypervisor waarmee je het zou repareren. (KVM-over-IP is het vangnet, maar ontwerp niet zodat je het nodig hebt.)

Netwerkontwerp op een dedicated server

Dit bouwt direct voort op het bridge-model uit onze Proxmox-netwerkgids. OPNsense wordt gewoon een guest met een been in twee (of meer) bridges:

• WAN: een virtuele NIC op vmbr0 (de publieke bridge), geconfigureerd met een extra publiek IP-adres toegewezen aan je server, met inachtneming van het MAC-beleid van de provider, precies zoals bij elke bridged guest. Op ons netwerk komen extra IP's standaard mee met de server en werkt dit gewoon.
• LAN: een virtuele NIC op een interne bridge (bridge-ports none, een switch zonder uplink, bijv. vmbr1). Elke guest die achter de firewall moet leven, koppelt hier aan en gebruikt het LAN-adres van OPNsense als gateway.
• Meer segmenten: meer interne bridges, of (schoner op schaal) één VLAN-aware interne bridge waarbij OPNsense een trunk neemt en routeert tussen getagde segmenten. Dat is een DMZ, een beheernetwerk en een lab, allemaal gefirewalld op één punt.

De Proxmox-host zelf houdt zijn beheer-IP op vmbr0 (of beter, een aparte beheerinterface), niet achter de OPNsense-VM, volgens de regel hierboven. Guests krijgen defence in depth: onze network-edge firewall upstream, OPNsense op de segmentgrens, en regels op de host zelf binnen elke guest waar dat gewenst is.

De VM-configuratie die werkt

De community (en de goed onderhouden virtualisatie-HOWTO op het officiële OPNsense-forum) is uitgekomen op één recept; wie ervan afwijkt, vindt daar de mysterieuze bugs.

Eerlijk over sizing: de officiële hardware-richtlijnen van OPNsense stoppen bij "750+ Mbit/s" voor de 8 GB "recommended"-spec en publiceren geen exact gevirtualiseerd gigabit-cijfer; het recept van 2–4 vCPU / 4–8 GB is door de community vastgestelde richtlijn, comfortabel voor het routeren van een gigabit met een normale ruleset. RAM voor de state-table is zelden het probleem (ruwweg 1 KB per connection state); Suricata IDS/IPS wel: inline inspectie is CPU-hongerig en is wat een kleine firewall-VM naar 4+ cores duwt.

De offloading-voetnoot die je een weekend bespaart

Historische pijn: VirtIO-NIC's plus hardware checksum offload op FreeBSD-guests veroorzaakten dropped packets en kapotte connectiviteit. Moderne OPNsense levert het juiste antwoord al standaard mee: hardware checksum/TSO/LRO-offloading staat standaard uit (Interfaces → Settings). Het bruikbare advies in 2026 is dus: controleer of die vakjes aangevinkt blijven ("disable") en "optimaliseer" ze niet door ze weer aan te zetten op VirtIO-interfaces. Als een OPNsense-VM verkeer vreemd afhandelt (sommige sites laden, andere hangen), is deze instelling verdachte nummer één.

Installeren, verkort

1. Upload de OPNsense-installer-ISO (huidige serie: 26.1; het project brengt twee keer per jaar een major uit, in januari en juli) naar Proxmox en boot de VM ervanaf.
2. Log in als installer, installeer naar disk met ZFS, reboot.
3. Wijs op de console de interfaces toe: VirtIO-NIC's verschijnen als vtnet0, vtnet1… Match ze aan WAN/LAN via de MAC-adressen die het hardwarepaneel van Proxmox toont (stel ze bij het aanmaken van de VM herkenbaar verschillend in; toekomstige jij zegt dank je wel).
4. Stel WAN in op je toegewezen publieke IP/gateway en LAN op je interne reeks (bijv. 10.0.0.1/24), open dan de web-UI vanaf een guest op de LAN-bridge (of via een SSH-tunnel door de host) en doorloop de setup-wizard.
5. Eerste stappen na de wizard: updaten naar de huidige versie, os-qemu-guest-agent installeren, je eerste snapshot maken.

Bij day-2-beheer blinkt het VM-formfactor uit: snapshot → upgrade → verifiëren → snapshot verwijderen maakt van OPNsense's tweejaarlijkse majors een non-event in plaats van een onderhoudsrisico, en PBS back-upt de hele firewall elke nacht net als elke andere guest.

En pfSense dan?

Hetzelfde recept geldt bijna woordelijk voor pfSense, ook FreeBSD, ook blij met VirtIO. Tussen de twee: pfSense CE blijft in leven (2.8.x actueel, 2.9 in ontwikkeling) naast het commerciële pfSense Plus, terwijl de voorspelbare cadans van twee majors per jaar, het volledig open model en de moderne UI van OPNsense het de afgelopen jaren tot de standaardaanbeveling hebben gemaakt in de self-hosting-wereld. Ken je er al een, draai die dan; begin je vers, dan koos deze gids bewust voor OPNsense.

Veelgestelde vragen

Moet ik een fysieke NIC doorgeven aan OPNsense in plaats van VirtIO te gebruiken?

Kies standaard voor VirtIO: dat is het huidige advies van de community, houdt de VM volledig virtueel (snapshots, migratie, geen gepriegel met IOMMU) en routeert een gigabit probleemloos. PCI-passthrough verdient zijn complexiteit terug in twee gevallen: maximale doorvoer najagen met hardware-offloads op multi-gigabit-links, of de WAN-kabel fysiek willen isoleren van de netwerkstack van de hypervisor. Geef je toch door, dan verliest de VM live-migratie en de eenvoudige snapshot-ergonomie. Dan doe je afstand van precies de redenen om te virtualiseren.

Beschermt OPNsense ook de Proxmox-host?

Niet in dit ontwerp. En dat hoort ook niet. Het beheervlak van de host blijft op zijn eigen pad (bewust niet achter de firewall-VM), en wordt in plaats daarvan beschermd door de upstream edge-firewall, zijn eigen regels, en door de web-UI (poort 8006) nooit publiek bloot te stellen. Het eigen verkeer van de host routeren via een guest die hij zelf host, creëert een circulaire afhankelijkheid met precies één faalmodus: volledige lockout. Guests achter OPNsense; host ernaast, onafhankelijk gehard.

Hoeveel prestaties lever ik in ten opzichte van bare metal?

Voor gewone routing/NAT op gigabit-schaal op moderne cores: weinig genoeg dat het gemak van VirtIO wint: de officiële spec-tiers plaatsen zelfs bescheiden hardware al in de klasse "750+ Mbit/s", en een correct geconfigureerde VM zit in die band. De eerlijke kosten zitten aan de uitersten: multi-gigabit-doorvoer (de overhead per pakket van paravirtualisatie telt op; overweeg passthrough) en IDS/IPS (de inspectie van Suricata is de echte CPU-rekening, waar dan ook draaiend). Meet je eigen pad voordat je optimaliseert, en zie de benchmark van de redactie hierboven.

Kan ik dit high-available draaien?

CARP (OPNsense's VRRP-achtige failover) werkt gevirtualiseerd, maar bedenk goed wat het je oplevert op één host: twee firewall-VM's op dezelfde hypervisor delen elk hardwarefalen, dus intra-host CARP dekt vooral upgrade-vensters, wat snapshots al afhandelen. Echte firewall-HA betekent OPNsense-VM's op twee hosts met de LAN-segmenten die ze overspannen (VLAN's over privénetwerken, of VXLAN via Proxmox SDN), de moeite waard wanneer de guests erachter clustergericht ontwerp in het algemeen rechtvaardigen.

Uitrollen op Serverside

Alles wat dit patroon nodig heeft, komt hier standaard mee bij een Proxmox dedicated server: extra publieke IP's voor het WAN-been, privénetwerken dat je VLAN's tussen hosts draagt voor multi-server-ontwerpen, altijd-actieve DDoS-mitigatie upstream van de hele opzet, en KVM-over-IP als het vangnet tegen lockout. Proxmox staat vooraf geïnstalleerd; de OPNsense-ISO is een upload verwijderd.

Maak het compleet met de Proxmox-netwerkverdieping waarop dit ontwerp voortbouwt, back-upstrategieën voor de firewall-VM zelf, en (voor het WireGuard-native alternatief op de routinglaag) onze VyOS site-to-site-gids.