How to Create an Additional Network Bridge in Proxmox VE (Isolated Internal Network for VMs and Containers)

Every virtual machine you create in Proxmox VE lands on the same network bridge by default: vmbr0. That's fine right up until it isn't — maybe you're testing a firewall VM and don't want it anywhere near your real LAN, maybe you want a private backend network between a web VM and a database VM, or maybe you just want a sandbox where a misbehaving container can't reach anything else on your network. The fix takes about five minutes: add a second bridge.

This one trips people up more than it should, mostly because the Proxmox UI doesn't explain what an "isolated" bridge actually means until you've already created one and started poking at it. By the end of this guide you'll have a working vmbr1 with no physical NIC attached, and you'll understand exactly what it does and doesn't do.

What You Will Learn

• What a Linux bridge is in Proxmox VE, and why vmbr0 isn't your only option
• How to create a new bridge through the web GUI
• How to do the same thing from the command line by editing /etc/network/interfaces
• How to attach a VM or LXC container to your new bridge
• What actually happens (and doesn't happen) on an isolated network with no gateway
• Common mistakes and the exact error messages they produce

What Is This Feature?

A Linux bridge is a software switch. That's really the whole concept — think of it like a physical network switch, except it lives entirely in the Proxmox VE host's kernel instead of a box with blinking lights. vmbr0, the bridge Proxmox creates during installation, has one of your physical network cards plugged into it, so anything connected to vmbr0 (your VMs, the host itself) can reach your actual LAN.

Nothing says a bridge has to have a physical NIC attached, though. You can create vmbr1 with zero physical ports connected to it. Any VM or container you plug into vmbr1 can talk to other guests on vmbr1 — and nothing else. No route out to your LAN, no route to the internet, no way for anything outside that bridge to reach in. It's a closed room with an Ethernet switch in it.

Why Would You Use It?

The most common reason is testing a router or firewall VM — pfSense or OPNsense being the usual suspects. You give the firewall VM one NIC on vmbr0 (the real network, acting as WAN) and a second NIC on your new isolated bridge (acting as LAN). Then any VM you want "behind" that firewall gets plugged into the isolated bridge too. Nothing reaches those VMs except through the firewall, exactly like a real network.

Homelab folks also use this for multi-tier setups — a web server VM and a database VM that only need to talk to each other, with the web server bridged to both the isolated network and vmbr0, and the database only ever touching the isolated side. That way a compromised web app can't just walk straight to the database over your LAN.

There's a simpler use case too: you're experimenting with something you don't fully trust yet — a container downloaded from somewhere sketchy, a script you're not sure about — and you'd rather it not have any path to your other machines. An isolated bridge with no gateway handles that without touching your firewall rules.

I'll be honest, if you just want basic network segmentation and you're already comfortable with VLANs, a VLAN-aware bridge might serve you better long-term since it doesn't require a separate bridge device per network. But for a quick, dead-simple isolated segment, a second Linux bridge is hard to beat — there's nothing to misconfigure.

Prerequisites

You'll need a working Proxmox VE host — this guide was written against Proxmox VE 9.2, but the steps are identical back through the 8.x series since the networking stack hasn't changed in any way that matters here. You'll also need:

• Root access to the Proxmox VE web GUI, or SSH access to the host as root
• An existing VM or LXC container you can use to test the new bridge (optional, but it helps to confirm things work)
• No extra hardware. You do not need a spare network card — that's the entire point of an isolated bridge

Step-by-Step Tutorial

Method 1: Using the Web GUI

This is the method I'd recommend for almost everyone, since Proxmox validates your input as you go and you can't easily typo your way into a broken config.

1. Log in to the Proxmox VE web interface and click your node's name in the left-hand tree (not "Datacenter" — the actual host, e.g. pve).
2. Click System > Network.
3. Click the Create button near the top of the panel, then choose Linux Bridge.
4. In the dialog that opens, set the Name field. Proxmox will usually suggest the next free bridge number automatically — vmbr1 if vmbr0 is already taken.
5. Leave IPv4/CIDR and Gateway blank. This is the step people skip past without thinking about, and it's the one that actually makes the bridge isolated. If you fill in an IP here, you're giving the Proxmox host itself an address on that network, which is a different thing entirely (useful sometimes, but not what we're after).
6. Leave Bridge ports empty. This field is where you'd normally type a physical NIC name like eno2 if you wanted this bridge to reach the outside world. Leaving it blank is what makes the bridge fully internal.
7. Check Autostart so the bridge comes back up after a reboot.
8. Click Create.

You'll now see vmbr1 listed in the Network panel with a status of "Pending changes" — nothing has actually been applied to the running system yet. Click the Apply Configuration button in the top right of the panel. On modern Proxmox VE (which uses ifupdown2), this reloads networking in place. You won't lose your SSH session or drop running VMs on vmbr0.

Method 2: Editing /etc/network/interfaces Directly

If you're more comfortable on the command line, or you're scripting this as part of a larger setup, SSH into the host and open the file with your editor of choice:

nano /etc/network/interfaces

Add a block like this at the end of the file:

auto vmbr1
iface vmbr1 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0

bridge-ports none is the CLI equivalent of leaving the Bridge ports field empty in the GUI — no physical NIC attached. Save the file, then apply it without rebooting:

ifreload -a

Run ip a show vmbr1 afterward and you should see the interface listed as UP with no IPv4 address, which is exactly what you want.

Attaching a VM or Container to the New Bridge

For a VM: select it in the left tree, go to Hardware, click your network device (usually net0), click Edit, and change the Bridge dropdown from vmbr0 to vmbr1. If the VM is running, you'll need to either reboot the guest OS or, on Linux guests, bring the interface down and up again — Proxmox can hot-plug the change into the VM, but the guest OS often needs a nudge to notice.

For an LXC container, it's almost identical: select the container, go to Network, click the interface, edit it, and change the Bridge field the same way. Containers pick up bridge changes faster than VMs since the network device isn't emulated hardware.

Commands Explained

Common Errors

Troubleshooting

If Apply Configuration seems to hang or the web GUI briefly disconnects, that's usually normal — ifupdown2 restarts networking services during the apply, and the GUI's WebSocket connection drops for a second or two before reconnecting on its own. Give it about 15 seconds before assuming something broke.

If a VM you attached to vmbr1 doesn't get an interface at all inside the guest OS, check the VM's hardware tab first. It's easy to add a brand new network device (net1) instead of editing the existing one, which leaves the VM with two NICs when you only meant to change one. Delete the extra device if that happened.

Two VMs on vmbr1 that can't ping each other almost always comes down to the guest OS firewall, not Proxmox. Ubuntu and Debian guests are usually fine out of the box; Windows guests will block ICMP by default under most firewall profiles, so a failed ping doesn't necessarily mean the bridge is broken. Try a TCP-based test instead, like standing up a quick nc -l listener, before assuming the network layer is at fault.

If changes don't survive a reboot, double check that Autostart was ticked in the GUI, or that your interfaces file block starts with auto vmbr1 and not just iface vmbr1 inet manual on its own — without the auto line, the interface exists in config but won't come up automatically at boot.

Best Practices

Keep your bridge numbering predictable. vmbr0 for your main LAN, vmbr1 for your first isolated segment, and so on — it sounds obvious, but six months from now when you're staring at a list of five bridges, you'll be glad you didn't get creative with names.

Document what each bridge is for somewhere outside your own memory — a comment above the block in /etc/network/interfaces works fine, and so does a note in whatever wiki or text file you keep your homelab notes in. "vmbr1 = pfSense LAN, no internet" takes ten seconds to write and saves you real confusion later.

If you find yourself creating a fourth or fifth isolated bridge for what's really just different VLANs on the same physical network, stop and look at a VLAN-aware bridge instead. Multiple flat bridges work, but they don't scale as cleanly as VLAN tagging once you're past two or three segments.

And don't assume isolation from Proxmox networking means isolation from everything. If a VM on vmbr1 also has a second NIC on vmbr0, it can act as a bridge between the two networks whether you meant it to or not — routing between interfaces is a guest OS setting (IP forwarding), not something Proxmox blocks for you.

Frequently Asked Questions

Does creating a new bridge affect my existing VMs on vmbr0?

No. vmbr0 and any VMs attached to it keep working exactly as before. Applying the new config only adds vmbr1 — it doesn't touch existing interfaces.

Do I need to reboot the Proxmox host?

No, not with ifupdown2. Apply Configuration in the GUI or ifreload -a on the CLI applies the change live.

Can I give the isolated bridge internet access later?

Yes, in a couple of ways. The simplest is running a router VM (like OPNsense) with one leg on vmbr0 and one on vmbr1, and letting it handle NAT. If you want Proxmox to do NAT and DHCP for you automatically instead of running a router VM, look at Proxmox VE's SDN Simple Zone feature — it's built for exactly this and saves you from hand-configuring iptables rules.

What's the difference between this and a VLAN-aware bridge?

A second Linux bridge is a completely separate virtual switch — nothing about vmbr1 knows vmbr0 exists. A VLAN-aware bridge is one bridge that carries multiple tagged networks over the same virtual switch, which uses fewer bridge devices but requires every guest to be configured with the correct VLAN tag. For one or two isolated networks, a second bridge is simpler. For many, VLANs usually win.

Does the isolated bridge need an IP subnet assigned at all?

Not from the host's side, no. Guests on vmbr1 can still use static IPs or run their own DHCP server and talk to each other fine — the Proxmox host itself just won't have an address on that network unless you explicitly give it one.

Will LXC containers work the same way as VMs here?

Yes. Containers use the same bridge concept, and the same "leave the IP fields blank on the bridge itself" logic applies. Containers tend to pick up the new network immediately since their networking isn't emulated hardware the way a VM's is.

Conclusion

A second bridge with nothing plugged into it looks unremarkable in the GUI, but it's one of those small Proxmox features that quietly solves a lot of problems — router VM testing, backend-only database networks, or just keeping something you don't fully trust away from the rest of your setup. The whole process comes down to one rule worth remembering: leave the IP and Bridge ports fields empty, and Proxmox does the rest. Once you've built vmbr1 the first time, adding vmbr2 or vmbr3 later takes about thirty seconds.