Proxmox VE with one public IP: a NAT bridge and port forwarding for your VMs

A Proxmox node usually bridges VMs straight onto the network (vmbr0), and each VM takes its own public address. With one public IPv4 address that doesn’t work — your provider won’t route a second address to a MAC it doesn’t know. The usual answer is a private bridge with no physical port, NAT out through the node, and port forwards for anything you want to reach from outside.

1. Add a private NAT bridge
2. Point a VM at it
3. Forward a port to a VM
4. Firewalls: three places to open a port
5. If you route another network to the node (VPN)
6. What this can’t do

1. Add a private NAT bridge

Append this to /etc/network/interfaces. vmbr1 gets a private subnet; the node is .1 and acts as the VMs’ gateway, masquerading their traffic out of vmbr0.

auto vmbr1
iface vmbr1 inet static
	address 192.168.100.1/24
	bridge-ports none
	bridge-stp off
	bridge-fd 0
	post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
	post-up   iptables -t nat -A POSTROUTING -s '192.168.100.0/24' -o vmbr0 -j MASQUERADE
	post-down iptables -t nat -D POSTROUTING -s '192.168.100.0/24' -o vmbr0 -j MASQUERADE

Bring it up without a reboot: ifup vmbr1. The Proxmox network guide describes the same setup; if you turn on the Proxmox firewall for VMs, add the connection-tracking zone lines it gives for this case.

2. Point a VM at it

Give the VM a network device on vmbr1. There’s no DHCP server on this bridge, so configure the VM statically — in the guest, or with Proxmox’s Cloud-Init settings:

• Address: 192.168.100.10/24 (any free address in the subnet)
• Gateway: 192.168.100.1
• DNS: a public resolver such as 1.1.1.1

From the VM, ping 1.1.1.1 should now work. If it doesn’t, check cat /proc/sys/net/ipv4/ip_forward on the node (must be 1) and iptables -t nat -S POSTROUTING (the MASQUERADE rule must be there).

3. Forward a port to a VM

To reach a web server on that VM at http://your-ip:8080, forward the node’s port 8080 to the VM’s port 80. Add the rules to the vmbr1 stanza so they come back after a reboot:

	post-up   iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.100.10:80
	post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.100.10:80

Apply with ifreload -a (or ifdown vmbr1 && ifup vmbr1), then test from outside the node — a forward on vmbr0 doesn’t apply to connections made from the node itself, which should use 192.168.100.10 directly.

4. Firewalls: three places to open a port

1. Your provider’s firewall, if there is one in front of the server. (On Piedmont Hosting that’s the Cloud Firewall tab: add an inbound rule for the outside port, e.g. TCP 8080.)
2. The Proxmox firewall, if enabled at datacenter, node or VM level.
3. The firewall inside the VM (ufw, firewalld, Windows Firewall) for the inside port.

5. If you route another network to the node (VPN)

If you reach the VMs over a VPN or another routed network, the MASQUERADE rule above will also rewrite the VMs’ replies to that network, and connections fail in confusing ways. Exempt it with a rule above the masquerade — for example, for a VPN on 10.8.0.0/24:

	post-up   iptables -t nat -I POSTROUTING -s '192.168.100.0/24' -d '10.8.0.0/24' -j RETURN
	post-down iptables -t nat -D POSTROUTING -s '192.168.100.0/24' -d '10.8.0.0/24' -j RETURN

What this can’t do

• VMs on vmbr1 don’t have public addresses of their own; everything inbound goes through a port forward.
• Protocols that need many or unpredictable ports (some VoIP, passive FTP) need extra forwards or a VPN.
• This covers IPv4. For IPv6, a routed prefix from your provider is the clean answer; NAT for IPv6 is possible but rarely what you want.