VLANs are often presented as the upgrade that makes a homelab serious. The shopping list appears first: a managed switch, a VLAN-aware access point, and a firewall with enough interfaces. The harder part is not the equipment. It is deciding which communication should be allowed after the network is divided.
Start with trust boundaries rather than device categories. Infrastructure management, ordinary clients, internet-facing services, and untrusted devices have different risks. A printer and a television may both be “IoT,” but the important fact is that neither needs administrative access to a hypervisor.
Write the traffic matrix first #
Before choosing VLAN IDs, list the flows that must work. Administrators need to reach Proxmox and switch management. Clients need DNS, NTP, and selected applications. A reverse proxy may need to reach two internal web services but not the storage network. Backup systems need carefully scoped access to the guests or hypervisors they protect.
Write those needs as source, destination, service, and reason. The reason is important: a rule without a reason is difficult to remove later. Begin with whole network zones, then narrow high-value paths by address and port where the extra precision is useful.
Avoid a design with one VLAN per application. It creates more interfaces, firewall objects, DHCP scopes, and troubleshooting paths than most home environments can justify. Four or five durable zones are easier to operate than twenty clever ones.
Pick boring numbers and names #
VLAN numbers do not provide security. They are labels carried in Ethernet frames, so choose IDs that are easy to recognize and keep the meaning in one inventory. For example, management might use 10, servers 20, clients 30, and untrusted devices 40. The exact values matter less than consistency across the router, switches, access points, and Proxmox bridges.
Give every subnet a matching human name. servers is more useful in a firewall
log than vlan20, and management documents intent better than trusted.
Reserve space for future changes, but do not create empty networks simply to
fill a numbering scheme.
Decide where routing happens #
Traffic between VLANs needs a router. In a small lab, that is usually the main firewall. Keeping inter-VLAN routing there gives one place for policy and logs. It also means the router, its uplink, and the relevant switch trunks become important dependencies.
Document which ports are trunks and which are access ports. A trunk carries several tagged VLANs between infrastructure components. An access port normally presents one untagged network to an ordinary device. A native or untagged VLAN on a trunk can be convenient, but inconsistent expectations at each end cause some of the most confusing failures.
Build one path at a time #
Create the management path first and preserve a console recovery option. Then add one test VLAN, one DHCP scope, and one disposable client. Verify address assignment, DNS, internet access, and blocked cross-zone traffic. Only after the complete path works should it be copied for the next zone.
Test denial as carefully as access. A client in the untrusted zone should fail to open the Proxmox interface, while still reaching its resolver and approved internet destinations. Save the expected results beside the traffic matrix. After a firewall change, those checks provide a small regression test instead of relying on the absence of complaints.
Budget for operations #
Segmentation adds real maintenance. Every new VLAN needs an address plan, DHCP behavior, DNS policy, firewall rules, switch configuration, monitoring, and a recovery method. Multicast discovery may not cross the router, which affects printers and media devices. Emergency access may depend on the very firewall being repaired.
That cost is acceptable when the boundary reduces meaningful risk. It is waste when a network exists only to make a diagram symmetrical. Prefer a few zones whose policy can be stated in one sentence each, and review unused exceptions during normal maintenance.
A VLAN plan is successful when it makes policy visible and failure predictable. If the diagram cannot explain why a packet should pass, buying a larger switch will not make the design clearer.