Proxmox on Hetzner with one IP and a firewall VM

WZ-IT supports setup and network planning for Proxmox on Hetzner. Arrange a conversation.

A dedicated Hetzner server comes with one public IPv4 by default. Several VMs and a firewall VM need their own network behind it: either NAT behind the host IP or additionally allocated addresses. This article shows the NAT approach with example configuration for the host and the firewall VM, separates it from routed and bridged setups and lists checks. As of October 2026.

Contents

• One IPv4 is not a public IP per VM
• Distinguish NAT, routed networks and additional IPs
• Example: NAT behind the host IP
• Firewall VM with OPNsense, pfSense or VyOS
• Management and acceptance
• Common mistakes

One IPv4 is not a public IP per VM

Several private guests can share one public IPv4 for outbound connections through NAT. This does not create multiple independently addressable IPs. The Hetzner Community tutorial distinguishes bridged, routed and masquerading setups. At Hetzner every IP is bound to the server and its MAC address; bridged additional IPs need a virtual MAC in the Robot panel.

In this guide the host remains the public endpoint. Behind it sits a private transit network to the firewall VM and then the guest network. Plan IPv6 separately.

Distinguish NAT, routed networks and additional IPs

Hetzner Additional IPs explains bridging versus routing and virtual MACs for additional individual IPs. Do not transfer these MAC rules to arbitrary subnets. The vSwitch is a separate network path; it replaces neither an IP allocation nor a firewall.

Example: NAT behind the host IP

The configuration follows the masquerading pattern of the Proxmox networking documentation and the Hetzner tutorial. The addresses come from the documentation range (198.51.100.0/24) and from private networks; uplink name, public IP and gateway come from the existing configuration. ip -br link shows the uplink name.

1. Enable forwarding in /etc/sysctl.d/ip-forwarding.conf:

net.ipv4.ip_forward = 1

sysctl --system

2. Private guest network with masquerading in /etc/network/interfaces, below the existing uplink configuration. <uplink> stands for the outbound interface, vmbr0 or the physical network card depending on the installation:

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. Attach guests: The VM gets its network card on vmbr1, an address from 10.10.10.0/24 and 10.10.10.1 as gateway.

4. Forward an inbound service (example HTTPS to a VM at 10.10.10.20), also in the vmbr1 block:

    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. Apply: Reload the network, then stop and start running VMs as the Hetzner tutorial prescribes. Have external console access or the rescue system ready beforehand.

Restarting the network can cut the connection if the configuration contains an error. Do not change the uplink configuration without console or rescue access.

Firewall VM with OPNsense, pfSense or VyOS

OPNsense, pfSense and VyOS document source and destination NAT. A firewall VM pays off with several guest networks, VPN termination or detailed filter rules. With a single host IP the masquerading from the previous section is enough.

Layout with two bridges and no address on the guest network:

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

1. The firewall VM gets net0 on vmbr1 (WAN: 10.255.0.2/30, gateway 10.255.0.1) and net1 on vmbr2 (LAN: 192.168.10.1/24).
2. The WAN interface sits in a private network. Therefore switch off the option that blocks private networks on the WAN, otherwise the firewall drops traffic from the host.
3. Forward inbound services from the host by DNAT to the firewall WAN address 10.255.0.2; the port mapping to guests is then done in the firewall.
4. Guests use the firewall (192.168.10.1) as gateway. If host and firewall both perform NAT, document both translation stages.
5. Check return routes and allowed services on both levels. Do not forward every port.

Do not combine iptables examples with a different active firewall backend without checking compatibility. With the Proxmox firewall active, the Proxmox documentation gives additional notes on conntrack zones for masquerading.

Management and acceptance

The firewall VM runs on the host whose access it may provide. Plan recovery that works without that VM. Keep a copy of the network configuration and a rollback plan. Do not publish the management interface on port 8006 through NAT; make it reachable through a VPN or with an IP filter.

After setup, check and record:

iptables -t nat -L -n -v      # NAT rules and counters on the host
ip -br addr                   # addresses of the bridges
curl -4 ifconfig.me           # in the guest: outbound source IP, should be the host IP

Also DNS in the guest, permitted inbound ports, blocked ports, management access with the firewall VM stopped, and behavior after a host reboot. Connect an isolated guest before adding other networks.

Common mistakes

• Guest has no connectivity: net.ipv4.ip_forward is not active, the guest gateway is wrong or the -o interface of the MASQUERADE rule is not the uplink.
• Additional IP does not work: For bridged additional IPs the virtual MAC is missing in the Robot panel or the VM sends with a different MAC.
• Rules missing after reboot: The iptables rules are not in post-up lines of the network configuration.
• Firewall drops transit traffic: Blocking of private networks on the firewall VM's WAN interface is active.
• Access to the host lost: The change was made without console access over the connection it affected.

Related guides

• Proxmox on Hetzner: ZFS RAID1 Single-Node Setup with Auto-Install Script
• Proxmox Cluster Networking on Hetzner: Using Private Networks + vSwitch Properly

WZ-IT supports setup and network planning for Proxmox on Hetzner. Arrange a conversation.

Sources

• community.hetzner.com: Install and Configure Proxmox VE
• docs.hetzner.com: Additional IPs
• docs.hetzner.com: vSwitch
• pve.proxmox.com: Administration Guide, networking
• docs.opnsense.org: NAT
• docs.netgate.com: pfSense NAT
• docs.vyos.io: NAT44