VLANs let one physical network carry several isolated networks, each tagged with its own ID. On a Proxmox host that usually means keeping management traffic, VM workloads, storage, and a guest or DMZ network apart while they all share the same NIC and cable.
Proxmox handles this through 802.1Q tagging on a Linux bridge. Once the bridge is VLAN-aware, you assign a VLAN ID per VM the same way you’d configure an access port on a managed switch. The guest never has to know it’s tagged.
This guide covers the two ways Proxmox does VLANs, how to make vmbr0 VLAN-aware, how to tag VMs and containers, how to put the host’s own management IP on a tagged VLAN, and the mistakes that leave a tagged VM with no network. Examples target Proxmox VE 8.x, which uses ifupdown2 so changes apply without a reboot.
Two ways to do VLANs in Proxmox
Proxmox supports two approaches, and it helps to know which one you’re using before you start editing config.
The VLAN-aware bridge is the modern, simpler method. You enable one flag on the bridge, then set a VLAN tag per VM. A single bridge carries every VLAN, and Proxmox tags frames as they leave for each VM — exactly like an access port on a switch. This is what most setups should use.
The traditional method creates a separate interface per VLAN using vlanX.Y naming (a vlan-raw device), often paired with its own bridge. You’d reach for this with certain bonding configurations or when you need a bridge dedicated to a single VLAN. It works fine, but it’s more interfaces to manage.
What needs to be true upstream
Before touching Proxmox, make sure the network around it is ready. VLANs are an end-to-end agreement — the host can tag all it wants, but if the switch drops the tags, nothing works.
Before you start
- The switch port feeding the host is configured as a trunk (tagged) port
- The trunk allows every VLAN ID you plan to use on the host
- You know the VLAN IDs and the subnet/gateway for each one
- You have console or IPMI access in case management connectivity drops
- The host NIC is wired Ethernet, not Wi-Fi (bridges and tagging need wired)
If you only want VLAN isolation inside a single host — VMs on different VLANs that never leave the box — you can skip the switch entirely and use an internal VLAN-aware bridge with no uplink. The moment traffic has to reach another machine, the upstream trunk has to carry the tags.
Making vmbr0 VLAN-aware
The fastest path is the GUI. Open your node, go to System → Network, select vmbr0, click Edit, and tick VLAN aware. Apply the configuration. That’s the whole change for the bridge itself.
Under the hood, Proxmox writes this into /etc/network/interfaces:
auto vmbr0
iface vmbr0 inet static
address 192.168.10.50/24
gateway 192.168.10.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094Two lines do the work. bridge-vlan-aware yes turns on 802.1Q handling, and bridge-vids 2-4094 declares which VLAN IDs the bridge will pass. You can narrow bridge-vids to just the VLANs you use (for example bridge-vids 10 20 30), which is tidier and slightly safer.
After editing the file by hand, apply it without rebooting:
# apply all interface changes
ifreload -a
# confirm the bridge shows vlan_filtering 1
bridge -d link showTagging a VM
With the bridge VLAN-aware, putting a VM on a VLAN is a single field.
In the GUI: open the VM, go to Hardware, double-click the Network Device, and set VLAN Tag to the VLAN ID — say 20. The bridge stays vmbr0. Save, and the change applies the next time the NIC is reconfigured (a stop/start of the VM is the clean way).
From the shell, qm set does the same thing. Here VM 101 gets a virtio NIC on vmbr0 tagged into VLAN 20:
# put VM 101's net0 on vmbr0 with VLAN tag 20
qm set 101 -net0 virtio,bridge=vmbr0,tag=20The guest OS inside the VM uses a normal, untagged interface and picks up an IP from VLAN 20’s subnet — by DHCP if that VLAN has a DHCP server, or static otherwise. The VM has no idea a tag is involved. That’s the point: tagging happens at the bridge.
VM network device fields for VLANs
| Bridge | Stays vmbr0 — the VLAN-aware bridge carries every VLAN. |
|---|---|
| VLAN Tag | The access VLAN for this VM, e.g. 20. Leave blank for untagged/native. |
| Model | virtio for best performance on Linux and modern Windows (with drivers). |
| Firewall | Optional Proxmox firewall on this NIC, independent of the VLAN. |
Putting the host’s management IP on a tagged VLAN
Sometimes the management network is its own VLAN, and the trunk carries no untagged (native) traffic for the host. In that case the host’s IP can’t sit on plain vmbr0 — it needs a tagged interface.
On a VLAN-aware bridge you create a vmbr0.<vlanid> interface and move the IP there. Notice vmbr0 itself loses its address and gateway:
auto vmbr0
iface vmbr0 inet manual
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
auto vmbr0.10
iface vmbr0.10 inet static
address 192.168.10.50/24
gateway 192.168.10.1The vmbr0.10 notation tells Proxmox to put the host on VLAN 10. VMs still tag onto other VLANs through vmbr0 as before.
If you’re using the traditional method instead — no VLAN-aware bridge — you’d build a vlan-raw interface on the physical NIC and bridge that:
iface enp3s0 inet manual
auto enp3s0.10
iface enp3s0.10 inet manual
vlan-raw-device enp3s0
auto vmbr0v10
iface vmbr0v10 inet static
address 192.168.10.50/24
gateway 192.168.10.1
bridge-ports enp3s0.10
bridge-stp off
bridge-fd 0Both get the host onto VLAN 10. The VLAN-aware version is fewer moving parts, which is why it’s the better default.
Tagging LXC containers
Containers handle VLANs the same way. In the GUI, edit the container’s network interface and set VLAN Tag. From the shell, pct set uses a tag= option:
# put container 201 on vmbr0, VLAN 30, with a static IP
pct set 201 -net0 name=eth0,bridge=vmbr0,tag=30,ip=192.168.30.40/24,gw=192.168.30.1The container sees a clean eth0 with no tag. As with VMs, the bridge does the tagging.
When a tagged VM has no network
This is where most VLAN tickets land. Work through it from the bridge outward.
Common VLAN failure causes
| Bridge isn't VLAN-aware | No bridge-vlan-aware yes, so the tag is ignored or dropped. Check the bridge config. |
|---|---|
| Switch port isn't a trunk | The uplink is an access port, so tagged frames die at the switch. Trunk it and allow the VLAN. |
| VLAN not allowed on trunk | Trunk exists but doesn't permit that VLAN ID. Add the VLAN to the allowed list. |
| Wrong VLAN ID | Tag doesn't match the VLAN's real ID. Confirm the number against the switch config. |
| Guest IP on wrong subnet | VM is on the right VLAN but has an IP/gateway for a different subnet. |
| bridge-vids too narrow | You limited bridge-vids and forgot to include this VLAN ID. |
A quick way to narrow it down: temporarily move the VM’s NIC to an untagged port on a VLAN you know works. If it gets network without a tag, the problem is the tag path — bridge, trunk, or VLAN ID. If it’s still dead untagged, the issue is elsewhere (guest config, bridge uplink, or the VM’s network device pointing at the wrong bridge).
You can confirm the host’s view of VLAN filtering at any time:
# show per-port VLAN membership on the bridge
bridge vlan showWrapping up
VLANs in Proxmox come down to two decisions: make the bridge VLAN-aware (almost always the right call), then tag each VM or container with the VLAN ID it belongs to. The guest stays untagged, the bridge does the work, and the upstream trunk has to carry every VLAN you use. Most failures trace back to a non-VLAN-aware bridge or a switch port that isn’t trunking the right IDs.
If you’re still getting comfortable with Proxmox networking, the vmbr0 bridge guide covers the foundation this builds on, and the bare-metal install walkthrough shows where the first bridge gets created. For more, browse the Proxmox guides.
