WZ-IT unterstützt bei Setup und Netzwerkplanung für Proxmox auf Hetzner. Gespräch vereinbaren.
Ein dedizierter Hetzner-Server hat standardmäßig eine öffentliche IPv4. Mehrere VMs und eine Firewall-VM brauchen dahinter ein eigenes Netz: entweder mit NAT hinter der Host-IP oder mit zusätzlich zugeteilten Adressen. Dieser Artikel zeigt die NAT-Variante mit Beispielkonfiguration für Host und Firewall-VM, grenzt sie von Routed und Bridged ab und nennt Prüfschritte. Stand: Oktober 2026.
Inhalt
- Eine IPv4 ist keine öffentliche IP je VM
- NAT, Routed und Zusatz-IPs unterscheiden
- Beispiel: NAT hinter der Host-IP
- Firewall-VM mit OPNsense, pfSense oder VyOS
- Management und Abnahme
- Typische Fehler
Eine IPv4 ist keine öffentliche IP je VM
Mehrere private Gäste können über NAT dieselbe öffentliche IPv4 für ausgehende Verbindungen nutzen. Eine einzelne IPv4 wird dadurch nicht zu mehreren unabhängig adressierbaren IPs. Das Hetzner-Community-Tutorial unterscheidet Bridged, Routed und Masquerading. Bei Hetzner ist jede IP an den Server und seine MAC-Adresse gebunden; für gebridgte Zusatz-IPs ist eine virtuelle MAC im Robot-Panel nötig.
In dieser Anleitung bleibt der Host der öffentliche Endpunkt. Dahinter liegt ein privates Transitnetz zur Firewall-VM und danach das Gastnetz. IPv6 ist separat zu planen.
NAT, Routed und Zusatz-IPs unterscheiden
| Weg | Zuordnung | Vorher klären |
|---|---|---|
| Eine IPv4 mit NAT | Öffentliche IP am Host, private Gäste | Portbelegung und Rückweg |
| Zusätzliche Einzel-IP | Eigene öffentliche Gastadresse | Routing oder freigegebene virtuelle MAC |
| Geroutetes Subnetz | Host als Router zum Gastnetz | Providerroute und Gastgateway |
| vSwitch mit öffentlichem Subnetz | Eigenes Netz über den vSwitch | VLAN, Subnetz und Gateway |
Hetzner Additional IPs beschreibt die Unterschiede von Bridging und Routing sowie die virtuelle MAC für zusätzliche Einzel-IPs. Diese MAC-Regeln nicht auf beliebige Subnetze übertragen. Der vSwitch ist ein gesonderter Netzpfad; er ersetzt weder eine zusätzliche IP-Zuteilung noch eine Firewall.
Beispiel: NAT hinter der Host-IP
Die Konfiguration folgt dem Masquerading-Muster der Proxmox-Netzwerkdokumentation und des Hetzner-Tutorials. Die Adressen stammen aus dem Dokumentationsbereich (198.51.100.0/24) und aus privaten Netzen; Uplink-Name, öffentliche IP und Gateway kommen aus der bestehenden Konfiguration. Den Namen des Uplinks zeigt ip -br link.
1. Forwarding aktivieren in /etc/sysctl.d/ip-forwarding.conf:
net.ipv4.ip_forward = 1
sysctl --system
2. Privates Gastnetz mit Masquerading in /etc/network/interfaces, unterhalb der vorhandenen Uplink-Konfiguration. <uplink> steht für das ausgehende Interface, je nach Installation vmbr0 oder die physische Netzwerkkarte:
auto vmbr1
iface vmbr1 inet static
address 10.10.10.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o <uplink> -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o <uplink> -j MASQUERADE
3. Gäste anbinden: Die VM erhält ihre Netzwerkkarte an vmbr1, eine Adresse aus 10.10.10.0/24 und als Gateway 10.10.10.1.
4. Eingehenden Dienst weiterleiten (Beispiel HTTPS auf eine VM mit 10.10.10.20), ebenfalls im Block von vmbr1:
post-up iptables -t nat -A PREROUTING -i <uplink> -p tcp --dport 443 -j DNAT --to-destination 10.10.10.20:443
post-down iptables -t nat -D PREROUTING -i <uplink> -p tcp --dport 443 -j DNAT --to-destination 10.10.10.20:443
5. Anwenden: Netzwerk neu laden und danach laufende VMs stoppen und starten, wie es das Hetzner-Tutorial vorsieht. Vorher externen Konsolenzugang oder Rescue-System bereithalten.
Ein Neustart des Netzwerks kann die Verbindung trennen, wenn die Konfiguration einen Fehler enthält. Ohne Konsolen- oder Rescue-Zugang keine Änderungen an der Uplink-Konfiguration vornehmen.
Firewall-VM mit OPNsense, pfSense oder VyOS
OPNsense, pfSense und VyOS dokumentieren Quell- und Ziel-NAT. Die Firewall-VM lohnt sich bei mehreren Gastnetzen, VPN-Terminierung oder detaillierten Filterregeln. Für eine einzige Host-IP genügt das Masquerading des vorigen Abschnitts.
Aufbau mit zwei Bridges ohne Adresse am Gastnetz:
| Netz | Bridge | Adressen | Zweck |
|---|---|---|---|
| Transit | vmbr1 |
Host 10.255.0.1/30, Firewall-WAN 10.255.0.2/30 | Verbindung Host zu Firewall-WAN |
| Gastnetz | vmbr2 |
Firewall-LAN 192.168.10.1/24, Gäste 192.168.10.x | Netz hinter der Firewall |
auto vmbr1
iface vmbr1 inet static
address 10.255.0.1/30
bridge-ports none
bridge-stp off
bridge-fd 0
post-up iptables -t nat -A POSTROUTING -s 10.255.0.0/30 -o <uplink> -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s 10.255.0.0/30 -o <uplink> -j MASQUERADE
auto vmbr2
iface vmbr2 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
- Die Firewall-VM erhält
net0anvmbr1(WAN: 10.255.0.2/30, Gateway 10.255.0.1) undnet1anvmbr2(LAN: 192.168.10.1/24). - Das WAN-Interface liegt in einem privaten Netz. Die Option, private Netze am WAN zu blockieren, deshalb abschalten, sonst verwirft die Firewall den Verkehr vom Host.
- Eingehende Dienste vom Host per DNAT zur Firewall-WAN-Adresse 10.255.0.2 weiterleiten, die Portzuordnung zu Gästen erfolgt dann in der Firewall.
- Gäste verwenden die Firewall (192.168.10.1) als Gateway. Bei NAT auf Host und Firewall den doppelten Übersetzungsweg dokumentieren.
- Rückrouten und erlaubte Dienste auf beiden Ebenen prüfen. Kein pauschales Weiterleiten sämtlicher Ports.
Regeln aus iptables-Beispielen nicht ungeprüft mit einem anderen aktiven Firewall-Backend kombinieren. Bei aktiver Proxmox-Firewall nennt die Proxmox-Dokumentation zusätzliche Hinweise zu Conntrack-Zonen für Masquerading.
Management und Abnahme
Die Firewall-VM läuft auf dem Host, dessen Zugang sie vermitteln kann. Planen Sie deshalb einen Wiederanlauf, der ohne diese VM funktioniert. Halten Sie eine Kopie der Netzkonfiguration und einen Rückbauplan bereit. Die Verwaltungsoberfläche auf Port 8006 nicht über NAT veröffentlichen, sondern per VPN oder mit IP-Filter erreichbar machen.
Prüfen und protokollieren Sie nach der Einrichtung:
iptables -t nat -L -n -v # NAT-Regeln und Zähler auf dem Host
ip -br addr # Adressen der Bridges
curl -4 ifconfig.me # im Gast: ausgehende Quell-IP, soll die Host-IP sein
Dazu DNS im Gast, eingehende freigegebene Ports, gesperrte Ports, Management-Zugriff bei gestoppter Firewall-VM sowie das Verhalten nach einem Neustart des Hosts. Erst den isolierten Gast, dann weitere Netze anbinden.
Typische Fehler
- Gast hat keine Verbindung:
net.ipv4.ip_forwardist nicht aktiv, das Gateway im Gast stimmt nicht oder das-o-Interface der MASQUERADE-Regel ist nicht der Uplink. - Zusatz-IP geht nicht: Bei gebridgten Zusatz-IPs fehlt die virtuelle MAC im Robot-Panel oder die VM sendet mit einer anderen MAC.
- Regeln fehlen nach Neustart: iptables-Regeln stehen nicht in
post-up-Zeilen der Netzwerkkonfiguration. - Firewall verwirft den Transitverkehr: Die Blockierung privater Netze am WAN-Interface der Firewall-VM ist aktiv.
- Zugriff auf den Host abgebrochen: Die Änderung wurde ohne Konsolenzugang über die betroffene Verbindung ausgeführt.
Weiterführende Guides
- Proxmox auf Hetzner installieren: ZFS RAID1 Single-Node mit Auto-Install-Skript
- Proxmox Cluster Netzwerk auf Hetzner: vSwitch und Private Networks einrichten
WZ-IT unterstützt bei Setup und Netzwerkplanung für Proxmox auf Hetzner. Gespräch vereinbaren.










