Wer Proxmox VE betreibt, denkt bei Netzwerksicherheit oft zuerst an die Perimeter-Firewall — also eine OPNsense oder pfSense, die den Datenverkehr zwischen internem Netz und Internet regelt. Das greift jedoch zu kurz. Gelangt ein Angreifer einmal ins interne Netz oder kompromittiert er eine VM, kann er sich ohne weitere Hürden lateral bewegen und andere VMs auf demselben Host angreifen. Die Proxmox Firewall setzt genau hier an: Sie filtert den Datenverkehr direkt auf Hypervisor-Ebene, bevor Pakete die virtuelle Netzwerkkarte einer VM überhaupt erreichen.

Warum VM-Isolation so wichtig ist

In einer nicht segmentierten virtuellen Umgebung kommunizieren alle VMs auf demselben Proxmox-Host über den internen Bridge (z. B. vmbr0) miteinander — ohne jegliche Filterung. Wird ein Webserver kompromittiert, kann der Angreifer von dort aus Datenbankserver, Backup-Systeme und Management-Interfaces direkt ansprechen. Dieses Angriffsmuster nennt sich Lateral Movement und ist bei Ransomware-Angriffen oder gezielten Einbrüchen der häufigste Ausbreitungsweg.

Mikrosegmentierung löst dieses Problem: Jede VM erhält exakt die Netzwerkzugriffe, die sie für ihre Funktion benötigt — und keinen Zugriff darüber hinaus. Das Prinzip der minimalen Rechtevergabe gilt nicht nur für Benutzerkonten, sondern auch für Netzwerkverbindungen.

Architektur der Proxmox Firewall

Die Proxmox Firewall arbeitet auf drei hierarchischen Ebenen:

Ebene	Gültigkeitsbereich	Konfigurationsort
Datacenter	Alle Nodes und VMs	Datacenter > Firewall
Node	Einzelner Proxmox-Host	Node > Firewall
VM / Container	Einzelne virtuelle Maschine	VM > Firewall

Regeln auf höherer Ebene gelten automatisch für alle untergeordneten Ebenen. Die VM-Ebene kann diese Regeln durch eigene Regeln ergänzen, aber nicht aufheben. Technisch setzt Proxmox die Firewall mittels iptables (auf Nodes ohne nftables) oder nftables um — die Weboberfläche und API abstrahieren jedoch die gesamte Komplexität.

Firewall aktivieren

Die Firewall ist standardmäßig deaktiviert und muss explizit eingeschaltet werden — sowohl auf Datacenter-Ebene als auch für jede VM individuell.

Schritt 1: Datacenter-Firewall aktivieren

In der Proxmox-Weboberfläche: Datacenter > Firewall > Options — den Haken bei Firewall setzen.

Schritt 2: VM-Firewall aktivieren

Für jede VM unter VM > Firewall > Options: Firewall aktivieren. Wichtig: Ohne diesen Schritt greift die VM-spezifische Regelkonfiguration nicht.

Schritt 3: Netzwerkinterface der VM aktivieren

In den VM-Einstellungen unter Hardware > Network Device muss die Option Firewall ebenfalls angehakt sein. Nur dann werden Pakete an dieser virtuellen Netzwerkkarte gefiltert.

Sicherheitsgruppen: Wiederverwendbare Regelwerke

Sicherheitsgruppen (Security Groups) sind benannte Regelsammlungen, die auf mehrere VMs angewendet werden können. Statt für jeden Webserver dieselben Regeln einzeln anzulegen, erstellen Sie eine Gruppe webserver und weisen diese allen betreffenden VMs zu.

# Sicherheitsgruppe per CLI erstellen
pvesh create /cluster/firewall/groups --group webserver --comment "Regeln für Webserver"

# Regel zur Gruppe hinzufügen: HTTP und HTTPS eingehend erlauben
pvesh create /cluster/firewall/groups/webserver \
  --action ACCEPT --type in --proto tcp --dport 80 --comment "HTTP eingehend"

pvesh create /cluster/firewall/groups/webserver \
  --action ACCEPT --type in --proto tcp --dport 443 --comment "HTTPS eingehend"

Über die Weboberfläche finden Sie Sicherheitsgruppen unter Datacenter > Firewall > Security Groups. Änderungen an der Gruppe wirken sofort auf alle zugewiesenen VMs — ideal für konsistente Sicherheitsrichtlinien über eine ganze VM-Flotte.

Eingehende und ausgehende Regeln erstellen

Regeln bestehen aus mehreren Parametern:

Direction: in (eingehend zur VM) oder out (ausgehend von der VM)
Action: ACCEPT, DROP oder REJECT
Protocol: tcp, udp, icmp oder beliebig
Source / Destination: IP-Adresse, CIDR-Block oder IP-Set
Port: Einzelner Port oder Port-Bereich

Praktisches Beispiel: Webserver-VM

Ein typischer Webserver benötigt nur wenige eingehende Verbindungen — der Rest sollte blockiert werden:

# Eingehende Regeln für VM 101 (Webserver)
Direction  Action  Protocol  Port   Source          Kommentar
in         ACCEPT  tcp       80     0.0.0.0/0       HTTP von überall
in         ACCEPT  tcp       443    0.0.0.0/0       HTTPS von überall
in         ACCEPT  tcp       22     10.0.0.0/8      SSH nur aus Mgmt-Netz
in         DROP    tcp       -      0.0.0.0/0       Alles andere verwerfen

# Ausgehende Regeln
out        ACCEPT  tcp       443    0.0.0.0/0       HTTPS-Anfragen (Updates etc.)
out        ACCEPT  udp       53     10.0.1.1        DNS zum internen Resolver
out        DROP    -         -      0.0.0.0/0       Alles andere sperren

Mit diesen Regeln ist die VM isoliert: Sie empfängt nur Web-Traffic und legitime Admin-Zugriffe, kann aber selbst keine Verbindungen zu anderen internen Systemen aufbauen — selbst wenn ein Angreifer die VM übernimmt.

IP-Sets: Gruppen von Adressen verwalten

IP-Sets erlauben es, Adressgruppen zu benennen und in Regeln als Quelle oder Ziel zu verwenden. Das vereinfacht die Regelverwaltung erheblich:

# IP-Set für Verwaltungsadressen anlegen
pvesh create /cluster/firewall/ipset --name management --comment "Admin-Workstations"

# Adressen zum IP-Set hinzufügen
pvesh create /cluster/firewall/ipset/management --cidr 10.0.0.10
pvesh create /cluster/firewall/ipset/management --cidr 10.0.0.11
pvesh create /cluster/firewall/ipset/management --cidr 10.0.0.12

In Regeln wird das IP-Set als +management referenziert. Ändert sich die Zusammensetzung des Admin-Teams, genügt eine Anpassung des IP-Sets — alle Regeln, die sich darauf beziehen, greifen automatisch auf die neue Liste zurück.

Proxmox legt zwei vordefinierte IP-Sets an: +cluster_nodes (alle Proxmox-Node-IPs) und +management (konfigurierbar). Diese eignen sich direkt für Node-Firewall-Regeln.

Makros für häufige Dienste

Proxmox Firewall enthält vordefinierte Makros für gängige Protokolle und Dienste. Statt Protokoll und Port manuell einzutragen, wählen Sie einfach das Makro:

Makro	Entspricht
`SSH`	TCP Port 22
`HTTP`	TCP Port 80
`HTTPS`	TCP Port 443
`DNS`	UDP/TCP Port 53
`SMTPS`	TCP Port 465
`Ping`	ICMP Echo
`NTP`	UDP Port 123

Makros erhöhen die Lesbarkeit der Firewall-Konfiguration deutlich und reduzieren Tippfehler bei der Port-Eingabe.

Standard-Richtlinien: ACCEPT vs. DROP

Die Default-Policy bestimmt, was mit Paketen passiert, auf die keine explizite Regel zutrifft. Es gibt zwei Strategien:

Whitelist-Ansatz (empfohlen für Produktivumgebungen): Default-Policy auf DROP setzen, nur explizit erlaubten Traffic zulassen. Sicherer, aber aufwändiger bei der Ersteinrichtung.

Blacklist-Ansatz: Default-Policy auf ACCEPT belassen, unerwünschten Traffic explizit blockieren. Einfacher zu starten, aber jeder vergessene Dienst bleibt offen.

Für Produktiv-VMs empfehlen wir konsequent den Whitelist-Ansatz. Die Default-Policy wird pro VM unter Firewall > Options gesetzt — getrennt für eingehenden (Input Policy) und ausgehenden (Output Policy) Datenverkehr.

Schutz der Proxmox-Management-Oberfläche

Die Proxmox-Weboberfläche (Port 8006) und die SSH-Zugänge der Nodes sollten niemals aus dem Internet erreichbar sein. Auf Node-Ebene lässt sich der Zugriff auf definierte Quell-IPs beschränken:

# Nur aus dem Management-Netz auf Port 8006 zugreifen lassen
pvesh create /nodes/proxmox01/firewall/rules \
  --action ACCEPT --type in --proto tcp --dport 8006 \
  --source "+management" --comment "Proxmox WebUI"

# SSH nur aus Management-Netz
pvesh create /nodes/proxmox01/firewall/rules \
  --action ACCEPT --macro SSH --type in \
  --source "+management" --comment "SSH Admin"

# Alles andere verwerfen
pvesh create /nodes/proxmox01/firewall/rules \
  --action DROP --type in --comment "Default DROP"

Mikrosegmentierung mit Sicherheitsgruppen

Mikrosegmentierung bedeutet, dass VMs unterschiedlicher Sicherheitszonen auch dann nicht miteinander kommunizieren können, wenn sie auf demselben Host laufen. Typische Zonen:

DMZ: Webserver, Reverse Proxies — öffentlich erreichbar
App: Applikationsserver — nur aus DMZ erreichbar
DB: Datenbankserver — nur aus App-Zone erreichbar
Mgmt: Monitoring, Backup — aus allen Zonen lesend erreichbar

Für jede Zone erstellen Sie eine Sicherheitsgruppe mit passenden Regeln. Ein Datenbankserver mit der Gruppe db-server lässt z. B. nur TCP/5432 (PostgreSQL) aus dem app-Subnetz zu und blockiert alles andere — egal, ob der Angreifer von außen oder aus einer kompromittierten App-VM kommt.

Firewall-Logging aktivieren

Für Audit-Zwecke und die Fehleranalyse lässt sich Logging pro Regel aktivieren. Jedes gematche Paket wird dann in /var/log/pve-firewall.log protokolliert:

# Regel mit Logging anlegen
pvesh create /nodes/proxmox01/firewall/rules \
  --action DROP --type in --log warning --comment "DROP mit Logging"

Das Log enthält Zeitstempel, Quell- und Ziel-IP, Protokoll, Port und die Regelbezeichnung. Für eine zentrale Auswertung lassen sich die Logs per rsyslog an ein SIEM weitergeleiten.

Proxmox Firewall vs. OPNsense vs. iptables/nftables

Merkmal	Proxmox Firewall	OPNsense	iptables/nftables
Integration	Nativ in Proxmox VE	Separate Appliance/VM	Manuell auf Node
Verwaltung	Weboberfläche + API	Weboberfläche + API	CLI / Skripte
Granularität	VM-Ebene	Subnetz-Ebene	Beliebig
Mikrosegmentierung	Ja (per VM)	Eingeschränkt	Ja (komplex)
Stateful Inspection	Ja	Ja	Ja
IDS/IPS	Nein	Ja (Suricata)	Nein
Aufwand	Gering	Mittel	Hoch

Die Proxmox Firewall und OPNsense schließen sich nicht aus — sie ergänzen sich ideal: OPNsense kontrolliert den Nord-Süd-Verkehr (intern ↔ Internet), die Proxmox Firewall den Ost-West-Verkehr (VM ↔ VM). Iptables/nftables direkt auf dem Node zu konfigurieren ist möglich, aber fehleranfällig und wird durch Proxmox-Updates unter Umständen überschrieben.

DATAZONE Control: Firewall-Monitoring über alle Hosts

Bei mehreren Proxmox-Nodes und Dutzenden von VMs verliert man schnell den Überblick, welche Firewall-Regeln aktiv sind und ob die Konfiguration konsistent ist. DATAZONE Control bietet zentrales Monitoring Ihrer gesamten Proxmox-Umgebung: Regelabweichungen zwischen Nodes, unerwartete offene Ports und auffällige Verbindungsversuche werden im Dashboard sichtbar und lösen automatische Alerts aus. Firewall-Änderungen landen zudem im Audit-Log — nachvollziehbar und revisionssicher.

Häufige Fragen

Bremst die Proxmox Firewall die VM-Performance?

Der Overhead ist minimal. Da die Firewall auf Kernel-Ebene arbeitet, ist der Durchsatz auch bei hunderten von Regeln kaum messbar beeinträchtigt. In Benchmark-Tests liegt der Einfluss typischerweise unter 1–2 %.

Kann ich Firewall-Regeln per Ansible oder Terraform verwalten?

Ja. Die Proxmox API ist vollständig dokumentiert, und es gibt Terraform-Provider sowie Ansible-Module, die Firewall-Konfigurationen als Code verwalten. Das erleichtert Versionierung und Rollouts.

Was passiert, wenn ich mich versehentlich ausserre?

Bei falscher Node-Firewall-Konfiguration können Sie sich aus der Proxmox-Weboberfläche aussperren. Dann hilft nur der direkte Konsolenzugang (physisch oder IPMI). Testen Sie Node-Firewall-Regeln deshalb immer zuerst in einer Test-Umgebung oder fügen Sie temporäre Accept-Regeln für Ihre aktuelle IP ein.

Sie möchten Ihre Proxmox-Umgebung durch Firewall-Segmentierung und Mikrosegmentierung absichern? Sprechen Sie uns an — wir analysieren Ihre Netzwerktopologie und implementieren ein durchgängiges Sicherheitskonzept für Ihre virtuellen Infrastrukturen.

Proxmox Firewall: VM-Isolation und Mikrosegmentierung im Unternehmen