Zum Inhalt

Proxmox-VE-Firewall sicher für Host und virtuelle Maschinen konfigurieren

Veröffentlicht am 28. August 2026 · Geschätzte Lesezeit: 8 Minuten

Die integrierte Proxmox-VE-Firewall schützt den Verwaltungszugang des Hosts sowie ausgewählte VMs und LXC-Container, ohne eine zusätzliche Firewall zu installieren. Regeln lassen sich getrennt für Datacenter, Knoten und Gäste verwalten; Host-Regeln schützen eine VM oder einen Container jedoch nicht automatisch.[1][6] Plane für Einrichtung, Tests und Rückweg etwa 30 bis 45 Minuten ein.

Voraussetzungen

  • Ein einzelner Proxmox-VE-Host mit Zugriff auf die Weboberfläche
  • Ein bekanntes Management-Netz, zum Beispiel 192.168.178.0/24
  • Eine zweite offene SSH-Sitzung sowie möglichst Monitor und Tastatur oder eine IPMI-/KVM-Konsole
  • Ein aktuelles Backup wichtiger VMs und Container

1. Version, Dienste und Management-Netz erfassen

Öffne die Shell des Proxmox-Hosts und dokumentiere zuerst die installierte Version:

pveversion --verbose

Die aktuelle offizielle Firewall-Dokumentation gehört zu Proxmox VE 9.2.4. Ältere Installationen können andere Bezeichnungen oder nur den klassischen Dienst pve-firewall verwenden.[6]

Zeige anschließend die lauschenden Netzwerkdienste an:

ss -tulpen

Die Proxmox-Weboberfläche verwendet standardmäßig HTTPS auf TCP-Port 8006; SSH verwendet normalerweise TCP-Port 22.[3][7]

Prüfe den klassischen Firewall-Dienst:

systemctl status pve-firewall --no-pager

Bleibt dieser Dienst absichtlich inaktiv und wurde bereits die neue nftables-basierte Variante eingerichtet, prüfe stattdessen:

systemctl status proxmox-firewall --no-pager

Wechsle für diese Anfängeranleitung nicht zwischen beiden Varianten. Die neue nftables-basierte Firewall wird in der aktuellen Dokumentation weiterhin gesondert behandelt; insbesondere FORWARD- und VNet-Regeln funktionieren nicht mit dem klassischen pve-firewall.[1][6]

Notiere jetzt das Netz, aus dem du Proxmox verwaltest. Ersetze <management-netz> durch dieses Netz, zum Beispiel 192.168.178.0/24. Verwende nicht ungeprüft ein größeres Netz wie 192.168.0.0/16, weil dadurch deutlich mehr Geräte Zugriff erhalten.

2. Firewall-Konfiguration sichern und Rückweg öffnen

Ermittle zuerst den Namen des Proxmox-Knotens:

hostname

Sichere die zentrale Firewall-Datei, falls sie bereits vorhanden ist:

test ! -f /etc/pve/firewall/cluster.fw || cp -a /etc/pve/firewall/cluster.fw "/root/cluster.fw-vorher-$(date +%F-%H%M%S)"

Der Befehl lässt eine noch nicht vorhandene Datei in Ruhe. Andernfalls kopiert er sie mit einem Zeitstempel nach /root.

Sichere auch die Knotenkonfiguration. Ersetze <knotenname> durch die Ausgabe von hostname:

test ! -f /etc/pve/nodes/<knotenname>/host.fw || cp -a /etc/pve/nodes/<knotenname>/host.fw "/root/host.fw-vorher-$(date +%F-%H%M%S)"

Lasse eine bestehende SSH-Sitzung offen und öffne die Weboberfläche zusätzlich in einem zweiten Browserfenster. Eine lokale oder IPMI-/KVM-Konsole ist der zuverlässigste Rückweg. Auch die geprüfte Praxisquelle warnt ausdrücklich vor einer Aussperrung und empfiehlt einen zweiten Testzugang.[4]

Danger

Aktiviere niemals eine Eingangsrichtlinie DROP, bevor Regeln für dein tatsächliches Management-Netz erfolgreich getestet wurden. Schließe die vorhandene SSH-Sitzung erst ganz am Ende.

3. Firewall zunächst mit sicherer Eingangsrichtlinie aktivieren

Öffne in der Proxmox-Weboberfläche Datacenter → Firewall → Options.

  1. Setze Input Policy zunächst auf ACCEPT.
  2. Lasse Output Policy auf ACCEPT.
  3. Setze Firewall auf Yes.

Die Firewall ist in der Standardkonfiguration nicht global aktiviert. Proxmox empfiehlt, vor dem Aktivieren eine SSH-Verbindung geöffnet zu lassen.[1][6]

Kontrolliere sofort in beiden Browserfenstern, ob die Weboberfläche weiter reagiert. Öffne außerdem eine neue SSH-Sitzung. Schlägt bereits einer dieser Tests fehl, ändere keine weitere Richtlinie und nutze den Rückweg aus Schritt 9.

4. Verwaltungszugriff ausdrücklich erlauben

Öffne Datacenter → Firewall → Rules und füge eine Regel für die Weboberfläche hinzu:

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: <management-netz>
Dest. port: 8006
Comment: Proxmox-Weboberfläche aus Management-Netz
Enable: Yes

<management-netz> ersetzt du zum Beispiel durch 192.168.178.0/24. Port 8006 ist der offizielle HTTPS-Port der Proxmox-Weboberfläche.[3][7]

Füge danach die SSH-Regel hinzu:

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: <management-netz>
Dest. port: 22
Comment: SSH aus Management-Netz
Enable: Yes

Verwendet dein SSH-Dienst nachweislich einen anderen Port, trägst du statt 22 genau diesen Port ein. Prüfe ihn vorher mit ss -tulpen.

Wenn du Proxmox über ein VPN verwaltest, lege zusätzliche Regeln für das tatsächliche VPN-Netz an. Ersetze die LAN-Regeln erst, wenn Weboberfläche und SSH über das VPN zuverlässig getestet wurden.

5. Erlaubende Regeln testen und Eingangsverkehr begrenzen

Öffne die Weboberfläche in einem privaten Browserfenster aus dem erlaubten Management-Netz. Baue außerdem eine vollständig neue SSH-Verbindung auf:

ssh <proxmox-benutzer>@<proxmox-ip>

Ersetze <proxmox-benutzer> durch dein vorhandenes Administratorkonto. Ersetze <proxmox-ip> durch die interne IP-Adresse des Hosts. Eine bereits offene Verbindung reicht als Test nicht aus, weil sie durch die zustandsbehaftete Firewall weiterlaufen kann.

Sind beide neuen Verbindungen erfolgreich, öffne Datacenter → Firewall → Options und ändere Input Policy von ACCEPT auf DROP. Die Ausgangsrichtlinie bleibt ACCEPT.

Teste Weboberfläche und eine neue SSH-Verbindung sofort erneut. Prüfe bei sicher vorhandener zweiter Netzstrecke zusätzlich, dass ein Gerät außerhalb von <management-netz> keinen Verwaltungszugriff erhält.

Warning

Die Proxmox-Firewall filtert IPv4 und IPv6.[1][6] Teste deshalb auch vorhandene IPv6-Zugänge. Eine enge IPv4-Regel schützt nicht vor einem übersehenen Verwaltungszugriff über eine andere IPv6-Verbindung.

6. Firewall einer Test-VM oder eines Containers aktivieren

Regeln für Datacenter und Knoten schützen den Host, werden aber nicht einfach zu Gastregeln. Eine VM oder ein Container benötigt eigene Regeln, eine aktivierte Gast-Firewall und zusätzlich das Firewall-Häkchen am jeweiligen virtuellen Netzwerkgerät.[1][5][6]

Wähle zuerst einen unkritischen Testgast und öffne VM/CT → Firewall → Options. Lasse dessen Input Policy zunächst auf ACCEPT und setze Firewall auf Yes.

Öffne danach Hardware → Network Device → Edit und aktiviere Firewall für die verwendete Netzwerkschnittstelle. Bei mehreren Schnittstellen musst du jede benötigte Schnittstelle einzeln prüfen.

Benötigt der Gast seine Adresse per DHCP, aktiviere unter den Firewall-Optionen des Gasts auch die passende DHCP-Unterstützung oder erstelle dafür geprüfte Regeln. Ändere nicht gleichzeitig Netzwerkadresse, Gast-Firewall und Dienstkonfiguration.

7. Nur benötigte Gastdienste freigeben

Öffne VM/CT → Firewall → Rules. Für einen internen HTTPS-Dienst könnte die Regel so aussehen:

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: <client-netz>
Dest. port: 443
Comment: HTTPS aus freigegebenem Netz
Enable: Yes

Ersetze <client-netz> durch das Netz, aus dem der Dienst wirklich erreichbar sein soll. Port 443 ist hier nur ein Beispiel für einen HTTPS-Dienst. Verwende den tatsächlich von deiner Anwendung belegten Port.

Für SSH zu diesem Gast legst du nur bei Bedarf eine getrennte Regel an:

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: <management-netz>
Dest. port: 22
Comment: Gast-SSH aus Management-Netz
Enable: Yes

Teste beide erlaubten Dienste. Setze erst danach unter VM/CT → Firewall → Options die Input Policy des Gasts auf DROP. Prüfe erneut, dass der erlaubte Dienst erreichbar und ein nicht freigegebener Port blockiert ist.

8. Protokolle, Regeln und Neustart prüfen

Kontrolliere den Firewall-Status des verwendeten klassischen Dienstes:

pve-firewall status

Prüfe zusätzlich den Systemd-Dienst:

systemctl status pve-firewall --no-pager

Verwendest du bewusst die neue nftables-basierte Variante, lautet die passende Dienstprüfung stattdessen:

systemctl status proxmox-firewall --no-pager

Öffne in der Weboberfläche den Bereich Firewall → Log auf der jeweils geprüften Ebene. Aktiviere Regel-Logging nur gezielt, da ausführliche Firewall-Protokolle schnell viele Einträge erzeugen können.[1]

Starte den Testgast zu einem geplanten Zeitpunkt neu und prüfe danach erneut seinen erlaubten Dienst. Nach einem späteren Host-Neustart müssen Weboberfläche, neue SSH-Verbindungen und die freigegebenen Gastdienste ebenfalls noch funktionieren.

9. Rückweg bei einer Aussperrung verwenden

Wenn nur ein Gast nicht mehr erreichbar ist, deaktiviere über die Proxmox-Weboberfläche zuerst dessen Firewall oder das Firewall-Häkchen an der betroffenen Netzwerkschnittstelle. Korrigiere anschließend Quellnetz, Protokoll und Zielport.

Ist der Host nicht mehr über das Netz erreichbar, melde dich an der lokalen oder IPMI-/KVM-Konsole an. Zeige vorhandene Sicherungen an:

ls -l /root/cluster.fw-vorher-* /root/host.fw-vorher-* 2>/dev/null

Vergleiche die aktuelle zentrale Konfiguration mit der passenden Sicherung. Ersetze <sicherungsdatei> durch den vollständigen Dateinamen:

diff -u <sicherungsdatei> /etc/pve/firewall/cluster.fw

Stelle nur dann die zentrale Datei wieder her, wenn du die richtige Sicherung eindeutig identifiziert hast:

cp -a <sicherungsdatei> /etc/pve/firewall/cluster.fw

Starte bei der in dieser Anleitung verwendeten klassischen Variante den Dienst neu:

systemctl restart pve-firewall

Teste danach zuerst den lokalen Zustand und anschließend eine neue Verbindung. Führe keine pauschalen iptables- oder nft-Flush-Befehle aus: Sie können weitere, von Proxmox oder anderen Diensten verwaltete Regeln entfernen.

10. Typische Fehler und besondere Risiken prüfen

  • Weboberfläche und SSH sind gesperrt: Die DROP-Richtlinie wurde vor den erlaubenden Management-Regeln aktiviert oder das Quellnetz ist falsch. Nutze die Konsole und den Rückweg aus Schritt 9.
  • Die Gastregel hat keine Wirkung: Prüfe sowohl VM/CT → Firewall → Options als auch das Firewall-Häkchen am virtuellen Netzwerkgerät.[1][6]
  • Eine bestehende Verbindung funktioniert, eine neue nicht: Teste immer mit einem privaten Browserfenster und einer vollständig neuen SSH-Verbindung.
  • IPv4 ist geschützt, IPv6 aber erreichbar: Kontrolliere IPv6-Netze und teste beide Protokollfamilien; Proxmox unterstützt beide.[1][6]
  • Ein Cluster verliert Kommunikation: Ein Cluster benötigt zusätzliche Regeln für Corosync, Migration, SSH und gegebenenfalls Ceph. Diese Einzelhost-Anleitung darf nicht unverändert auf einen Cluster übertragen werden.[3]
  • FORWARD- oder VNet-Regeln werden ignoriert: Diese Funktionen setzen die nftables-basierte Proxmox-Firewall voraus.[1][6]
  • Zu viele Logeinträge entstehen: Reduziere Logging auf die Regeln, die du gerade untersuchst.

Die Host-Firewall ersetzt keine Netzsegmentierung, Router-Firewall oder sichere VPN-Lösung. Veröffentliche die Proxmox-Weboberfläche nicht direkt im Internet; beschränke Verwaltungszugänge auf ein vertrauenswürdiges Management- oder VPN-Netz.[4]

Grundlage dieser Anleitung sind die aktuelle offizielle Proxmox-VE-Firewall-Dokumentation, die offizielle Firewall-Wiki-Seite und die Portübersicht, geprüft am 28. August 2026. Als Praxisabgleich dient der Proxmox VE Hardening Guide; das öffentlich zugängliche Video How to Configure the Firewall on Proxmox zeigt die getrennten Ebenen Datacenter, Node und VM/Container.[4][5]

Sources: [1] https://pve.proxmox.com/wiki/Firewall — Firewall - Proxmox VE [3] https://pve.proxmox.com/wiki/Ports — Ports - Proxmox VE [4] https://www.hacknwatch.com/posts/proxmox-ve-hardening — Proxmox VE Hardening Guide [5] https://www.youtube.com/watch?v=SnjBjU9irtg — How to Configure the Firewall on Proxmox [6] https://pve.proxmox.com/pve-docs/chapter-pve-firewall.html — Proxmox VE Firewall [7] https://pve.proxmox.com/pve-docs/pveproxy.8.html — pveproxy(8)

Fertig

Die Proxmox-VE-Firewall schützt jetzt den Host und den ausgewählten Testgast mit getrennten, nachvollziehbaren Regeln. Die Funktionsprüfung ist abgeschlossen, wenn Weboberfläche und neue SSH-Verbindungen nur aus dem erlaubten Management-Netz funktionieren, der Gast ausschließlich seine freigegebenen Dienste anbietet, die Firewall-Dienste aktiv sind und der Konsolenzugriff als Rückweg bereitsteht.