Wenn Ihre Firewall nicht hört: Der Frust beim Absichern von Proxmox' Port 8006

Es begann als harmloser Test – oder zumindest dachte er das. Ein Homelab-Enthusiast, der Proxmox VE in einem kleinen, aber sorgfältig abgestimmten Setup betrieb, wollte den Zugriff auf sein Management-Interface blockieren. Nichts Aufwendiges, nur ein schneller Firewall-Test. Das Ziel: verhindern, dass irgendjemand die Proxmox-GUI auf Port 8006 erreicht, selbst von innerhalb des Netzwerks.

Aber die Firewall schien es nicht zu kümmern.

Egal welche Regeln er hinzufügte – egal wie präzise die Syntax aussah –, der Proxmox-Port 8006 nahm weiterhin Verbindungen an. Jeder Versuch, den Zugriff zu verweigern, prallte mit einem höhnischen Erfolg zurück: Die Login-Seite lud weiterhin problemlos. Für ein Setup, das eine abgeriegelte Produktionsumgebung simulieren sollte, war das zum Verzweifeln.

Wenn Sie schon einmal mit Virtualisierung herumgebastelt haben, besonders in Homelabs, klingt das vermutlich vertraut. Sie starten mit einer sauberen Proxmox-Installation, virtualisieren vielleicht pfSense als Router oder Firewall, und schon bald jagen Sie Geister durch iptables-Regeln und Bridge-Interfaces. In dem Moment, in dem Sie merken, dass Ihre Firewall nicht das tut, was sie soll, beginnt das eigentliche Debugging.

Der Test, der eigentlich einfach sein sollte

Das Setup war unkompliziert:

• pfSense virtualisiert innerhalb von Proxmox VE.
• enp1s0 als WAN-Interface.
• enp2s0 und enp3s0 gebündelt für LAN.
• Ein privater Adressraum mit 10.10.0.0 für WAN-seitige Tests und 10.0.0.0 für LAN.

Der Nutzer, der externen Zugriff simulieren wollte, schrieb Regeln in /etc/pve/nodes/proxmox/host.fw wie diese:

IN REJECT -i enp1s0 -source 10.10.0.25 -dest 10.10.0.10 -p tcp -dport 8006 -log nolog

und

IN REJECT -i vmbr0 -source 10.10.0.25 -dest 10.10.0.10 -p tcp -dport 8006 -log nolog

Das Ziel war einfach: allen TCP-Traffic auf Port 8006 abweisen, den Standardport von Proxmox für die Web-GUI.

Aber die Realität passte nicht zur Absicht. Selbst nach Aktivierung der Proxmox-Firewall blieb die GUI erreichbar. Die Testmaschine unter 10.10.0.25 konnte sich weiterhin ins Web-Dashboard des Hosts einloggen, als wäre nichts gewesen.

„Ich kann weiterhin von Quelle 10.10.0.25 auf Port 8006 zugreifen", schrieb der Nutzer. „Ich wollte nur wissen, ob mir etwas entgeht – wird der Zugriff auf den Proxmox-VE-Port vielleicht standardmäßig irgendwo anders überschrieben?"

Die Ports, von denen Sie glauben, sie zu kennen

Für die meisten Nutzer sind Proxmox-Ports leicht zu merken. 8006 für die GUI. 22 für SSH. Vielleicht noch ein paar Extras für Cluster-Kommunikation oder die SPICE-Konsole. Aber was oft übersehen wird, ist, wie Proxmox diese Ports intern handhabt.

Die Proxmox-Portnummer 8006 wird nicht einfach von einem Standard-Webdienst geöffnet – sie ist direkt an pveproxy gebunden, einen Daemon, der tief im Management-Stack sitzt. Er läuft als Systemdienst und bindet sich an alle verfügbaren Interfaces, nicht nur an eines. Das bedeutet: Selbst wenn Sie denken, eine Regel auf vmbr0 anzuwenden, lauscht pveproxy möglicherweise weiterhin auf den anderen Bridges oder gebündelten Adaptern des Hosts.

Per Design geht Proxmox VE davon aus, dass sein Management-Interface immer von jedem verbundenen Netzwerk aus erreichbar sein sollte – zumindest bis man es auf einer höheren Ebene anders anweist oder es vollständig über VLANs oder ein reines Management-Subnetz isoliert.

Deshalb war der erste Rat der Community unverblümt: „10.10.0.10 ist keine WAN-Adresse, sondern immer noch eine LAN-Adresse. Wenn Sie den Zugriff auf die Proxmox-Web-GUI von Ihrem LAN aus kontrollieren wollen, kümmern Sie sich um die interne Firewall. Wenn Sie aber den Zugriff aus dem Internet blockieren wollen, ist das die Aufgabe von pfSense."

Das war eine gute Erinnerung daran, dass nicht alle „blockierten Ports" gleich sind. Innerhalb eines Virtualisierungs-Stacks behandeln Host, Gast und die virtuellen Bridges Traffic jeweils unterschiedlich. Man denkt vielleicht, man blockiere Traffic auf einer Ebene, aber er rutscht immer noch durch eine andere.

Schicht um Schicht: Wenn virtuelle Firewalls kollidieren

pfSense innerhalb von Proxmox laufen zu lassen erzeugt ein interessantes Henne-Ei-Problem. Proxmox verwaltet die virtuellen Maschinen, aber pfSense verwaltet das Netzwerk, das Proxmox selbst nutzt.

In diesem Testfall saß der Proxmox-Host hinter pfSense, was bedeutet, dass pfSense den Traffic zu Proxmox nicht wirklich kontrollierte – nur den Traffic durch ihn hindurch. Deshalb ergab es wenig Sinn, den Proxmox-Port 8006 von pfSense aus zu blockieren. Die einzige echte Lösung war, Proxmox' eigene Firewall (pve-firewall) zur Mitarbeit zu bewegen.

Und genau da begann die Verwirrung.

Manche Nutzer im Thread wiesen darauf hin, dass die Firewall auf Host-Ebene von Proxmox tückisch sein kann:

• Man muss sicherstellen, dass sie global aktiviert ist (pvefirewall status).
• Man muss bestätigen, dass die Regeln auf das richtige Interface angewendet werden.
• Und, vielleicht am wichtigsten, Regeln werden der Reihe nach ausgewertet, das heißt: Erlaubt eine weiter oben stehende ACCEPT-Regel die Verbindung, bewirkt die REJECT-Regel darunter gar nichts.

Ein hilfreicher Kommentar empfahl, Logging auf den REJECT-Regeln mit -j LOG zu aktivieren, um zu prüfen, ob sie überhaupt ausgelöst wurden. Spoiler: Das wurden sie nicht.

Es stellte sich heraus, dass entweder die Regelreihenfolge oder die Interface-Zuordnung nicht stimmte – eine subtile, aber häufige Falle im Umgang mit Proxmox' virtuellen Bridges.

VLANs zur Rettung (meistens)

Ein weiterer Nutzer brachte den altbewährten Rat ein: das Management-Interface auf ein dediziertes VLAN legen. Das würde bedeuten, dass Proxmox VE ein „reines Management"-Netzwerk hätte, getrennt von dem, das von virtuellen Maschinen oder dem LAN genutzt wird.

„Ich würde die Proxmox-GUI auf ein separates Management-VLAN legen", schrieb ein Kommentator.

Die Idee ist einfach: Selbst wenn man bei den Firewall-Regeln patzt, haben die normalen LAN-Clients keine Route zum Management-Interface. Es ist physische Trennung, logisch umgesetzt.

Aber das brachte eigene Herausforderungen mit sich. Der ursprüngliche Poster wies darauf hin, dass der Zugriff auf das Management-VLAN nahezu unmöglich wurde, als sein Router ausfiel – besonders, wenn dieser für das Routing der VLANs zuständig war.

Die Antwort? „Lassen Sie einen Port übrig, den Sie zur Fehlersuche direkt ins Management-VLAN einstecken können." Mit anderen Worten: Haben Sie immer einen Notfallplan. Wenn das Routing ausfällt, können Sie sich immer noch direkt ins Netzwerk einstecken und an Ihr Proxmox-Dashboard kommen.

Denn in Homelabs – und selbst in kleinen Produktionsumgebungen – gibt es nichts Schlimmeres, als aus dem eigenen Hypervisor ausgesperrt zu sein.

Warum das Blockieren von Proxmox-Ports schwerer ist, als es aussieht

Auf den ersten Blick klingt das Blockieren einer Proxmox-Portnummer so einfach wie das Schreiben einer Firewall-Regel. Aber Proxmox verhält sich nicht wie ein klassischer Linux-Server. Es verwaltet nicht nur seine eigenen Interfaces, sondern auch virtuelle Bridges, Tunnel und Cluster-Kommunikationskanäle.

Das bedeutet: Wenn Sie glauben, den GUI-Port (8006) ins Visier zu nehmen, müssen Sie womöglich auch bedenken:

• Die Interface-Bindung von pveproxy
• Cluster-Sync-Ports (meist 5400–5405)
• SSH (Port 22) für die Node-Verwaltung
• QEMU-Migrationsports (Bereich 60000–60050)
• Und Konsolenports für SPICE oder noVNC

Mit anderen Worten: Proxmox-Ports sind voneinander abhängig. Einen davon unbedacht zu schließen, kann leicht etwas anderes kaputtmachen – oder Sie schlimmstenfalls komplett aussperren.

Deshalb empfehlen erfahrene Admins einen mehrschichtigen Ansatz:

• Nutzen Sie pfSense oder eine andere Edge-Firewall, um externen Zugriff zu blockieren.
• Konfigurieren Sie die Proxmox-VE-Firewall für interne Segmentierung.
• Und halten Sie, wenn möglich, den Management-Traffic über VLANs oder dedizierte Interfaces isoliert.

Wenn alles andere scheitert, können Sie das Proxmox-Web-Interface an eine bestimmte Adresse binden, indem Sie /etc/default/pveproxy bearbeiten und den Dienst neu starten. Daran denken die wenigsten Homelab-Nutzer, aber es ist ein solider Rückfallplan, falls Ihr Standardport von Proxmox sich weiterhin den falschen Netzwerken zeigt.

Das größere Bild: Kontrolle vs. Komfort

Diese Geschichte handelt nicht nur von einem Proxmox-Port, der sich weigert zu schließen. Sie handelt von der Spannung zwischen Kontrolle und Komfort, die so viele moderne IT-Setups prägt.

Virtualisierung verspricht totale Kontrolle – isolierte Umgebungen, definierte Regeln, perfekte Vorhersagbarkeit. Aber die Realität ist unordentlicher. Je mehr Schichten man hinzufügt (Hypervisor, virtuelle Firewall, VLANs), desto leichter verliert man den Überblick, wer wirklich den Traffic-Fluss kontrolliert.

Für Homelab-Nutzer gehört genau das zum Spaß – und zum Frust. Man lernt, indem man Dinge kaputtmacht. Man verbringt Stunden damit, einen offenen Proxmox-VE-Port zu debuggen, nur um zu entdecken, dass ein Daemon standardmäßig an alle Interfaces gebunden war. Man justiert VLANs, testet HA-Setups, und irgendwann baut man sich ein mentales Modell auf, das sich wie eine lebendige Landkarte des eigenen Netzwerks anfühlt.

Am Ende wird die „Firewall, die nicht hörte" weniger zu einem Bug und mehr zu einem Initiationsritus. Denn hat man erst lange genug mit Proxmox-Ports gekämpft, erkennt man: Der Fix steckt nicht nur in den Config-Dateien – er steckt im Verständnis, wie die gesamte virtuelle Welt zusammenhängt.

Schlussgedanken

Die Ironie an der ganzen Geschichte ist, dass sie als Test begann. Eine einzelne Regel, die eine einzelne Proxmox-Portnummer blockieren sollte, wurde zum Crashkurs in Netzwerksegmentierung, VLAN-Verwaltung und den inneren Abläufen der Firewall eines Hypervisors.

Proxmox VE ist ein mächtiges Werkzeug, aber keine Magie. Der Proxmox-Standardport 8006 ist aus gutem Grund offen – er ist die Lebensader zum System. Und ihn sicher und korrekt zu schließen erfordert mehr als nur eine Firewall-Regel. Es verlangt ein Bewusstsein dafür, wie die Architektur von Proxmox alles miteinander verknüpft.

Wenn sich also das nächste Mal Ihr Proxmox-Port weigert zu schließen, nehmen Sie es nicht persönlich. Es ist nur die Art der Plattform, Sie daran zu erinnern, dass Virtualisierung zwar virtuell sein mag – aber die Probleme, die sie schafft, so real wie eh und je sind.