Proxmox VE Networking Explained: Bridges, Bonds and VLANs

Answer first: the one mental model

Proxmox VE networking is Linux networking, arranged around one idea: virtual machines and containers plug their virtual NICs into software switches called Linux bridges. The default bridge, vmbr0, is created at install time with your physical NIC attached — that's the whole reason your first VM could reach the internet.

Every real-world setup is a variation on where those bridges connect:

• Bridged: the VM sits directly on the physical network with its own public IP and MAC — simplest, but on a hosting provider it requires provider-sanctioned additional IPs/MACs.
• Routed: the host owns the public addresses and routes traffic to VMs — works everywhere, no MAC constraints, slightly more config.
• NAT / private: VMs live on a private bridge and share the host's IP outbound — right for VMs that don't need to be publicly reachable.

Configuration lives in one readable file, /etc/network/interfaces, and because Proxmox uses ifupdown2, changes apply live with ifreload -a (or the GUI's "Apply Configuration") — no reboots. This article assumes a working installation; if you're not there yet, start with our Proxmox VE setup guide, which introduces vmbr0 briefly — this is the promised deep dive. Addresses below are documentation ranges (203.0.113.0/24, 10.0.0.0/24); substitute your own.

Anatomy of vmbr0

A fresh install's /etc/network/interfaces reduces to this:

auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

Read it bottom-up and the model clicks: the physical NIC (enp1s0) carries no IP itself — it's purely a bridge port. The bridge owns the host's IP address and the uplink. VMs attach their virtual NICs (tap devices) to the same bridge, making it an unmanaged switch with the physical NIC as its uplink port. Everything else in this article is adding more bridges, tagging traffic on them, or changing what feeds them.

The three patterns on a hosted server

On your own switch at home, bridged networking just works. On a dedicated server at a provider, there's a constraint to respect: datacentre access switches typically enforce MAC filtering — traffic from MAC addresses the provider doesn't expect on your port gets dropped. That single fact decides which pattern fits:

Bridged: VMs with their own public IPs

Each VM gets a public IP and its virtual MAC appears on the provider's switch. This requires additional IPs assigned to your server by the provider, with the VM's MAC registered where the provider requires it (some allocate a MAC per IP; some accept any MAC on your port for routed subnets). When supported — as on our network, where additional IP space comes with the server — this is the cleanest setup: the VM config is just "attach to vmbr0, set the assigned IP and the same gateway as the host".

Routed: works under any MAC policy

Only the host's MAC ever appears on the wire; the host routes for its VMs. Sketch — public subnet 203.0.113.64/26 routed to your server:

auto vmbr1
iface vmbr1 inet static
    address 203.0.113.65/26
    bridge-ports none
    bridge-stp off
    bridge-fd 0

bridge-ports none is the trick worth internalising: a bridge with no physical port is a purely internal switch. VMs on vmbr1 use 203.0.113.65 as their gateway; the host forwards between vmbr1 and the uplink (enable net.ipv4.ip_forward in /etc/sysctl.d/). The provider's switch only ever sees the host.

NAT: private VMs that can reach out

Same port-less bridge with a private range (10.0.0.1/24 on the bridge), plus a masquerade rule so VMs share the host's public IP for outbound traffic. Right for build VMs, databases serving only other VMs, and lab guests. Inbound access, where needed, is port-forwarding (DNAT) on the host — at which point, if you're forwarding much, reconsider whether the VM just wants a routed public IP.

Mix freely: a typical host runs vmbr0 (public, bridged), and a private bridge for backend traffic between guests.

VLANs: one bridge, many networks

The modern pattern is the VLAN-aware bridge — one flag on vmbr0:

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Now the bridge passes tagged traffic, and you set the VLAN Tag per virtual NIC in the VM's hardware options — the bridge handles tagging/untagging, guests stay unaware. Compared to the older one-bridge-per-VLAN style (vmbr0v40 and friends), this is one bridge instead of a dozen and no host config change when you introduce a new VLAN — assign a new tag and go. Guests that need trunks (a firewall VM, say) can receive tagged traffic directly too.

Where VLANs meet a hosting provider: they only segment traffic where the infrastructure carries the tags — within your host, always; between your servers, when the provider's private networking preserves them (ours does — VLANs over the private LAN are how customers build multi-host segmented networks; it's also the mechanism behind customer DMZs).

Bonding: two NICs, one logical uplink

Bonds aggregate physical NICs for redundancy (and sometimes bandwidth). The bond becomes the bridge's port:

auto bond0
iface bond0 inet manual
    bond-slaves enp1s0 enp2s0
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports bond0
    ...

Mode choice is simpler than the seven options suggest, and the official guidance is direct: use 802.3ad (LACP) if your switch supports it — otherwise use active-backup. LACP needs matching configuration on the provider's switch (on a dedicated server, that means it's something to arrange with your host, not just enable locally); active-backup works with any switch and buys pure failover. Note that a single TCP flow never exceeds one physical link's speed under LACP — bonding multiplies aggregate, not per-flow, bandwidth. And if you later cluster: corosync dislikes some bond modes; give cluster traffic its own unbonded NIC or active-backup.

Where the SDN layer fits

Everything above configures one host. Proxmox's SDN feature (fully supported core since 8.1, configured under Datacenter → SDN) applies network definitions cluster-wide: define a zone and its VNets once, and every node offers them consistently. Zone types map to ambition:

• Simple — isolated per-node bridges with optional cluster-managed IPAM/DHCP; the managed version of bridge-ports none.
• VLAN — the VLAN setup above, defined once for the whole cluster.
• QinQ — stacked VLAN tags, for when you're handing VLANs to tenants.
• VXLAN — layer-2 networks tunnelled over any layer-3 connectivity between nodes; the standard answer to "one private network spanning servers that don't share a switch". Mind the MTU: VXLAN costs 50 bytes of overhead, so either raise the underlay MTU or lower the VNet's.
• EVPN — VXLAN plus BGP-based control plane and distributed routing; datacentre-fabric territory.

Rule of thumb: single host or a handful of static bridges → plain /etc/network/interfaces, this article. Cluster with more than a couple of shared networks, or any tenancy → define them once in SDN. (PVE 9 added "fabrics" — auto-configured routed underlays — a sign of where this layer is headed.)

Not cutting yourself off

Every Proxmox networking horror story is the same story: a bridge change applied to the interface carrying the SSH session. The disciplines:

• Apply live, atomically. Edit /etc/network/interfaces, then ifreload -a (ifupdown2 applies the delta live). The GUI's pending-changes + "Apply Configuration" flow does the same with a review step.
• Have the console before you need it. IPMI/KVM-over-IP access (included with our servers) turns "I bridged away my uplink" from an outage into a two-minute fix at the console. Verify your access before editing.
• Change one layer at a time. Bond first, verify; then bridge onto the bond; then VLANs. Compound changes produce compound failure modes.
• Don't firewall the host by accident. Proxmox has its own firewall (datacentre → node → VM levels). When you enable it, confirm the management rules (SSH, 8006) before applying at node level — the same lockout logic as our firewall baseline guide, one layer up.

Frequently asked questions

Should I use Linux bridges or Open vSwitch?

Linux bridges, unless you arrive with a specific OVS requirement. They're Proxmox's default and best-documented path, the VLAN-aware flag covers the segmentation cases OVS used to be fetched for, and the entire SDN layer is built on Linux bridges with ifupdown2. OVS remains supported for those who need its extras, but for a typical dedicated-server deployment it adds surface without adding capability you'll use.

How do I give a VM its own public IP?

Two ways. Bridged: attach the VM to vmbr0 and configure an additional IP your provider has assigned to your server (respecting their MAC policy — on our network, additional IPs come with the server and this is the standard setup). Routed: keep the provider-facing MAC the host's own, put VMs behind an internal bridge, and route the subnet to them — works under any switch policy at the cost of the host doing the forwarding.

Why did my VM's network die when I enabled VLAN tagging?

Almost always one of three: the bridge isn't VLAN-aware (bridge-vlan-aware yes missing), the physical path doesn't carry the tag (the provider's switch or private LAN must pass that VLAN), or an MTU mismatch when tunnelling (VXLAN's 50-byte overhead). Debug in that order — bridge flags, then end-to-end tag transport with tcpdump -e vlan, then MTU with a do-not-fragment ping sized to the limit.

Does any of this require a cluster?

No — everything down to the SDN section is single-host. SDN itself also works on one node (Simple zones with managed DHCP are genuinely useful solo), but its value compounds with node count. If clustering is on your roadmap, the networking decision worth making early is reserving a NIC (or at least a VLAN) for cluster traffic — corosync wants low latency and hates competing with VM bulk traffic; details in our cluster and HA guide.

Deploying on Serverside

The patterns in this guide map directly onto what a Proxmox dedicated server from us gives you: additional public IP space for bridged VMs, private networking between your servers that carries your VLANs (the multi-host segmentation and DMZ patterns above), KVM-over-IP for fearless network edits, and always-on DDoS mitigation upstream of everything — provisioned with Proxmox VE pre-installed in under a minute on ASN 55285.

Continue the series with how to set up your first VMs and containers, LXC vs KVM: when to use which, and backup strategies with vzdump and PBS.