Sollten Sie OPNsense in der Produktion auf Proxmox betreiben?
Der Betrieb von OPNsense als virtuelle Maschine auf Proxmox kann ein zuverlässiges Produktionsdesign sein. Er kann die Hardwarekosten senken, Backups vereinfachen und die Firewall-Wiederherstellung beschleunigen – schneller, als eine ausgefallene physische Appliance neu aufzubauen.
Dieses Design schafft jedoch auch eine wichtige Abhängigkeit. Wenn OPNsense den Internetzugang, das Routing und die Fernverwaltung für denselben Proxmox-Host bereitstellt, auf dem es läuft, kann ein Ausfall des Hypervisors oder des Netzwerks die gesamte Umgebung von der Außenwelt trennen.
Sie sollten OPNsense in der Produktion nur dann auf Proxmox betreiben, wenn Server-, Netzwerk- und Recovery-Design diese Failure Domain berücksichtigen. Die virtuelle Maschine selbst ist selten der Schwachpunkt. Eine schlechte Bridge-Konfiguration, fehlender Konsolenzugriff und mangelnde Redundanz stellen die größeren Risiken dar.
Wird OPNsense als virtuelle Maschine unterstützt?
OPNsense dokumentiert virtuelle Installationen offiziell und stellt Installationsabbilder bereit, die von virtuellen Festplatten laufen können. Die Anleitung für virtuelle Bereitstellungen empfiehlt mindestens 3 GB Arbeitsspeicher, eine 8 GB große virtuelle Festplatte sowie das Deaktivieren von Hardware-Offloading-Einstellungen für die Kompatibilität.
Proxmox nutzt KVM, um vollständige virtuelle Maschinen mit eigenem Gastbetriebssystem und eigenem Kernel bereitzustellen. Es verwendet außerdem ein Bridge-basiertes Netzwerkmodell, bei dem virtuelle Netzwerkschnittstellen mit Software-Bridges verbunden werden, die ähnlich wie Ethernet-Switches arbeiten.
Das macht Proxmox technisch geeignet, um OPNsense zu hosten. Die wichtigere Frage ist, ob das umgebende Design für den Produktionseinsatz geeignet ist.
Welche Vorteile bietet die Virtualisierung von OPNsense?
Der erste Vorteil ist die effiziente Hardwarenutzung. Eine dedizierte Firewall-Appliance nutzt oft nur einen Bruchteil ihres Prozessors und Arbeitsspeichers. Proxmox kann die übrigen Ressourcen anderen Infrastrukturdiensten zuweisen.
Virtualisierung erleichtert außerdem den Austausch. Fällt eine physische Firewall aus, benötigen Administratoren oft erst kompatible Ersatzhardware, bevor der Dienst wiederhergestellt werden kann. Ein virtuelles OPNsense-System lässt sich dagegen auf einem anderen Proxmox-Node wiederherstellen, sofern kompatibler Storage und passendes Netzwerk verfügbar sind.
Proxmox kann komplette virtuelle Maschinen sichern, einschließlich ihrer virtuellen Festplatten und Konfiguration. Die Integration mit dem Proxmox Backup Server ergänzt das um inkrementelle Backups, Deduplizierung und strukturierte Restore-Workflows.
OPNsense verfügt zudem über ein eigenes System für Konfigurations-Backups. Administratoren können verschlüsselte Konfigurationsdateien exportieren und Backups automatisch an externe Dienste senden. Eine Konfigurationsdatei lässt sich während der Installation importieren, um die Firewall auf neuer Hardware oder in einer neuen virtuellen Maschine wiederherzustellen.
Diese beiden Backup-Ebenen erfüllen unterschiedliche Zwecke. Ein Proxmox-Backup stellt die komplette virtuelle Firewall wieder her. Ein OPNsense-Konfigurations-Backup kann die Firewall dagegen unabhängig von der ursprünglichen virtuellen Maschine wiederaufbauen.
Was ist das größte Produktionsrisiko?
Das Hauptrisiko besteht darin, die Firewall und die Infrastruktur, die für den Zugriff auf diese Firewall benötigt wird, auf demselben Host zu platzieren.
Stellen Sie sich einen einzelnen Proxmox-Server vor, auf dem OPNsense läuft. Die OPNsense-VM stellt Internetzugang, DHCP, DNS und VPN-Konnektivität bereit. Die Proxmox-Verwaltungsoberfläche ist nur über ein Netzwerk erreichbar, das von OPNsense geroutet wird.
Stoppt der Proxmox-Host, stoppt auch die Firewall. Remote-Nutzer verlieren ihr VPN, und Administratoren verlieren möglicherweise auch den Weg, um Proxmox überhaupt zu erreichen. Ein kleinerer Virtualisierungsfehler kann so zu einem kompletten Netzwerkausfall werden.
Das Design braucht einen Wiederherstellungsweg, der nicht von der OPNsense-VM abhängt. Das kann eine dedizierte Verwaltungsschnittstelle, ein isoliertes Verwaltungsnetzwerk, lokaler Konsolenzugriff oder ein Server-Management-Controller sein.
Sie sollten in der Lage sein, die Proxmox-Konsole zu öffnen, die OPNsense-VM zu untersuchen und Bridge-Einstellungen zu korrigieren, selbst wenn das normale Routing nicht verfügbar ist.
Wie sollten Sie das Proxmox-Netzwerk gestalten?
Ein einfaches Deployment nutzt normalerweise getrennte Proxmox-Bridges für externen und internen Traffic.
Die externe Bridge verbindet das WAN-Interface von OPNsense mit dem Internetanschluss. Die interne Bridge verbindet das LAN-Interface von OPNsense mit virtuellen Maschinen, physischen Switches oder internen VLANs.
Die Proxmox-Verwaltungsoberfläche sollte nicht unbedacht an eine Bridge mit Internetanbindung gehängt werden. Proxmox bietet eigene Firewall-Funktionen, aber die Verwaltungsoberfläche sollte trotzdem in einem vertrauenswürdigen Netzwerk verbleiben und nicht direkt dem öffentlichen Internet ausgesetzt sein. Proxmox-Firewall-Regeln lassen sich auf Cluster-, Host- und VM-Ebene anwenden.
Die Proxmox-Netzwerkkonfiguration unterstützt Bridges, Bonds, VLANs und geroutete Designs. Produktionsumgebungen sollten dokumentieren, welche physische Schnittstelle mit welcher Bridge verbunden ist und wie VLAN-Tags zwischen Proxmox, OPNsense und den physischen Switches wandern.
Ein Netzwerkfehler kann sowohl die Firewall als auch den Hypervisor betreffen. Nehmen Sie Änderungen nach Möglichkeit über die Konsole vor, besonders wenn Sie die Bridge ändern, über die der Management-Traffic läuft.
Sollten Sie virtuelle Interfaces oder PCI-Passthrough verwenden?
Die meisten Deployments kommen mit virtuellen Netzwerkschnittstellen aus, die mit Proxmox-Bridges verbunden sind.
Virtuelle Interfaces machen es einfacher, die OPNsense-Maschine zu sichern, zu migrieren und wiederherzustellen. Sie erlauben es außerdem mehreren virtuellen Workloads, sich einen physischen Netzwerkadapter über die Proxmox-Bridge zu teilen.
PCI-Passthrough gibt der OPNsense-VM die direkte Kontrolle über eine physische Netzwerkkarte. Proxmox unterstützt das Durchreichen eines kompletten PCI-Geräts, einschließlich eines Netzwerkadapters, an eine KVM-VM.
Passthrough kann für eine klare Trennung zwischen der Firewall und der Proxmox-Netzwerkebene sorgen. Es kann außerdem für spezialisierte Interfaces oder Umgebungen mit hohem Traffic-Aufkommen sinnvoll sein.
Der Kompromiss ist eine geringere Portabilität. Eine virtuelle Maschine mit durchgereichter Karte hängt davon ab, dass diese Karte im gewählten Proxmox-Node vorhanden ist. Live-Migration und automatische Wiederherstellung werden dadurch schwieriger.
Für viele kleine und mittlere Deployments bieten Proxmox-Bridges die bessere Balance. Setzen Sie Passthrough ein, wenn es einen belegten Performance-, Kompatibilitäts- oder Sicherheitsgrund dafür gibt.
Welche Performance kann eine virtuelle OPNsense-Firewall liefern?
Der Ressourcenbedarf hängt von Verbindungsgeschwindigkeit, Firewall-Regeln, VPN-Verschlüsselung, Intrusion Prevention und Traffic-Reporting ab.
Einfaches Routing und Filtering benötigen vergleichsweise bescheidene Ressourcen. Suricata-Intrusion-Prevention, Traffic-Inspection und schnelle VPN-Verbindungen können dagegen einen deutlich höheren Prozessorbedarf erzeugen.
OPNsense empfiehlt, Checksum-Offloading, TCP-Segmentation-Offloading und Large-Receive-Offloading in vielen Firewall- und Virtualisierungsszenarien zu deaktivieren. Die Dokumentation weist darauf hin, dass manche Offloading-Funktionen mit Intrusion Prevention nicht kompatibel sind oder Routing-Probleme verursachen können.
Dimensionieren Sie die virtuelle Maschine nicht nur nach der durchschnittlichen Bandbreite. Messen Sie die Prozessorauslastung während Backups, VPN-Spitzen, Intrusion-Detection-Updates und starkem gleichzeitigem Traffic.
Reservieren Sie genug Proxmox-Kapazität, damit andere virtuelle Maschinen der Firewall nicht die Ressourcen entziehen können. Eine Firewall, die mit Anwendungs-Workloads um Prozessorzeit konkurriert, kann Latenz erzeugen, selbst wenn die physischen Netzwerkadapter nicht ausgelastet sind.
Wie sollten Start und Herunterfahren gehandhabt werden?
OPNsense sollte vor den meisten Workloads starten, die von Routing, DHCP, DNS oder Internetzugang abhängen.
Proxmox unterstützt automatischen Gaststart sowie eine konfigurierbare Startreihenfolge mit Verzögerungen. Administratoren können die Firewall zuerst starten, ihren Diensten Zeit zur Initialisierung geben und anschließend die Anwendungs-VMs starten. Beim Herunterfahren nutzt Proxmox die umgekehrte Reihenfolge, sodass abhängige Workloads stoppen, bevor die Firewall stoppt.
Gehen Sie nicht davon aus, dass eine laufende virtuelle Maschine bedeutet, dass das Netzwerk bereit ist. OPNsense benötigt möglicherweise Zeit, um Interfaces zu initialisieren, VPN-Tunnel aufzubauen und die Verfügbarkeit des Gateways zu bestätigen.
Testen Sie einen vollständigen Neustart des Proxmox-Hosts. Bestätigen Sie, dass OPNsense korrekt startet und dass abhängige Systeme sich ohne manuellen Eingriff erholen.
Brauchen Sie zwei OPNsense-VMs?
Eine einzelne OPNsense-VM kann während eines Host-Ausfalls keinen unterbrechungsfreien Dienst gewährleisten.
OPNsense unterstützt Hochverfügbarkeit über CARP. Zwei Firewalls können sich virtuelle Adressen teilen, ihre Firewall-Zustände synchronisieren und dem sekundären System erlauben, die Übernahme zu tätigen, wenn das primäre System nicht mehr verfügbar ist. OPNsense empfiehlt für die Zustandssynchronisierung eine dedizierte Schnittstelle.
Die beiden Firewall-VMs sollten auf getrennten Proxmox-Nodes laufen, wenn sie vor einem Host-Ausfall schützen sollen. Werden beide auf einem physischen Server betrieben, schützt das nur vor einem Ausfall innerhalb eines Firewall-Gasts.
Auch der Proxmox-Cluster braucht ein zuverlässiges Quorum. Proxmox empfiehlt mindestens drei Nodes für ein verlässliches Hochverfügbarkeits-Quorum.
CARP hängt von Netzwerkverhalten wie Multicast, der Bewegung von MAC-Adressen und Gratuitous ARP ab. OPNsense warnt, dass virtualisierte Switching-Umgebungen CARP erschweren können, wenn die Netzwerkebene diese Funktionen einschränkt. Der komplette Failover-Pfad muss getestet werden, nicht nur angenommen.
Wie sollten Updates und Backups verwaltet werden?
Exportieren Sie die OPNsense-Konfiguration vor jeder größeren Änderung. Bewahren Sie Kopien außerhalb des Proxmox-Clusters auf, damit sie auch bei einem Storage- oder Cluster-Ausfall verfügbar bleiben.
Erstellen Sie außerdem vor größeren OPNsense-Upgrades ein verifiziertes Proxmox-Backup. Snapshots können eine schnelle Rollback-Option bieten, allerdings gehen Änderungen, die nach dem Snapshot vorgenommen wurden, beim Rollback verloren. OPNsense empfiehlt deshalb, Konfigurations-Backups zusätzlich zu Snapshots aufzubewahren.
Updates sollten zuerst an einer sekundären Firewall oder einer Laborkopie getestet werden. Vermeiden Sie es, OPNsense und Proxmox im selben Wartungsfenster zu aktualisieren. Getrennte Änderungen erleichtern es, Fehler zu diagnostizieren.
Sollten Sie es in der Produktion betreiben?
Ja, OPNsense kann erfolgreich in der Produktion auf Proxmox laufen.
Das Design ist geeignet, wenn Sie über zuverlässige Server-Hardware, getrennte Netzwerk-Bridges, geschützten Verwaltungszugriff, automatische Startreihenfolgen und Backups verfügen, die außerhalb der Firewall-VM gespeichert werden.
Nutzen Sie für kritische Netzwerke zwei OPNsense-Systeme auf getrennten Proxmox-Nodes und testen Sie das CARP-Failover unter realistischen Bedingungen.
Eine physische Firewall bleibt einfacher, wenn die Umgebung nur über einen Proxmox-Server verfügt, keinen unabhängigen Verwaltungsweg bietet und während eines Ausfalls kein Administrator vor Ort verfügbar ist.
Die Virtualisierung von OPNsense bietet Flexibilität und schnelle Wiederherstellung. Sie koppelt die Netzwerkverfügbarkeit aber auch an den Zustand der Virtualisierungsplattform. Ob die Produktionsreife gegeben ist, hängt davon ab, ob diese Abhängigkeit bewusst gestaltet und getestet wurde.