OPNsense als Firewall-VM auf Proxmox betreiben

Zuerst die Antwort: Wann eine virtuelle Firewall sinnvoll ist

OPNsense als Proxmox-Guest zu betreiben ist ein bewährtes, produktionstaugliches Muster mit einem klaren Profil, wann es die richtige Wahl ist:

Tun Sie es, wenn die Aufgabe der Firewall darin besteht, den virtuellen Bestand zu schützen: Eine OPNsense-VM als Gateway für Ihre übrigen Guests liefert Inter-VLAN-Routing, eine vollwertige DMZ, VPN-Terminierung und IDS/IPS für alles dahinter, dazu die Dividende der Virtualisierung: Snapshot vor jedem Upgrade, Konfigurations-Restore in Minuten und kein zweites Chassis zu mieten. Auf einem einzelnen Dedicated Server mit vielen VMs ist das der naheliegende Aufbau.

Überlegen Sie zweimal, wenn die Firewall unabhängig vom Hypervisor sein muss (wenn OPNsense der Perimeter ist für Infrastruktur jenseits dieses Hosts, reißt jeder Proxmox-Neustart Ihr Netzwerk mit runter) oder wenn Sie jedes letzte Gigabit mit Hardware-Offloads brauchen, wo Bare Metal (oder NIC-Passthrough) noch immer im Vorteil ist.

Eine Design-Regel vorab, die alle, die sie ignoriert haben, auf die harte Tour gelernt haben: Machen Sie die eigene Management-Schnittstelle des Proxmox-Hosts niemals von der OPNsense-VM abhängig. Die SSH-/Web-UI des Hosts muss über ihren eigenen Pfad erreichbar bleiben; sonst sperrt eine nicht bootende Firewall-VM Sie aus genau dem Hypervisor aus, von dem aus Sie sie reparieren würden. (KVM-over-IP ist das Backup, aber planen Sie nicht so, dass Sie es brauchen.)

Netzwerkdesign auf einem Dedicated Server

Das baut direkt auf dem Bridge-Modell aus unserem Proxmox-Netzwerk-Guide auf. OPNsense wird einfach ein Guest mit einem Bein in zwei (oder mehr) Bridges:

• WAN: eine virtuelle NIC auf vmbr0 (der öffentlichen Bridge), konfiguriert mit einer zusätzlichen öffentlichen IP, die Ihrem Server zugewiesen ist, unter Beachtung der MAC-Richtlinie des Providers, genau wie bei jedem Bridged Guest. In unserem Netzwerk kommen zusätzliche IPs standardmäßig mit dem Server, und das funktioniert einfach.
• LAN: eine virtuelle NIC auf einer internen Bridge (bridge-ports none, ein Switch ohne Uplink, z. B. vmbr1). Jeder Guest, der hinter der Firewall leben soll, hängt sich hier an und nutzt die LAN-Adresse von OPNsense als Gateway.
• Weitere Segmente: entweder mehr interne Bridges oder (sauberer im großen Maßstab) eine VLAN-fähige interne Bridge, bei der OPNsense einen Trunk übernimmt und zwischen getaggten Segmenten routet. Das ergibt eine DMZ, ein Management-Netz und ein Lab, alle an einem Punkt gefirewallt.

Der Proxmox-Host selbst behält seine Management-IP auf vmbr0 (oder besser: einer eigenen Management-Schnittstelle), gemäß der Regel oben nicht hinter der OPNsense-VM. Guests erhalten Defence in Depth: unsere Network-Edge-Firewall vorgelagert, OPNsense an der Segmentgrenze, und Regeln auf dem Host selbst innerhalb jedes Guests, wo es angebracht ist.

Die VM-Konfiguration, die funktioniert

Die Community (und das gepflegte Virtualisierungs-HOWTO im offiziellen OPNsense-Forum) hat sich auf ein Rezept geeinigt; wer davon abweicht, findet dort die mysteriösen Bugs:

Ehrlich zum Sizing: Die offiziellen Hardware-Empfehlungen von OPNsense enden bei "750+ Mbit/s" für die 8-GB-"recommended"-Spec und veröffentlichen keine exakte Zahl für virtualisiertes Gigabit; das Rezept mit 2–4 vCPU / 4–8 GB ist von der Community etablierte Richtlinie, komfortabel für das Routen eines Gigabits mit einem normalen Regelwerk. RAM für die State-Table ist selten das Problem (rund 1 KB pro Connection State); Suricata IDS/IPS dagegen schon: Inline-Inspektion ist CPU-hungrig und ist das, was eine kleine Firewall-VM auf 4+ Cores treibt.

Die Offloading-Fußnote, die Ihnen ein Wochenende spart

Historischer Schmerzpunkt: VirtIO-NICs plus Hardware-Checksum-Offload auf FreeBSD-Guests verursachten verlorene Pakete und kaputte Konnektivität. Modernes OPNsense liefert die richtige Antwort bereits mit: Hardware-Checksum/TSO/LRO-Offloading ist standardmäßig deaktiviert (Interfaces → Settings). Der praktische Rat in 2026 lautet also: prüfen Sie, dass diese Kästchen aktiviert bleiben ("disable"), und "optimieren" Sie sie nicht, indem Sie sie wieder einschalten, auf VirtIO-Interfaces. Wenn eine OPNsense-VM Traffic merkwürdig behandelt (manche Seiten laden, andere hängen), ist diese Einstellung Verdächtiger Nummer eins.

Installation, kompakt

1. Laden Sie das OPNsense-Installer-ISO (aktuelle Serie: 26.1; das Projekt liefert zwei Major-Releases pro Jahr, im Januar und Juli) zu Proxmox hoch und booten Sie die VM davon.
2. Melden Sie sich als installer an, installieren Sie mit ZFS auf die Disk, Neustart.
3. Weisen Sie an der Konsole die Interfaces zu: VirtIO-NICs erscheinen als vtnet0, vtnet1 … Ordnen Sie sie WAN/LAN anhand der MAC-Adressen zu, die im Hardware-Panel von Proxmox angezeigt werden (vergeben Sie beim Erstellen der VM merkbar unterschiedliche Adressen; Ihr zukünftiges Ich dankt Ihnen).
4. Stellen Sie WAN auf Ihre zugewiesene öffentliche IP/Gateway und LAN auf Ihren internen Bereich (z. B. 10.0.0.1/24), öffnen Sie dann die Web-UI von einem Guest auf der LAN-Bridge aus (oder über einen SSH-Tunnel durch den Host) und durchlaufen Sie den Setup-Assistenten.
5. Erste Schritte nach dem Assistenten: auf den aktuellen Stand aktualisieren, os-qemu-guest-agent installieren, ersten Snapshot erstellen.

Im Day-2-Betrieb zeigt sich der Vorteil des VM-Formfaktors: Snapshot → Upgrade → Verifizieren → Snapshot löschen macht aus den halbjährlichen Major-Releases von OPNsense ein Nicht-Ereignis statt eines Wartungsrisikos, und PBS sichert die gesamte Firewall nachts wie jeden anderen Guest.

Was ist mit pfSense?

Dasselbe Rezept gilt nahezu wortgleich für pfSense, ebenfalls FreeBSD, ebenfalls VirtIO-freundlich. Zwischen beiden: pfSense CE bleibt am Leben (aktuell 2.8.x, 2.9 in Entwicklung) neben dem kommerziellen pfSense Plus, während OPNsenses berechenbarer Zwei-Major-Releases-pro-Jahr-Rhythmus, das vollständig offene Modell und die moderne UI es in den letzten Jahren zur Standardempfehlung in der Self-Hosting-Welt gemacht haben. Wenn Sie eines bereits kennen, betreiben Sie es; wer neu anfängt, für den hat sich dieser Leitfaden bewusst für OPNsense entschieden.

Häufig gestellte Fragen

Sollte ich OPNsense eine physische NIC durchreichen, statt VirtIO zu verwenden?

Setzen Sie standardmäßig auf VirtIO: Das ist die aktuelle Empfehlung der Community, hält die VM vollständig virtuell (Snapshots, Migration, kein Gefummel mit IOMMU) und routet ein Gigabit problemlos. PCI-Passthrough rechtfertigt seine Komplexität in zwei Fällen: wenn Sie mit Hardware-Offloads auf Multi-Gigabit-Links maximalen Durchsatz jagen, oder wenn das WAN-Kabel physisch vom Netzwerk-Stack des Hypervisors getrennt sein soll. Bei Passthrough verliert die VM Live-Migration und die einfache Snapshot-Handhabung. Damit geben Sie genau die Gründe für die Virtualisierung wieder auf.

Schützt OPNsense auch den Proxmox-Host?

In diesem Design nicht. Und das ist auch richtig so. Die Management-Ebene des Hosts bleibt auf ihrem eigenen Pfad (bewusst nicht hinter der Firewall-VM), sondern geschützt durch die vorgelagerte Edge-Firewall, eigene Regeln und dadurch, dass die Web-UI (Port 8006) niemals öffentlich erreichbar ist. Den eigenen Datenverkehr des Hosts über einen Guest zu routen, den er selbst hostet, erzeugt eine zirkuläre Abhängigkeit mit genau einem Fehlermodus: totaler Lockout. Guests hinter OPNsense; der Host daneben, unabhängig abgesichert.

Wie viel Performance verliere ich gegenüber Bare Metal?

Für einfaches Routing/NAT im Gigabit-Bereich auf modernen Cores: wenig genug, dass der Komfort von VirtIO gewinnt: Die offiziellen Spec-Stufen setzen selbst bescheidene Hardware in die Klasse "750+ Mbit/s", und eine korrekt konfigurierte VM liegt in diesem Bereich. Die ehrlichen Kosten zeigen sich an den Extremen: Multi-Gigabit-Durchsatz (der Overhead der paravirtualisierten Vernetzung pro Paket summiert sich; Passthrough erwägen) und IDS/IPS (die Inspektion von Suricata ist die eigentliche CPU-Rechnung, egal wo sie läuft). Messen Sie Ihren eigenen Pfad, bevor Sie optimieren, und siehe den Benchmark der Redaktion oben.

Kann ich das hochverfügbar betreiben?

CARP (OPNsense's VRRP-artiges Failover) funktioniert virtualisiert, aber überlegen Sie genau, was es auf einem Host bringt: Zwei Firewall-VMs auf demselben Hypervisor teilen sich jeden Hardwarefehler, sodass Intra-Host-CARP vor allem Upgrade-Fenster abdeckt, die Snapshots ohnehin schon abdecken. Echte Firewall-HA bedeutet OPNsense-VMs auf zwei Hosts, deren LAN-Segmente sich über beide erstrecken (VLANs per privater Vernetzung oder VXLAN über Proxmox SDN), lohnenswert, wenn die dahinterliegenden Guests ein clustertaugliches Design generell rechtfertigen.

Bereitstellung bei Serverside

Alles, was dieses Muster braucht, ist hier bei einem Proxmox Dedicated Server bereits dabei: zusätzliche öffentliche IPs für das WAN-Bein, privates Networking, das Ihre VLANs für Multi-Server-Designs zwischen Hosts trägt, permanente DDoS-Mitigation vorgelagert zur gesamten Konstruktion, und KVM-over-IP als Backup gegen Aussperrung. Proxmox ist vorinstalliert; das OPNsense-ISO ist nur einen Upload entfernt.

Ergänzen Sie das mit dem Proxmox-Networking-Deep-Dive, auf dem dieses Design aufbaut, Backup-Strategien für die Firewall-VM selbst, und (für die WireGuard-native Alternative auf der Routing-Ebene) unserem VyOS-Site-to-Site-Guide.