Proxmox VE Networking on a Dedicated Server With One Public IP (Routed & NAT Setup)

You just paid for a dedicated server, installed Proxmox VE on it, and now you're staring at a virtual machine that boots fine but has zero internet access. Or maybe the VM does get online, but you can't reach it from outside at all. If that's where you are right now, you haven't done anything wrong. This is arguably the single most common wall that people hit right after installing Proxmox on a rented server from a host like Hetzner, OVH, or a similar provider.

The reason is simple once you see it: a home router hands out IP addresses to anything plugged into it. A dedicated server's upstream switch does not work that way. It usually only allows traffic for the one public IP address (and one MAC address) it already knows about. Your VMs are, as far as that switch is concerned, strangers. This article walks through exactly why that happens and the two practical ways to fix it.

What You Will Learn

Why the default Proxmox bridge (vmbr0) often doesn't work on rented servers the way it does at home
The difference between a "routed" network setup and a NAT setup, and which one fits your situation
How to configure /etc/network/interfaces for a routed setup using extra IPs from your provider
How to set up NAT with port forwarding when you only have one IP and no budget for more
The exact commands involved, what each one does, and the mistakes that cause the most support tickets

What Is This Feature?

On a normal home network, your router does NAT (Network Address Translation) for you automatically. Every device on your LAN shares the router's one public IP, and the router quietly keeps track of which internal device is talking to which external server. You never have to think about it.

Dedicated server providers don't run their network that way. Their switches are configured so that only one specific IP and MAC address pair is allowed to send traffic out of your server's port. This is a security and anti-spoofing measure — it stops one customer's server from pretending to be someone else's on the shared network. The side effect is that if you create a Proxmox bridge and just plug VMs into it expecting them to get their own IPs from the physical network, packets from those VMs get silently dropped upstream.

Proxmox VE's documentation calls the fix for this a routed configuration. Instead of letting VMs talk to the physical network directly through a bridge, the Proxmox host itself becomes a tiny router. Traffic for each VM's IP gets explicitly routed through the host, which already has permission to use that port. There's also a second option — a NAT / masquerading configuration — where your VMs live on a private, made-up IP range and the host translates their traffic the same way a home router would.

Why Would You Use It?

You need one of these two setups any time your provider's network won't let a bridged VM talk to the internet directly, which in practice means almost every budget or mid-range dedicated server. Whether you pick routed or NAT usually comes down to money and how many VMs need to be reachable from the outside world.

If you've bought or can buy extra IP addresses from your host (Hetzner, for example, sells single additional IPv4 addresses for a few euros a month), the routed setup is worth doing. Each VM gets a real public IP, and you can run whatever services you want on any port without juggling forwarding rules.

If you're on a tight budget and only have the one IP that came with the server, NAT is the practical choice. Your VMs get private IPs behind the host, and you forward specific ports — say, 8006 for one VM's web app and 2222 for its SSH — to reach them from outside. It's a bit more fiddly day to day, but it costs nothing extra.

Prerequisites

Before you touch any network config, make sure you have the following. Get these wrong and you can lock yourself out of a server that might not have a physical keyboard within a thousand miles of you.

Proxmox VE already installed and reachable at https://your-server-ip:8006
Out-of-band access to the server — a KVM-over-IP console, iLO, iDRAC, or your provider's "rescue console" feature. Hetzner calls theirs the KVM console; OVH calls theirs the KVM/IPMI. You will want this open in a separate tab before you start.
Your server's main public IP, subnet mask, and gateway, exactly as your provider lists them in your control panel
If you're doing the routed setup: at least one additional IP address purchased from your provider, along with its subnet mask (providers usually hand these out as single /32 addresses, not a routable block)
Root SSH access to the Proxmox host
A recent backup or snapshot of the host's network config isn't strictly required for a fresh install, but if this is a server you've already customized, copy /etc/network/interfaces somewhere safe first

One honest warning: test any network change through the KVM console first, not over your normal SSH session. If a typo takes down networking, an SSH session over that same network dies with it, and you'll be stuck waiting for the change to fail back on its own — which it won't, unless you've set up ifupdown2 with a rollback timer, which is beyond what most people configure for a single dedicated box.

Step-by-Step Tutorial

Both methods below edit the same file: /etc/network/interfaces. Open it through the KVM console with nano /etc/network/interfaces, or edit it in the Proxmox web UI under Node → System → Network if you'd rather avoid the command line for the bridge parts.

Method A: Routed Setup With an Additional IP

This method assumes your main IP is 203.0.113.10 with gateway 203.0.113.1, and you've bought one extra IP, 203.0.113.20, to hand to a VM. Swap in your own addresses — these are documentation-only example ranges and won't work as-is.

First, back up the existing config:

cp /etc/network/interfaces /etc/network/interfaces.bak

Then set the file up so the physical interface holds your main IP, and the bridge sits on top of it without attaching to any physical port:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 203.0.113.10/32
    gateway 203.0.113.1
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/32
    bridge-ports none
    bridge-stp off
    bridge-fd 0

Notice the /32 on both addresses. That's not a typo — it tells Linux "this is a single host, not a subnet," which is exactly what your provider's routing expects. bridge-ports none means the bridge isn't attached to any physical NIC; it only talks to VMs and to the host itself.

Now assign the extra IP to a VM. Inside the VM's own guest operating system network config (not the Proxmox host), set:

IP address: 203.0.113.20/32
Gateway: 203.0.113.10 (your Proxmox host's IP, not the provider's real gateway)

Back on the Proxmox host, tell it how to reach that IP by adding a route. Append this to /etc/network/interfaces, inside the vmbr0 block:

    up ip route add 203.0.113.20/32 dev vmbr0

Apply the changes with systemctl restart networking, or reboot if you'd rather be safe. Then check the VM has internet with a simple ping 1.1.1.1 from inside the guest.

Method B: NAT Setup With Port Forwarding

If you don't have a spare IP, give your VMs a private range instead and let the host masquerade their traffic. Add a second bridge for this — leave vmbr0, which holds your real public IP, untouched:

auto vmbr1
iface vmbr1 inet static
    address 10.10.10.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 '10.10.10.0/24' -o eth0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eth0 -j MASQUERADE

Attach your VM's network device to vmbr1 instead of vmbr0 in the VM's hardware settings. Inside the guest, give it a static address like 10.10.10.50/24 with gateway 10.10.10.1 — or just let it pull one via DHCP if you've set up dnsmasq, though a static address is simpler to reason about on a single-VM homelab box.

To reach a service running on that VM from the outside, forward the port on the host. For SSH on the VM, for instance:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2222 -j DNAT --to 10.10.10.50:22

Make that rule persistent by adding it as a post-up line in the vmbr1 block, the same way the MASQUERADE rule is set up above. Otherwise it disappears on the next reboot.

Commands Explained

Command / Setting	What It Does
`echo 1 > /proc/sys/net/ipv4/ip_forward`	Turns on IP forwarding so the Linux kernel will pass traffic between interfaces instead of dropping anything not addressed to itself. Without this, your host won't route VM traffic at all.
`proxy_arp`	Makes the host answer ARP requests on behalf of IPs it's routing for, so the upstream switch believes those extra IPs live on this port. This is what lets the routed method work without your provider doing anything special on their end.
`bridge-ports none`	Tells the bridge not to bind to any physical network card. It exists purely to connect VMs to the host's routing table.
`ip route add ... dev vmbr0`	Adds a specific, single-host route so the kernel knows to send packets for that one extra IP out through the bridge, toward the VM that owns it.
`iptables -t nat -A POSTROUTING ... -j MASQUERADE`	Rewrites the source address on outgoing packets from your private VM range to look like they came from the host's public IP. This is what gives NAT'd VMs internet access.
`iptables -t nat -A PREROUTING ... -j DNAT`	Rewrites the destination on incoming packets so traffic hitting a specific port on the host gets redirected to a VM's private IP and port instead.
`systemctl restart networking`	Reloads the network configuration from `/etc/network/interfaces` without a full reboot. On a remote server, know this can briefly interrupt your SSH session.

Common Errors

A few things go wrong often enough that they're worth calling out by name.

VM has an IP but no route to the internet. This is almost always a missing ip_forward setting, or a route that didn't get added because of a typo in the IP address. Check with cat /proc/sys/net/ipv4/ip_forward — it should print 1, not 0.

"Network is unreachable" when pinging out from the VM. Nine times out of ten, the VM's gateway is set to the provider's real gateway instead of the Proxmox host's IP. In a routed setup, the VM's gateway must always point at the host, never at the outside world directly.

Losing SSH access mid-change. If you restart networking and the session hangs, don't panic and don't start mashing keys. Give it 30 seconds, then check the KVM console — the actual error is almost always sitting right there in the boot or syslog output.

Extra IP "doesn't work" even though it's configured correctly on the VM side. Double check the route was actually added on the host with ip route show. It's easy to save the interfaces file but forget to reload it, so the change never took effect.

Troubleshooting

Work through these in order — they cover the large majority of cases.

From the Proxmox host itself, run ip addr show vmbr0 and confirm the bridge has the address you expect.
Run ip route show and confirm you see a route for each extra IP you've assigned to a VM.
Check cat /proc/sys/net/ipv4/ip_forward returns 1.
For NAT setups, run iptables -t nat -L -n -v and confirm the MASQUERADE and DNAT rules are present. If they're missing after a reboot, they weren't saved as post-up lines and only existed in memory.
From inside the VM, try ping 1.1.1.1 (tests raw connectivity) and then ping google.com (tests whether DNS is also working — a separate problem from routing).
If nothing works, temporarily attach the VM back to the original working bridge to confirm the VM's own OS network config isn't the actual problem.

Best Practices

Keep a copy of a known-good /etc/network/interfaces before you change anything — one cp command costs you five seconds and saves you an hour of guesswork later.

Always test through the KVM/rescue console the first time you apply a network change, even if you're confident in the syntax. I've seen a single missing slash in a subnet mask take down a server for twenty minutes while someone frantically opened a support ticket.

Don't mix routed and NAT VMs on the same bridge. Keep vmbr0 for anything with a real public IP and a separate bridge like vmbr1 purely for NAT'd guests. It makes the firewall rules and your own mental model much easier to follow six months from now.

If you're going to run more than two or three NAT'd services, look at Proxmox VE's built-in firewall (under Datacenter → Firewall) instead of hand-managing a growing pile of iptables rules. It's not required for a small homelab, but it saves real headaches once the rule count climbs.

Frequently Asked Questions

Do I need to buy extra IPs to run more than one VM?
No. NAT lets you run as many VMs as your hardware can handle on a single public IP — you just forward different ports to each one, or run a reverse proxy in front of them.

Why doesn't the default Proxmox bridge just work like it does on my home lab PC?
Home routers accept traffic from any device on the LAN. Data center switches are locked to a specific IP and MAC pair for security, so a plain bridge can't get traffic past that port.

Can I combine both methods on the same host?
Yes. It's common to put one or two important VMs on real IPs via the routed method and everything else behind NAT on a second bridge.

Will this setup survive a Proxmox host reboot?
Yes, as long as everything is written into /etc/network/interfaces as shown above, rather than run as one-off commands in a terminal. One-off commands vanish on reboot; config file entries don't.

My provider mentions a "MAC-based" or "vSwitch" networking option instead. Should I use that?
Some providers, Hetzner included, offer add-on products (vSwitch, for example) that let you skip the routed setup entirely and bridge normally within a private network. If your provider offers something like that and it fits your budget, it's genuinely simpler than what's covered here — check their documentation for the specifics, since the exact feature name and setup steps vary by provider.

Conclusion

The jump from "Proxmox works fine on my home PC" to "Proxmox on a rented server won't give my VMs internet" trips up almost everyone the first time, and it has nothing to do with anything you misconfigured in Proxmox itself. It's just a different kind of network sitting underneath it.

Pick routed if you've got (or are willing to buy) extra IPs and want each VM directly reachable. Pick NAT if you're working with a single IP and don't mind forwarding a handful of ports. Either way, the two building blocks are the same: make sure the host is willing to forward traffic, and make sure it knows exactly where to send it. Once those two pieces are in place, everything else on top — LXC containers, more VMs, reverse proxies — behaves exactly like it would on any other Proxmox box.

Vormox is an independent virtualization management platform built on Proxmox VE. Proxmox® and Proxmox VE® are trademarks of Proxmox Server Solutions GmbH. Vormox is not affiliated with, endorsed by, or sponsored by Proxmox.

How to Set Up Proxmox VE Networking on a Dedicated Server With Only One Public IP (Routed vs NAT Explained)