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

Es begann als harmloser Test, dachte er zumindest. 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 mit dem Ziel, dass niemand die Proxmox-GUI auf Port 8006 erreicht, auch nicht aus dem eigenen Netzwerk.

Die Firewall schien das nicht zu interessieren. Egal welche Regeln er hinzufügte und wie präzise die Syntax aussah, der Proxmox-Port 8006 nahm weiter Verbindungen an. Jeder Versuch, den Zugriff zu verweigern, endete mit einem höhnischen Erfolg, denn die Login-Seite lud jedes Mal problemlos. Für ein Setup, das eine abgeriegelte Produktionsumgebung simulieren sollte, war das zum Verzweifeln.

Wer schon einmal mit Virtualisierung herumgebastelt hat, besonders im Homelab, kennt das vermutlich. Man startet mit einer sauberen Proxmox-Installation, virtualisiert vielleicht pfSense als Router oder Firewall, und bald jagt man Geister durch iptables-Regeln und Bridge-Interfaces. Sobald man merkt, dass die Firewall nicht tut, was sie soll, fängt das eigentliche Debugging an.

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.

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

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 klar: allen TCP-Traffic auf Port 8006 abweisen, dem Standardport der Proxmox-Web-GUI.

Die Realität sah anders aus. Auch nach dem Aktivieren der Proxmox-Firewall blieb die GUI erreichbar, und die Testmaschine unter 10.10.0.25 konnte sich weiter 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

Die meisten Nutzer haben die Proxmox-Ports schnell im Kopf: 8006 für die GUI, 22 für SSH, vielleicht noch ein paar Extras für Cluster-Kommunikation oder die SPICE-Konsole. Oft übersehen wird, wie Proxmox diese Ports intern handhabt.

Port 8006 öffnet kein gewöhnlicher Webdienst. Er ist direkt an pveproxy gebunden, einen Daemon, der tief im Management-Stack sitzt, als Systemdienst läuft und sich an alle verfügbaren Interfaces bindet. Auch wenn Sie also glauben, eine Regel auf vmbr0 anzuwenden, lauscht pveproxy womöglich weiter auf den anderen Bridges oder gebündelten Adaptern des Hosts.

Proxmox VE geht von Haus aus davon aus, dass sein Management-Interface aus jedem verbundenen Netzwerk erreichbar sein soll, bis man es auf einer höheren Ebene anders festlegt oder es über VLANs oder ein reines Management-Subnetz vollständig isoliert.

Der erste Rat aus der Community fiel deshalb unverblümt aus: „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 erinnerte gut daran, dass „blockierte Ports" nicht alle gleich sind. In einem Virtualisierungs-Stack behandeln Host, Gast und virtuelle Bridges Traffic jeweils unterschiedlich. Man glaubt, Traffic auf einer Ebene zu blockieren, und er rutscht auf einer anderen durch.

Schicht um Schicht: Wenn virtuelle Firewalls kollidieren

pfSense innerhalb von Proxmox zu betreiben, erzeugt ein hübsches Henne-Ei-Problem. Proxmox verwaltet die virtuellen Maschinen, pfSense aber das Netzwerk, das Proxmox selbst nutzt.

In diesem Testfall saß der Proxmox-Host hinter pfSense. pfSense kontrollierte also den Traffic durch sich hindurch, aber nicht den Traffic zu Proxmox. Den Proxmox-Port 8006 von pfSense aus zu blockieren, ergab deshalb wenig Sinn, und als echte Lösung blieb nur, Proxmox' eigene Firewall (pve-firewall) zur Mitarbeit zu bewegen.

Genau dort begann die Verwirrung. Einige Nutzer im Thread wiesen darauf hin, dass die Host-Firewall von Proxmox ihre Tücken hat:

• Sie muss global aktiviert sein (pvefirewall status).
• Die Regeln müssen auf das richtige Interface angewendet werden.
• Und, vielleicht am wichtigsten, die Regeln werden der Reihe nach ausgewertet. Erlaubt eine weiter oben stehende ACCEPT-Regel die Verbindung, bewirkt die REJECT-Regel darunter gar nichts.

Ein hilfreicher Kommentar empfahl, auf den REJECT-Regeln Logging mit -j LOG zu aktivieren, um zu sehen, ob sie überhaupt greifen. Kleiner Spoiler: Sie griffen nicht.

Am Ende stimmte entweder die Regelreihenfolge oder die Interface-Zuordnung nicht, eine unscheinbare, aber häufige Falle bei Proxmox' virtuellen Bridges.

VLANs zur Rettung (meistens)

Ein weiterer Nutzer kam mit dem altbewährten Rat, das Management-Interface in ein eigenes VLAN zu legen. Proxmox VE hätte dann ein reines Management-Netzwerk, getrennt von dem, das virtuelle Maschinen oder das LAN nutzen.

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

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

Das bringt allerdings eigene Probleme mit sich. Der ursprüngliche Poster merkte an, dass er kaum noch ins Management-VLAN kam, als sein Router ausfiel, vor allem weil dieser das Routing der VLANs übernahm.

Die Antwort darauf: „Lassen Sie einen Port übrig, den Sie zur Fehlersuche direkt ins Management-VLAN einstecken können." Man braucht also immer einen Notfallplan, damit man sich bei ausgefallenem Routing direkt ins Netzwerk einstecken und das Proxmox-Dashboard erreichen kann. Im Homelab und auch in kleinen Produktionsumgebungen gibt es kaum etwas 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 es, als müsse man für einen Proxmox-Port nur eine Firewall-Regel schreiben. Proxmox verhält sich aber nicht wie ein klassischer Linux-Server. Es verwaltet neben seinen eigenen Interfaces auch virtuelle Bridges, Tunnel und Kanäle für die Cluster-Kommunikation.

Wer den GUI-Port (8006) ins Visier nimmt, muss deshalb womöglich auch Folgendes bedenken:

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

Die Proxmox-Ports hängen also voneinander ab. Schließt man einen davon unbedacht, geht leicht etwas anderes kaputt, oder man sperrt sich im schlimmsten Fall komplett aus.

Erfahrene Admins empfehlen deshalb mehrere Schichten:

• pfSense oder eine andere Edge-Firewall blockiert den externen Zugriff.
• Die Proxmox-VE-Firewall übernimmt die interne Segmentierung.
• Und wenn möglich bleibt der Management-Traffic über VLANs oder dedizierte Interfaces isoliert.

Hilft das alles nicht, 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, dabei ist es ein solider Rückfallplan, wenn sich der Standardport von Proxmox weiter in den falschen Netzwerken zeigt.

Das größere Bild: Kontrolle vs. Komfort

In dieser Geschichte steckt mehr als ein Proxmox-Port, der sich nicht schließen lässt. Sie zeigt die Spannung zwischen Kontrolle und Komfort, die viele moderne IT-Setups prägt.

Virtualisierung verspricht totale Kontrolle mit isolierten Umgebungen, definierten Regeln und perfekter Vorhersagbarkeit. Die Realität ist unordentlicher. Je mehr Schichten dazukommen (Hypervisor, virtuelle Firewall, VLANs), desto leichter verliert man den Überblick, wer den Traffic-Fluss wirklich steuert.

Für Homelab-Nutzer gehört genau das zum Spaß und zum Frust. Man lernt, indem man Dinge kaputtmacht. Man debuggt stundenlang einen offenen Proxmox-VE-Port und entdeckt dann, dass ein Daemon standardmäßig an alle Interfaces gebunden war. Man justiert VLANs, testet HA-Setups und baut sich nach und nach ein mentales Modell, das sich wie eine lebendige Landkarte des eigenen Netzwerks anfühlt.

Die „Firewall, die nicht hörte" wird so eher zum Initiationsritus als zum Bug. Wer lange genug mit Proxmox-Ports gekämpft hat, merkt, dass die Lösung zum Teil in den Config-Dateien liegt und zum anderen Teil im Verständnis, wie diese ganze virtuelle Welt zusammenhängt.

Schlussgedanken

Ironischerweise fing alles als Test an. Eine einzelne Regel für eine einzelne Proxmox-Portnummer wurde zum Crashkurs in Netzwerksegmentierung, VLAN-Verwaltung und dem Innenleben der Firewall eines Hypervisors.

Proxmox VE ist ein mächtiges Werkzeug, aber keine Magie. Der Proxmox-Standardport 8006 ist aus gutem Grund offen, denn über ihn erreicht man das System. Ihn sicher und korrekt zu schließen, braucht mehr als eine Firewall-Regel, nämlich ein Verständnis dafür, wie die Architektur von Proxmox alles miteinander verknüpft.

Wenn sich Ihr Proxmox-Port also das nächste Mal nicht schließen lässt, nehmen Sie es nicht persönlich. Die Plattform erinnert Sie nur daran, dass Virtualisierung virtuell sein mag, die Probleme, die sie schafft, aber so real sind wie eh und je.