Bridge vs NAT in Proxmox VE: Which Networking Mode Should You Use?

Introduction

If you spent any time in VirtualBox or VMware Workstation before touching Proxmox, you probably remember picking a network mode from a dropdown: Bridged, NAT, Host-only, maybe Internal. Proxmox VE doesn't give you that dropdown. Open the network settings on a fresh install and you'll find one bridge, vmbr0, already wired up to your physical network card and handing out your host's own subnet to anything you plug into it.

That trips people up constantly. New users assume their VMs are somehow isolated by default, the way a NAT-mode VM in VirtualBox is, and get a surprise when a Windows VM shows up on the office DHCP server with its own IP address, visible to every other device on the LAN. Others go the opposite direction — they want their VM to just reach the internet through the host, without eating up an IP on the real network, and can't find a checkbox for that either.

Neither of these is a Proxmox limitation. Both bridged and NAT-style networking are fully supported, they just aren't presented as a dropdown. You configure them through the bridge itself, in a config file that's honestly not that scary once you've seen it once. This guide walks through what each mode actually does, why you'd pick one over the other, and how to set both up on a real Proxmox VE 9.x host.

What You Will Learn

• What a Linux bridge is and why vmbr0 is the default in every fresh Proxmox install
• The real difference between bridged networking and NAT, not just the marketing version
• When you'd actually want NAT on Proxmox, and when it just adds complexity you don't need
• How to set up a bridged VM so it gets a real IP on your LAN
• How to build a private NAT network with a masquerade rule, step by step
• The mistakes that cause a freshly NAT'd VM to have no internet access at all

What Is This Feature?

A bridge is a piece of software that acts like a switch. Proxmox creates one automatically during install, called vmbr0, and connects it to your first network card. Every VM or LXC container you attach to vmbr0 behaves as if it had its own cable plugged straight into your physical network. It gets its own MAC address, and if your router hands out DHCP leases, the VM requests one directly and shows up on your network like any other device — a laptop, a smart TV, whatever else is on that subnet.

NAT, short for Network Address Translation, is different. Instead of giving the VM its own presence on the physical LAN, you put it on a private subnet that only exists inside the Proxmox host — something like 10.10.10.0/24. The host then rewrites outgoing traffic so it looks like it's coming from the host's own IP, forwards it out to the real network, and un-rewrites the replies on the way back. The VM can reach the internet, but nothing on your physical LAN can initiate a connection to it directly, because as far as the LAN is concerned, that private IP doesn't exist anywhere.

The rewriting part is called masquerading, and on Linux it's handled by iptables, the same firewall tool that's been part of Linux networking for decades. You'll see it referred to as "NAT via masquerade" in the official Proxmox docs, which is a fair description of what's actually happening under the hood.

Why Would You Use It?

Bridged networking is the right default for most homelab and small-business setups, and that's exactly why Proxmox ships with it. If you're running a Plex server, a Home Assistant VM, or a small web app that other devices on your network need to reach, you want that VM to have its own real IP. Port forwarding, mDNS discovery, and anything that expects a normal LAN device just works.

NAT earns its place in narrower situations. Say you're running a stack of throwaway test VMs that only need outbound internet access — downloading packages, hitting an API, nothing more. Giving each one a real LAN IP means burning IPs out of your router's DHCP pool and possibly triggering your router's device-limit or guest-network rules. A NAT'd private subnet keeps all of that contained on the Proxmox host, invisible to the rest of the network, and you don't have to explain to anyone why there are twelve mystery devices on the Wi-Fi.

It also comes up when you don't control the upstream network at all — a Proxmox box sitting behind a single dynamic IP from an ISP, or a dedicated server where you only get one or two usable public addresses. NAT lets you run far more VMs than you have IPs for.

Honestly, if you're just starting out and building your first homelab, default to bridged. It's simpler to reason about, it's what nearly every tutorial assumes, and you can always carve out a NAT network later for the handful of VMs that actually benefit from it.

Bridge vs NAT at a Glance

Prerequisites

Before you start, you'll want:

• A working Proxmox VE install — this guide is written against 9.2, but the steps are the same back through the 8.x series
• Root or an SSH session to the Proxmox host, either through the Shell button in the web UI or an SSH client
• Basic comfort editing a text file on the command line (nano is fine, it's installed by default)
• At least one VM or container already created, so you have something to attach to the network you're configuring
• Ten minutes, and a note of your current IP settings before you touch anything — network changes are the one place where a typo can lock you out of the web UI

One safety tip worth repeating: if you're managing this Proxmox host over the same network connection you're about to reconfigure, keep a second way in — physical console access, IPMI, or a colleague standing next to the server. Bridge and IP changes on the wrong interface are the single most common way people accidentally cut themselves off from a remote server.

Step-by-Step Tutorial

Part 1: Confirming Your Existing Bridge Setup

Every fresh Proxmox install already has bridged networking configured for vmbr0. Open the file that controls it:

nano /etc/network/interfaces

You'll see something close to this, generated automatically by the installer:

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.2/24
        gateway 192.168.10.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

eno1 is your physical network card — yours might be named enp3s0 or eth0, depending on your hardware. It's set to manual, meaning it doesn't get an IP of its own; the bridge above it holds the address instead. bridge-ports eno1 is the line that actually plugs the physical card into the virtual switch. When you create a new VM in the Proxmox GUI and leave the network device on vmbr0 with the default model, it's bridged and ready to go — no further steps needed. It'll pick up a DHCP lease from your router just like a physical machine would.

Part 2: Setting Up a Private NAT Network

NAT needs a second bridge, one that isn't wired to a physical card at all, plus a couple of rules to handle the address rewriting. Open the same file again and add a new stanza below the existing vmbr0 block:

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 eno1 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE

Notice bridge-ports none — this bridge isn't connected to any physical hardware. It only exists inside the host, which is exactly what you want for a private subnet. The post-up lines run automatically whenever the bridge comes up: the first turns on IP forwarding for the whole host, the second tells the kernel to rewrite outgoing packets from the 10.10.10.0/24 range so they leave through eno1 disguised as coming from the host. The matching post-down line removes that rule cleanly if the bridge ever goes down, so you don't end up with a stale iptables rule hanging around.

Save the file, then apply it. If your host has the ifupdown2 package installed — the default on modern Proxmox VE — you can apply this without a reboot:

ifreload -a

If that command doesn't exist on your system, a reboot applies it just as well; there's no harm in going that route on a host that isn't in production yet.

Part 3: Attaching a VM to the NAT Network

In the Proxmox web UI, open your VM, go to Hardware, select the network device, and change the bridge from vmbr0 to vmbr1. Boot the VM and, inside the guest, either let it pick up a static address in the 10.10.10.0/24 range with 10.10.10.1 as its gateway, or set that manually if you haven't got a DHCP server running on vmbr1 (this basic setup doesn't include one — you're assigning addresses by hand). Test it with a simple outbound check from inside the guest:

ping -c 3 1.1.1.1

If that comes back with replies, masquerading is working and the VM has outbound internet access through the host, without ever touching your real LAN.

Commands Explained

• bridge-ports none — tells the bridge it isn't attached to a physical network card. Used for private, host-only bridges.
• echo 1 > /proc/sys/net/ipv4/ip_forward — turns on IP forwarding, the kernel setting that lets a Linux box route traffic between two networks instead of just consuming it locally. Without this, masquerade rules do nothing.
• iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE — adds a rule to the NAT table saying: for traffic leaving through eno1 that originated from the 10.10.10.0/24 subnet, rewrite the source address to look like it came from the host. This is the actual translation step.
• ifreload -a — reapplies the entire /etc/network/interfaces file live, without dropping your existing connections (as long as you haven't changed the interface you're connected through).
• ping -c 3 1.1.1.1 — sends three ICMP echo requests to Cloudflare's public DNS IP, a quick way to confirm outbound connectivity without depending on DNS resolution working yet.

Common Errors

A few things come up again and again with this setup:

• VM on vmbr0 gets no IP at all. Usually means the physical switch port it's plugged into (or the one your Proxmox host uses) doesn't allow the VLAN or has port security enabled. Check the switch config, not Proxmox, first.
• NAT'd VM has no internet access. Almost always one of two things: IP forwarding didn't actually get enabled (double-check with cat /proc/sys/net/ipv4/ip_forward — it should print 1), or the interface name in your masquerade rule (-o eno1) doesn't match your host's real interface name.
• RTNETLINK answers: File exists when applying interfaces. Usually means you tried to run ifreload after manually creating a bridge with ip link commands that never got cleaned up. A reboot clears it.
• Rule disappears after a reboot. This means the rule was added by hand with iptables directly, instead of through the post-up line in /etc/network/interfaces. Rules added outside the interfaces file don't persist.

Troubleshooting

Start from the host, not the guest. Run ip a on the Proxmox host and confirm both vmbr0 and vmbr1 show up with the addresses you expect. If vmbr1 is missing entirely, your /etc/network/interfaces syntax has a typo — indentation matters less than people expect, but a missing auto vmbr1 line will leave the bridge defined but never brought up.

Next, check the NAT rule actually made it into iptables:

iptables -t nat -L POSTROUTING -n -v

You should see a MASQUERADE line referencing your private subnet. If it's not there, the post-up line either has a syntax error or never ran — rerun ifreload -a and watch for errors in the output.

If the rule is present but the VM still can't reach the internet, check the guest's own network config. A common mistake is leaving the guest's gateway blank or pointing it at the wrong address — it needs to be the bridge's own IP (10.10.10.1 in the example above), not your router's real gateway.

Finally, remember that this basic NAT bridge has no built-in DHCP server. If you want VMs on vmbr1 to get addresses automatically instead of typing them in by hand every time, you'd need to run a small DHCP service (dnsmasq is the common choice) bound to that bridge — that's a separate task from what's covered here.

Best Practices

Keep your bridged and NAT networks on clearly different subnets — don't let vmbr0 and vmbr1 overlap in address range, or routing gets confusing fast. Name bridges by purpose in your own notes (even a text file works) once you have more than two or three, because vmbr0, vmbr1, vmbr2 tells you nothing six months later about which one does what.

If a NAT'd VM occasionally needs to be reachable from outside — a web server you want to test, for instance — add a specific port-forward rule with iptables rather than switching the whole VM to bridged mode. It keeps the VM's isolation intact for everything except the one port you've deliberately opened.

Don't bridge a VM directly onto your LAN if it's something you don't fully trust — a downloaded appliance, a VM you're testing from an unfamiliar source. A NAT network gives you a safety margin: even if that VM gets compromised, it can't freely scan or attack the rest of your physical network the way a bridged VM could.

Frequently Asked Questions

Can I use both vmbr0 and a NAT bridge on the same host?

Yes, and it's the normal setup. Most Proxmox hosts run bridged networking for VMs that need to be reached directly, and a NAT bridge for anything that only needs outbound access.

Does NAT slow down my VM's network traffic?

Not in any way you'd notice on a homelab. Masquerading is handled in the kernel and adds negligible overhead for typical traffic levels.

Why doesn't Proxmox just have a NAT dropdown like VirtualBox?

Proxmox is built around real Linux networking primitives rather than a simplified desktop-hypervisor abstraction. It's more setup up front, but it also means nothing is hidden from you — you can inspect and change every part of it.

Can I switch a VM from bridge to NAT later without losing data?

Yes. Changing the network device's bridge in the VM's hardware settings doesn't touch its disk. You may need to update the IP address inside the guest OS afterward, since it's now on a different subnet.

What happens to my NAT'd VMs if the Proxmox host reboots?

As long as the bridge and iptables rule are defined in /etc/network/interfaces with post-up, they come back automatically on boot. Rules added manually with the iptables command and nothing else do not survive a reboot.

Conclusion

There's no universally correct choice between bridge and NAT — it comes down to whether other devices on your network need to talk to the VM directly. Bridged networking is the Proxmox default for a reason: it's simpler, it matches how most tutorials and appliances expect a VM to behave, and it's the right call for anything acting like a real server on your LAN.

NAT earns its keep when you want isolation, when you're short on spare LAN addresses, or when you're spinning up VMs you don't want cluttering your router's device list. Once you've set up one vmbr1 with a masquerade rule, reusing the pattern for future private networks takes minutes, not the ten it took the first time through.