Proxmox sets up a single bridge during install, vmbr0, hands every VM and container a virtual NIC on it, and most homelabs never touch networking again after that. That’s fine right up until you want to keep your NAS traffic off the same broadcast domain as a VM you don’t fully trust, or you add a second NIC and aren’t sure whether to bond it or split it out, or you’re staring at a VLAN dropdown in the VM hardware tab with no idea what happens if you fill it in wrong. None of this is complicated once you see the shape of it, but Proxmox’s networking config is also one of the few places where a bad change locks you out of the box that’s hosting the config, so it’s worth understanding before you’re mid-edit over SSH.

The default: one bridge, no isolation

vmbr0 is a Linux bridge, a software switch. Your physical NIC is a port on that switch, and every VM/container NIC you create on vmbr0 is another port on the same switch. Everything on it is on the same flat network, no different than plugging everything into the same physical unmanaged switch. For a single-purpose homelab where every VM is something you trust and there’s no reason to separate traffic, this is genuinely fine and you don’t need to add anything on top of it.

The moment that stops being true is the moment isolation actually matters: an internet-facing service you want fenced off from your management traffic, an IoT VLAN you don’t want your Proxmox host or backup traffic touching, or just wanting your NAS’s storage network on its own segment so it isn’t competing with everything else’s broadcast traffic. That’s where VLANs come in.

VLAN-aware bridge vs one bridge per VLAN

Proxmox gives you two ways to run multiple VLANs through one bridge, and it’s worth knowing both exist because they solve the same problem differently.

VLAN-aware bridge. Check the “VLAN aware” box on vmbr0 in the Proxmox network config, and the bridge itself becomes able to carry tagged traffic for multiple VLANs simultaneously, the same way a trunk port on a real managed switch does. Each VM or container’s virtual NIC then gets a VLAN tag set directly in its own network device config, not in the bridge. This is the simpler setup to maintain long-term: one bridge, tag guests individually, add or change a guest’s VLAN without touching host-level networking at all.

One bridge per VLAN. Alternatively, create a separate vmbrX for each VLAN, each one a VLAN sub-interface of your physical NIC (eno1.50, eno1.253, however your interfaces are named), bridged individually. Guests attach to whichever bridge matches the VLAN they belong to, with no tag set on the guest NIC itself, since the bridge already only carries that one VLAN’s traffic. This is more explicit and arguably easier to reason about at a glance in the UI (you can see “this VM is on the Infra bridge” instead of having to check its tag), but it means editing host-level network config every time you add a VLAN, and it’s a bit more clutter in the interface list as VLANs multiply.

Neither is wrong. VLAN-aware bridges scale better if you expect to add VLANs over time and don’t want to keep touching host networking. Per-VLAN bridges read more clearly at a glance and avoid ever having to think about tagging at the guest level. Pick one pattern and stay consistent, mixing both approaches on the same host is where things get genuinely confusing to audit later.

The switch has to agree with you

Whichever approach you pick, none of it works unless the physical switch port your Proxmox host’s NIC plugs into is configured to match. If you’re running a VLAN-aware bridge or multiple VLAN sub-interfaces off one physical NIC, that switch port needs to be a trunk port carrying all the VLAN tags you’re using, not an access port stuck on a single VLAN. This is the single most common reason “I set up VLANs in Proxmox and now nothing works” happens, the Proxmox side was configured correctly and the switch side wasn’t touched at all. Check your switch’s port config first, before spending time debugging the Proxmox side of a problem that’s actually sitting one hop upstream.

Bonding: redundancy and throughput, not free performance

If your host has more than one physical NIC, bonding lets you combine them into a single logical interface (bond0) that the bridge sits on top of instead of a single physical NIC. Two things people expect from this that aren’t automatically true:

  • A bond doesn’t automatically double your throughput for a single connection. Most bonding modes (802.3ad/LACP included) balance traffic across links per-flow, based on a hash of source/destination addresses and ports. A single VM copying a single large file to one destination will typically still ride one physical link, not both at once. You see the aggregate benefit across many simultaneous connections, not a single transfer.
  • LACP needs switch-side support. 802.3ad (LACP) is the mode most homelabbers actually want, since it does real load distribution and failover, but it requires your switch to be configured with a matching LACP port group on the exact ports the bonded NIC ports are plugged into. Plug a bonded pair of NICs into two unrelated switch ports with no LACP config on the switch side and you’ll get broken or flaky networking, not a working bond that silently falls back to something safer.

If your switch doesn’t support LACP (a lot of cheap unmanaged switches don’t), active-backup mode is the fallback: no throughput benefit, but real failover, one link is active and the other only takes over if the first drops, and it needs no special switch config at all since only one link is ever actually talking. For most homelabs, redundancy against a single bad cable or NIC is the actual win from bonding, treat any throughput gain as a bonus that shows up under multi-flow load, not as the reason to do it.

The Proxmox firewall layer

Separately from VLANs, Proxmox has its own built-in firewall, configurable at the datacenter, node, and individual VM/container level, sitting on top of whatever network segmentation you’ve built. It’s worth knowing this exists even if you don’t use it heavily, because it’s genuinely useful for a narrower job than VLANs solve: VLANs control what a device can physically reach on the wire, the Proxmox firewall controls what’s allowed to talk to a specific VM’s ports regardless of what VLAN it’s on. Using both together, VLANs for broad segmentation and per-VM firewall rules for anything that needs tighter control than “same VLAN, so it’s reachable,” covers more real scenarios than either one alone. It’s disabled by default at every level, so turning it on for a VM you actually want locked down is a deliberate opt-in, not something that silently starts filtering traffic you didn’t expect.

Don’t lock yourself out

The one real hazard in all of this: editing the network config of the interface you’re currently connected through. Change vmbr0’s settings, or worse, remove your only route to the host, over an SSH session or the web UI running through that same bridge, and you can cut your own access mid-change with no warning before it happens.

A few habits that actually prevent this:

  • Apply network changes through the Proxmox web UI’s “Apply Configuration” flow when possible, not by hand-editing /etc/network/interfaces and restarting networking blind. The UI writes a pending config and only applies it on your explicit confirmation, giving you a chance to catch an obvious mistake before it takes effect.
  • If you’re editing by hand, keep a second, independent way into the host open during the change, an iDRAC/IPMI console, a physical keyboard and monitor, or at minimum a second SSH session you don’t close until you’ve confirmed the new config works, so you have a way back in if the change breaks connectivity.
  • Never change the network config of the only interface a remote session is using, in that same session, without a fallback. If you only have one path in and you’re changing that exact path’s config, you’re one typo away from a trip to the physical hardware to fix it.

Bottom line

The default single-bridge setup is genuinely fine for a homelab where every guest is trusted and isolation doesn’t matter yet. Once it does, a VLAN-aware vmbr0 with tags set per guest is the lower-maintenance path for most people, per-VLAN bridges are the more explicit alternative if you’d rather see segmentation in the interface list than in each guest’s config. Either way, get the physical switch port configured to match before troubleshooting the Proxmox side, treat bonding as a redundancy feature first and a throughput feature second unless your switch does real LACP, and never touch the network config of the exact interface you’re connected through without a fallback path into the host already open.