If you've spent any time in Proxmox VE's Datacenter > SDN menu, you've probably noticed there are a few different zone types to choose from, and the docs don't exactly hold your hand about which one to pick. Most beginner guides cover the Simple zone, because it's the easiest to understand, or VXLAN, because it sounds impressive. The VLAN zone sits in between, and it's honestly the one most homelabbers with a managed switch actually want.
A VLAN zone lets you carve your existing network into isolated segments using tags, but it does it through Proxmox's SDN system instead of you manually editing bridge configs on every node. If you've got more than one Proxmox host and you're tired of copy-pasting VLAN interface config between them, this is the feature that fixes that.
What You Will Learn
- What a VLAN zone is and how it's different from a plain VLAN-aware bridge
- Why you'd reach for SDN instead of just tagging traffic by hand
- How to create a VLAN zone, add a VNet, and attach a VM to it
- What each field in the SDN wizard actually controls
- The mistakes that trip people up, and how to fix them
What Is This Feature?
Let's back up for a second. A VLAN, short for Virtual LAN, is a way of splitting one physical network into several logically separate ones. Instead of running a separate cable for every network you want, you tag traffic with a number (1 to 4094) and your switch keeps traffic with different tags apart, even though it's all riding the same wire. It's the standard way networking people isolate departments, guest Wi-Fi, or in our case, groups of VMs, without buying more hardware.
Proxmox VE has supported VLAN tagging for years through what's called a VLAN-aware bridge. You'd take your bridge, say vmbr0, tick a box to make it VLAN aware, and then set a VLAN tag on each VM's network device. That still works fine today, and for a single node it's honestly simpler than what I'm about to describe.
SDN, which stands for Software-Defined Networking, is the newer layer Proxmox added on top. It lets you define networks once in the Datacenter view and have that definition rolled out to every node in your cluster automatically. A VLAN zone is one of the zone types SDN offers. It uses an existing Linux bridge on each node as its transport, then lets you create VNets inside that zone, each one mapped to its own VLAN tag. Create the VNet once, click Apply, and every node that has the underlying bridge gets a matching interface.
The practical difference from a VLAN-aware bridge: with SDN you manage VLANs as named networks (like "guest-lan" or "dmz") instead of remembering that VLAN 20 means guest Wi-Fi. You also don't have to touch /etc/network/interfaces on each host by hand, and adding a third or fourth node to the setup is a checkbox, not a repeat of the same manual steps.
Why Would You Use It?
If you only run one Proxmox node, I'll be straight with you: a VLAN-aware bridge probably does everything you need with less setup. SDN's VLAN zone earns its keep once you've got two or more nodes and want VMs on the same VLAN to talk to each other no matter which host they land on, without re-typing the tag every time.
It also pays off if you're the kind of person who wants network changes tracked and applied in one batch instead of scattered across config files on five different machines. The SDN overview page shows you every pending change before you commit it, which is a nice safety net compared to editing interfaces files over SSH at 11pm.
I'd skip it if you're running a single-node homelab with three VMs. Set up a VLAN-aware bridge, tag your VMs, and move on with your life. Come back to this once you've got a cluster or you're managing enough VLANs that a spreadsheet would help.
Here's how the three approaches stack up, since the naming doesn't make the differences obvious:
| VLAN-aware bridge | SDN VLAN zone | SDN Simple zone | |
|---|---|---|---|
| Where it's configured | Per node, in System > Network | Once, in Datacenter > SDN | Once, in Datacenter > SDN |
| Needs a managed switch | Yes, for multi-node | Yes, for multi-node | No |
| Traffic leaves the host | Yes, tagged | Yes, tagged | Only via NAT/routing |
| Networks have names | No, just tag numbers | Yes, VNet names and aliases | Yes |
| Good for | One node, a few VLANs | Clusters, many VLANs | Isolated lab networks |
The row that matters most for beginners is the last one. Pick based on what you're actually trying to do, not on which feature sounds more capable.
Prerequisites
Before you start, make sure you've got the following:
- Proxmox VE 8.1 or newer. SDN's core packages ship installed by default from 8.1 onward, so there's nothing extra to install on a recent system. On PVE 7.x you'll need to run
apt updatefollowed byapt install libpve-network-perlfirst. - A managed switch with VLAN support, or at minimum a switch port set to trunk mode if you're testing between two nodes. Without a real trunk, tagged traffic between nodes won't get anywhere.
- The same Linux bridge name (commonly
vmbr0) already configured on every node that will join the zone. SDN doesn't create this bridge for you. It has to already exist and already be up. - Root or an account with the SDN.Allocate permission on
/sdn. - A VLAN ID you're not already using elsewhere on your physical network. If your switch is handling VLAN 20 for something else, don't reuse it here unless that's intentional.
Step-by-Step Tutorial
Step 1: Confirm your bridge exists on every node
Log into each Proxmox node and check Datacenter > node name > System > Network. Confirm the bridge you plan to use (I'll use vmbr0 in this example) is present and active. It needs the same name on every node — SDN matches nodes to the zone by that bridge name, so a typo here means a node quietly gets left out.
Step 2: Create the VLAN zone
Go to Datacenter > SDN > Zones and click Add > VLAN. Fill in:
- ID: a short name for the zone, up to 8 characters. Something like
vlanzoneorhomelanworks. - Bridge: the name of the bridge you confirmed in step 1, for example
vmbr0. - Nodes: leave this blank to apply to all nodes, or select specific ones if you only want certain hosts participating.
- MTU: usually fine to leave blank unless you're running jumbo frames on your physical network, in which case match it here.
Click Create. You won't see any effect on your network yet — zones are just definitions until you attach a VNet and apply the config.
Step 3: Create a VNet inside the zone
Go to Datacenter > SDN > VNets and click Create VNet. You'll see:
- Name: up to 8 characters, this becomes the interface name on each node (for example
vnet20). - Alias: an optional, more readable label. I'd put something like "guest-vlan" here so you're not guessing what
vnet20means six months from now. - Zone: pick the VLAN zone you just created.
- Tag: the VLAN ID for this network, say
20. - VLAN Aware: leave unchecked unless you specifically want to trunk multiple VLANs through this single VNet into a guest, which is a more advanced setup than most people need.
Click Create. Repeat this step for each additional VLAN you want managed through SDN — one VNet per tag.
Step 4: Apply the configuration
Nothing you've done so far has touched your actual network config. Head back to the main Datacenter > SDN page. You'll see your zone and VNet listed with a pending state. Click Apply in the top toolbar.
This writes the config into files under /etc/network/interfaces.d/sdn on every affected node and reloads networking through ifupdown2. It's non-disruptive to existing traffic in almost all cases, but I still wouldn't do this for the first time on a production host in the middle of the workday.
Step 5: Attach a VM to the VNet
Pick a VM, open its Hardware tab, and edit the network device. In the Bridge dropdown, you should now see your VNet name (vnet20) listed alongside your regular bridges. Select it, leave the VLAN Tag field on the VM's network device blank (the VNet already carries the tag), and start or reboot the VM.
Step 6: Test connectivity
Boot two VMs on the same VNet, ideally on two different nodes, and give them static IPs on the same subnet. Ping between them. If that works across nodes, your VLAN is correctly trunked through your physical switch and SDN is doing its job. If it only works between VMs on the same node, your switch port almost certainly isn't passing that VLAN tag between hosts.
One thing worth understanding: at this point your VMs can talk to each other, but they have no gateway and no DHCP unless something on that VLAN provides them. A VLAN zone deliberately doesn't do routing or address handout — it just moves tagged frames. If you want the VMs on VLAN 20 to reach the internet, something else has to route for them: your physical router with a sub-interface on VLAN 20, a pfSense or OPNsense VM with a leg on that VNet, or a Layer 3 switch. That catches a lot of people who expected the Simple zone's built-in NAT behaviour to carry over.
Step 7: Add more VLANs as you need them
Once the first VNet works, adding a second is a two-minute job: create another VNet in the same zone with a different tag, click Apply, done. No per-node work, no editing interface files. That repeatability is the actual payoff for the setup effort you just went through.
Commands Explained
Most of this tutorial happens in the GUI, but a couple of commands are worth knowing if you want to check things from the shell:
| Command | What it does |
|---|---|
apt install libpve-network-perl | Installs the SDN backend package on PVE 7.x hosts where it isn't already present. |
cat /etc/network/interfaces.d/sdn | Shows the actual interface config SDN generated after you clicked Apply. Useful for confirming what got written. |
ip -d link show vnet20 | Shows the low-level details of the VNet interface, including its VLAN tag and parent bridge, directly from the kernel. |
ifreload -a | Manually reapplies all interface config from ifupdown2. This is effectively what the Apply button triggers behind the scenes. |
Common Errors
A few things come up over and over with VLAN zones:
- "Apply" button does nothing visible. That's actually normal. Applying SDN changes rarely produces a pop-up unless something fails. Check
/etc/network/interfaces.d/sdnon the node to confirm the config landed. - VNet doesn't show up in a VM's bridge dropdown. Almost always means you forgot to click Apply, or the zone's node selection doesn't include that particular host.
- VMs on the same VNet can't reach each other across nodes. This is a switch problem, not a Proxmox problem, nine times out of ten. Your trunk port needs to allow that specific VLAN tag, not just be set to trunk mode in general.
- "VLAN tag already in use" when creating a VNet. Each VLAN tag can only be assigned to one VNet per zone. If you need the same VLAN in two separate zones for some reason, that's technically possible, but double-check you actually meant to do that.
Troubleshooting
If connectivity isn't working after you've applied the config and attached a VM, work through this in order:
- Confirm the VNet interface exists on the node with
ip link show vnet20. If it's missing, the Apply step didn't run on that host, likely because the node wasn't included in the zone's node list. - Check that the bridge itself (
vmbr0) is up and has a physical NIC attached. A VNet built on top of a dead bridge won't pass any traffic. - Verify the physical switch port feeding that NIC is trunked and explicitly allows the VLAN tag you assigned. Some switches default to only passing VLAN 1 on a trunk unless you add others manually.
- Check the VM's network device is actually pointed at the VNet and not still on the old bridge — this one sounds obvious, but it's the most common miss after a config change.
- Look at
journalctl -u networkingon the node for errors from the lastifreload, which sometimes points straight at a typo in the zone or VNet definition.
Best Practices
A few habits that'll save you time later:
- Keep a simple table somewhere (even a text file) mapping VLAN tags to their purpose. "VLAN 20 = guest devices" is obvious to you today and a mystery in eight months.
- Use the Alias field on every VNet. Interface names are capped at 8 characters, which forces cryptic abbreviations — the alias is where you get to be clear.
- Don't reuse VLAN IDs that are already doing something on your physical network unless you mean to bridge those networks together.
- Apply SDN changes one zone at a time when you're still learning the system, rather than batching ten changes together. It's much easier to spot what broke.
- Match your bridge name across nodes exactly, including case. "vmbr0" and "vmbr0 " with a trailing space have caused more than one late night for someone.
Frequently Asked Questions
Do I need a managed switch for this to work?
Yes, if you want VLANs to span more than one node. A single node can technically use a VLAN zone with an unmanaged switch since the tagging happens entirely inside Proxmox, but you lose the whole point of tagging if nothing downstream understands it.
Can I mix a VLAN zone and a Simple zone on the same host?
Yes. Zones are independent of each other. It's common to run a Simple zone for an isolated NAT lab network alongside a VLAN zone for your "real" segmented networks.
What happens to existing VMs on a VLAN-aware bridge if I switch to SDN?
Nothing, automatically. VLAN-aware bridges and SDN VLAN zones coexist fine. You'd need to manually move each VM's network device to the new VNet if you want to migrate it over.
Does the VLAN tag need to match anything on the switch configuration name-wise?
No, the tag is just a number (1-4094). Your switch config and your Proxmox VNet just both need to agree on that number for the same logical network.
Is there a limit to how many VNets I can create in one zone?
Practically, you're limited by available VLAN IDs (4094 of them), not by anything Proxmox imposes. Most homelabs never get close to that.
Conclusion
A VLAN zone won't replace a VLAN-aware bridge for everyone, and it shouldn't. But once you're managing more than one Proxmox host, defining your VLANs centrally through SDN saves you from the tedium of matching config by hand across every node. Get the underlying bridge right on each host, apply your changes deliberately, and check your switch trunk before you assume Proxmox is the problem — most VLAN zone issues turn out to live on the network hardware, not in the SDN config itself.