Home Lab Networking with VLANs

Why VLANs Matter

A flat network works fine for a handful of devices. But as your homelab grows -- servers, VMs, IoT devices, guest Wi-Fi, management interfaces -- a single broadcast domain becomes a problem. VLANs solve this by creating logical networks on physical hardware, giving you segmentation, security boundaries, and better traffic management without buying more switches.

For someone with a Cisco networking background like myself, VLANs are second nature. But even if you're new to networking, the concepts are straightforward once you see them in action.

VLAN Design for Homelabs

Start with a simple numbering scheme. I use this pattern and it scales well:

• VLAN 10 -- Management -- Switches, routers, firewalls, IPMI/iLO interfaces
• VLAN 20 -- Servers -- Domain controllers, file servers, application servers
• VLAN 30 -- VMs -- Virtual machines running on Hyper-V/Proxmox
• VLAN 40 -- IoT -- Smart home devices, sensors, cameras (isolated from everything else)
• VLAN 50 -- Guest -- Guest Wi-Fi and devices with no access to internal resources
• VLAN 99 -- Native/Default -- Left as default on switches, unused for traffic

Keep your native VLAN (VLAN 99) different from any traffic-carrying VLAN. This prevents VLAN hopping attacks. Never use VLAN 1 for user traffic -- it's the default on virtually every switch and is a well-known attack vector.

Trunk Ports and Access Ports

Understanding the difference between trunk and access ports is fundamental:

• Access ports -- Carry traffic for a single VLAN. Connect to end devices like PCs, servers, and APs. Configured with switchport mode access and switchport access vlan X
• Trunk ports -- Carry traffic for multiple VLANs between switches, routers, and firewalls. Configured with switchport mode trunk and switchport trunk allowed vlan X-Y

On Brocade ICX switches (which I use extensively), trunk configuration looks like this:

interface 1/1/1
switchport mode trunk
switchport trunk allowed vlan 10,20,30,40,50
no shutdown

Be explicit about which VLANs are allowed on trunks. Don't use the default "allow all" -- it's a security risk and makes troubleshooting harder.

Inter-VLAN Routing

VLANs are isolated by default. To allow communication between them, you need routing. There are three common approaches:

• Router-on-a-stick -- A single physical interface with sub-interfaces for each VLAN. Simple but creates a bottleneck. Fine for homelabs with modest traffic
• Dedicated router per VLAN -- Multiple physical interfaces, each connected to a different VLAN. More hardware but better performance
• Layer 3 switch -- The switch itself handles routing between VLANs using SVIs (Switch Virtual Interfaces). Best performance, most complex setup

For a homelab, OPNsense or pfSense as a router-on-a-stick is the most popular approach. Create sub-interfaces for each VLAN, assign them IP addresses, and configure firewall rules between them.

DHCP Design

Each VLAN needs its own DHCP scope. You have two main options:

• DHCP on the router/firewall -- OPNsense/pfSense can run DHCP for all VLANs. Simple, centralized, and easy to manage
• DHCP relay to a central server -- Configure DHCP relay (ip helper-address) on each VLAN interface to point to a DHCP server on the server VLAN. Better for AD-integrated environments where DHCP needs to communicate with DNS for dynamic updates

Reserve IP addresses for network infrastructure (switches, APs, firewalls) outside the DHCP pool. Document your IP scheme so you're not guessing later:

• VLAN 10 (Management) -- 10.10.10.0/24 -- .1 = gateway, .2-.10 = reserved for devices, .100-.200 = DHCP pool
• VLAN 20 (Servers) -- 10.10.20.0/24 -- Same pattern
• VLAN 30 (VMs) -- 10.10.30.0/24 -- Same pattern

VLAN Security Best Practices

• Disable unused ports -- Any switch port that isn't in use should be shut down and assigned to a dead VLAN
• Enable DHCP Snooping -- Prevents rogue DHCP servers from handing out IP addresses on your network
• Enable DHCP Snooping -- Prevents rogue DHCP servers from handing out IP addresses on your network
• Enable Dynamic ARP Inspection (DAI) -- Prevents ARP spoofing attacks between VLANs
• Implement port security -- Limit the number of MAC addresses per access port to prevent unauthorized devices
• Isolate the IoT VLAN -- IoT devices are notoriously insecure. Give them internet access only, no access to management or server VLANs
• Log everything -- Enable syslog on all network devices and forward to a centralized log server

Wi-Fi and VLANs

Wireless access points are ideal VLAN endpoints. Most enterprise-grade APs (Ubiquiti, Aruba, Ruckus) support SSID-to-VLAN mapping:

• SSIDs mapped to VLANs -- Corporate SSID → VLAN 20, Guest SSID → VLAN 50, IoT SSID → VLAN 40
• 802.1X authentication -- For production environments, use RADIUS/Active Directory for wireless authentication. Great practice to set up in a homelab
• Separate management SSID -- A dedicated SSID for managing APs and switches, on the management VLAN

Troubleshooting VLANs

Common VLAN issues and how to fix them:

• Device can't get an IP address -- Check if the switch port is in the correct VLAN, trunk allowed list includes the VLAN, and DHCP relay is configured
• Cannot reach another VLAN -- Verify inter-VLAN routing is configured on the router/firewall and firewall rules allow the traffic
• Native VLAN mismatch -- If two connected switches have different native VLANs on a trunk, you'll see CDP/LLDP warnings and potentially VLAN leakage. Match native VLANs on both ends
• VLAN not showing up -- Ensure the VLAN is created on all switches in the topology, not just the one you're testing from

Use show vlan brief, show interfaces trunk, and show ip interface brief as your primary troubleshooting commands on Cisco/Brocade gear.