On a flat network every device can reach every other one: compromising a smart light bulb or a guest's laptop also exposes the hypervisor and the backups. Segmentation limits the reach of an incident (the so-called blast radius) by splitting the network into separate domains, with explicit rules between them. The reference design for a homelab is built with 802.1Q VLANs and, on Proxmox VE, with a VLAN-aware bridge.
Why segment
There are three concrete benefits. The first is containment: a compromised device reaches only what its segment allows. The second is policy readability, since rules are written by role ("home devices do not initiate connections to the servers") instead of by individual address. The third is reduced broadcast and multicast traffic in each domain.
Important
A VLAN separates layer 2, but it does not protect anything by itself. Security depends on the point where the segments are routed, that is the firewall or router, which must enforce a restrictive policy. Without filters between the VLANs you just get a more complicated network.
Reference design
The design uses five segments. Each VLAN maps to a distinct IP subnet, documented in a single list; the IDs are indicative.
| ID | Name | Typical contents |
|---|---|---|
| 10 | Management | administration interfaces of hypervisors, switches, access points and backup servers |
| 20 | Servers | virtual machines, containers, NAS and internal services |
| 30 | Clients | everyday computers and laptops |
| 40 | Home automation and IoT | smart devices, cameras, printers |
| 50 | Guests | visitors' devices, Internet access only |
VLAN 1, the default on many devices, stays unused. Depending on your needs you add segments for storage, backup or VPN access; the Corosync network of a Proxmox cluster, on the other hand, should be separate and not routed (see Three-node Proxmox VE cluster).
Trunks and access ports
The 802.1Q tag adds 4 bytes to the Ethernet frame and contains a 12-bit identifier: usable IDs range from 1 to 4094. On the switch a port is access when it carries a single untagged VLAN (end devices) and trunk when it carries several tagged VLANs (links between devices, hypervisors, access points).
| Port | Mode | VLANs |
|---|---|---|
| Link to the firewall | trunk | all VLANs, tagged |
| Proxmox node | trunk | only those used by management and guests |
| Workstation | access | 30, untagged |
| Wi-Fi access point | trunk | 30, 40 and 50 tagged, one SSID per VLAN |
On trunks it is better to list the allowed VLANs explicitly instead of letting them all through.
Default-deny between segments
Traffic between segments is denied by default: you open only the flows that are needed, by source, destination and service. The firewall is stateful, so replies to allowed flows are admitted automatically. The table is conceptual and does not describe real rules: it shows who can initiate a connection to whom (n/a is the same segment).
| Source / destination | Management | Servers | Clients | Home automation and IoT | Guests | Internet |
|---|---|---|---|---|---|---|
| Management | n/a | yes | yes | yes | no | updates only |
| Servers | no | n/a | no | no | no | updates only |
| Clients | admin workstation only | specific services | n/a | specific devices | no | yes |
| Home automation and IoT | no | DNS and NTP only | no | n/a | no | limited |
| Guests | no | no | no | no | n/a | yes |
Exceptions are documented one by one: who, to what, why. Remote access over VPN (see WireGuard: remote access and site-to-site VPN) should be treated as a segment of its own, with its own rules, instead of placing it directly in management.
VLAN-aware bridge on Proxmox
With a VLAN-aware bridge a single bridge (vmbr0) carries all the VLANs and each virtual network card gets its own tag. In the node's configuration file:
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet manual
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
auto vmbr0.10
iface vmbr0.10 inet static
address 192.0.2.11/24
gateway 192.0.2.1bridge-vids 2-4094 admits tags 2 through 4094 on the bridge; VLAN 1 stays the default for untagged traffic, which the design does not use. The host's management address sits on a VLAN interface (vmbr0.10) and not on the untagged network. For VMs and containers the tag is assigned from the "VLAN Tag" field of the network card: 20 for a VM in the server segment, 50 for a test guest in the guest network. Manual changes to the file are applied with ifreload -a, which requires ifupdown2.
ifreload -aWarning
A wrong network configuration can make the node unreachable, as the Proxmox VE documentation itself warns. Apply changes from the local console or out of band, in a maintenance window, with a way to go back to the previous configuration. On the switch side the node's port must already be a trunk with the right VLANs.
Tip
For more elaborate setups Proxmox VE also offers SDN VLAN zones, managed from the web interface.
Common mistakes
- Native VLAN and VLAN 1. Untagged frames on a trunk end up in the native VLAN; if the two ends disagree, traffic leaks from one segment to another. It is best to avoid VLAN 1 and set an unused native VLAN on every trunk, which also reduces the risk of VLAN hopping with double tagging.
- Forgotten DHCP and DNS. Every VLAN needs its own DHCP scope (or a relay), a gateway and a reachable DNS. A new VLAN "does not work" almost always because one of them is missing.
- mDNS and discovery. Multicast does not cross routers: printers, casting and home devices discovered with mDNS vanish between segments. The fix is an mDNS reflector (for example Avahi's or the equivalent firewall feature) limited to the segments that need it, opening only the service ports.
- Incomplete trunks. A VLAN missing from the allowed list on a single device breaks the path: verify the whole chain.
- Management on the same segment as guests. A hypervisor interface reachable from every VM cancels most of the benefit. SSH and the web interface stay reachable only from the management VLAN (see the Debian SSH hardening checklist).