Virtual LANs (VLANs) allow you to split a single physical network into multiple isolated segments, each behaving as if it were on its own dedicated switch. For UK home users and small businesses running Proxmox, VLANs have become increasingly relevant — particularly following NCSC guidance recommending that IoT devices (smart speakers, security cameras, heating controllers) be kept on a separate network from your main computers and servers. Whether you want to isolate your home lab traffic from production workloads, keep guest Wi-Fi away from internal resources, or segment your Proxmox VMs by function, VLANs give you that control without buying additional hardware.
What You Need Before You Start
VLANs require a managed switch that supports 802.1Q VLAN tagging — an unmanaged switch will not work. In the UK, common choices are the DrayTek VigorSwitch series (popular with SMBs) and Ubiquiti UniFi switches (favoured by home lab enthusiasts for their web-based management). Both support 802.1Q trunking and per-port VLAN assignment. You will also need a network interface card (NIC) in your Proxmox host — a single port is sufficient if you use a VLAN-aware bridge, which is the recommended approach.
Decide on your VLAN IDs before you begin. A common layout might be:
- VLAN 10 — Trusted LAN (main workstations, servers)
- VLAN 20 — Home lab / Proxmox VMs
- VLAN 30 — IoT devices
- VLAN 40 — Guest network
Configuring Trunk and Access Ports on Your Switch
Your Proxmox host connects to the switch via a trunk port — a port that carries traffic from multiple VLANs simultaneously, each tagged with its VLAN ID. Devices such as PCs and IoT gadgets connect to access ports, which carry untagged traffic for a single VLAN only; the switch adds the tag transparently.
On a UniFi switch, navigate to Devices → your switch → Ports, select the port connected to Proxmox, and set the native network (untagged) plus add each VLAN as a tagged network. On a DrayTek VigorSwitch, go to VLAN → 802.1Q VLAN, create each VLAN, and mark the Proxmox uplink port as a tagged member of all VLANs. Access ports for end devices should be set as untagged members of their respective VLAN only.
Approach One: VLAN-Aware Linux Bridge (Recommended)
Proxmox supports two approaches to VLANs. The first — and generally preferred — method is a single VLAN-aware Linux bridge. This means one bridge handles all VLANs; you assign the VLAN tag at the VM or container level rather than creating separate bridges. It is cleaner, easier to maintain, and scales well.
Edit the network configuration file on your Proxmox host:
nano /etc/network/interfacesYour existing bridge entry will look something like this:
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0Add bridge-vlan-aware yes to enable VLAN awareness, and optionally bridge-vids 2-4094 to allow all VLAN IDs across the bridge:
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094Save the file and reboot the Proxmox host to apply the changes:
rebootOnce the host is back up, verify the change has taken effect via the Proxmox web UI under System → Network. You should see VLAN aware: Yes against vmbr0.
Assigning a VLAN Tag to a VM or Container
With a VLAN-aware bridge in place, assigning a VM to a VLAN is straightforward. In the Proxmox web UI, navigate to your VM or LXC container, go to Hardware → Network Device, and edit the network interface. Set the Bridge to vmbr0 and enter the VLAN Tag — for example, 20 for your lab VLAN. Click OK and restart the VM.
The VM will now send and receive traffic tagged with VLAN 20 at the bridge level. From the VM’s perspective, it simply has a normal network interface — the tagging is handled transparently by Proxmox and the switch.
Approach Two: A Separate Bridge per VLAN
The alternative is to create a dedicated Linux bridge for each VLAN. This approach suits environments where you want explicit separation at the Proxmox level, or where you are connecting physical interfaces to different switches for each VLAN.
In /etc/network/interfaces, create a VLAN sub-interface on your physical NIC and attach it to its own bridge:
auto eno1.20
iface eno1.20 inet manual
auto vmbr20
iface vmbr20 inet static
address 10.20.0.1/24
bridge-ports eno1.20
bridge-stp off
bridge-fd 0Repeat for each VLAN. VMs are then attached to the relevant bridge (vmbr20, vmbr30, and so on) rather than using a VLAN tag. This method is more explicit but creates more bridges to manage, and can become unwieldy beyond four or five VLANs. For most setups, the VLAN-aware bridge is the better choice.
Routing Between VLANs with pfSense or OPNsense
By default, VLANs cannot communicate with each other — that is the point. If you need controlled inter-VLAN routing (for example, allowing your lab VLAN to reach your NAS on the trusted LAN, but not the other way around), the cleanest solution is to run a virtual router inside Proxmox. Both pfSense and OPNsense are free, open-source options that run well as Proxmox VMs.
Create a VM, attach multiple network interfaces each tagged with a different VLAN, and configure each as a separate interface within pfSense or OPNsense. You can then define firewall rules that control precisely which traffic is permitted between VLANs — allowing, for instance, SSH from VLAN 20 to VLAN 10 on specific ports, while blocking all IoT traffic on VLAN 30 from initiating connections to any other segment.
Testing VLAN Isolation
Once configured, verify that isolation is working as expected. Assign two VMs to different VLANs and attempt to ping between them — the ping should fail unless you have explicitly permitted it at the router. Also confirm that each VM can reach its default gateway (the router interface on its VLAN) and reach the internet if appropriate.
On the switch side, a simple test is to connect a laptop to an access port on VLAN 30 and confirm it cannot reach devices on VLAN 10. Proper isolation means that even if an IoT device on VLAN 30 is compromised, it cannot directly access your workstations, NAS, or Proxmox management interface — precisely the outcome recommended by NCSC guidance for home and small business networks.
A Note on Proxmox Management Access
Take care when reconfiguring network interfaces on a live Proxmox host — an error in /etc/network/interfaces can leave the host unreachable over the network. Always have console access (via iDRAC, IPMI, or a physical monitor and keyboard) before making changes. Keep your Proxmox management interface on a dedicated, trusted VLAN and never expose it to IoT or guest segments.
Related articles: Proxmox — Complete Guide and How-To Index, Proxmox Cheat Sheet: CLI Commands for VMs, LXC and Storage, Best Hardware for a Proxmox Home Lab Server (UK), How to Access Proxmox Remotely with Tailscale
Related: how to set up VLANs in UniFi
