Most home lab guides skip the boring bit. They show you how to spin up containers and virtual machines, but leave everything sitting on a single flat network where your NAS, your experimental Kubernetes cluster and your kids' tablets all share the same broadcast domain. That is fine until your latest Docker experiment gets compromised and suddenly has line of sight to every device in your house. I run a segmented home lab built on Proxmox and OPNsense. It is not theoretical - it is the network I use every day. This guide walks through exactly how I structured it, why I made the choices I did, and how you can do the same thing over a weekend. If you want the enterprise version of this conversation, I have written a separate [network segmentation strategy guide](/blog/2026-03-09-network-segmentation-guide/) aimed at IT leaders. This post is the hands-on, home lab version. --- ## Why Bother Segmenting a Home Lab? The short answer: containment. A flat network means every device can talk to every other device. Your Proxmox host, your IoT smart plugs, your work laptop and that sketchy container you pulled from Docker Hub last Tuesday all exist in the same trust zone. If any one of them gets compromised, the attacker has unrestricted lateral movement across everything you own. Segmentation fixes this by creating boundaries. A compromised IoT device cannot reach your NAS. A rogue container cannot scan your management interfaces. Each segment has explicit rules about what traffic is allowed in and out. Beyond security, segmentation gives you: - **Broadcast domain control.** IoT devices are notoriously chatty. Isolating them stops mDNS and SSDP noise from polluting your production VLANs. - **A realistic test environment.** If you work in IT, your home lab should mirror enterprise patterns. Segmented networks with firewall rules are how production environments work. - **Traffic visibility.** When each VLAN has defined purposes, firewall logs become meaningful. You can see exactly what is talking to what. ## The Architecture Here is the network layout I use. Yours will differ based on your hardware and needs, but the principles apply universally. ### VLAN Design

VLAN ID	Name	Subnet	Purpose
1	Management	10.0.0.0/24	OPNsense, switch management, IPMI/iDRAC
10	Trusted	10.0.10.0/24	Personal devices, workstations, phones
20	IoT	10.0.20.0/24	Smart home devices, cameras, sensors
30	Lab	10.0.30.0/24	Experimental VMs, containers, dev work
50	Servers	10.0.50.0/24	Production services - NAS, Plex, Pi-hole
99	Guest	10.0.99.0/24	Guest Wi-Fi, fully isolated

Six VLANs is enough for most home labs. I have seen people create 15 or more and then spend their weekends debugging firewall rules instead of actually using their lab. Start with fewer segments and split later if you need to. ### Key Design Decisions **Management VLAN on VLAN 1.** Some people insist on moving management off the default VLAN. In an enterprise, I agree. At home, keeping management on VLAN 1 simplifies initial switch configuration since untagged traffic lands there by default. The important thing is that only management devices live on it. **Separate IoT and guest networks.** IoT devices need internet access and sometimes local communication with each other (Hue bridges, for example). Guests need internet only. Keeping them separate means you can allow IoT-to-IoT traffic within the VLAN while locking guests down completely. **Lab VLAN with restricted outbound.** The lab VLAN has internet access but cannot initiate connections to any other internal VLAN. This is where I run anything experimental. If something goes wrong, the blast radius is contained. ## Hardware You Need You do not need enterprise gear. Here is the minimum: - **A VLAN-capable managed switch.** Unmanaged switches do not understand VLAN tags. A TP-Link TL-SG108E (around thirty quid) handles eight ports with full VLAN support. If you need more ports or PoE, the Netgear GS308EPP is solid. - **A router/firewall that supports VLANs.** OPNsense or pfSense running on dedicated hardware or as a VM. I run OPNsense virtualised on Proxmox, which works brilliantly but requires a bit more setup. - **VLAN-aware access points (optional).** If you want segmented Wi-Fi (and you should), your access points need to support multiple SSIDs mapped to VLANs. UniFi APs do this well. So do TP-Link Omada devices. ## Setting Up VLANs on OPNsense I am assuming you have OPNsense installed and working as your gateway. If you are running it as a VM on Proxmox, make sure the virtual network interface is configured as a VLAN trunk (more on that in the Proxmox section below). ### Step 1: Create VLAN Interfaces Navigate to **Interfaces > Other Types > VLAN** and create each VLAN: - **Parent interface:** The physical (or virtual) interface connected to your managed switch - **VLAN tag:** The ID from your design (10, 20, 30, 50, 99) - **Description:** Something meaningful - "Trusted", "IoT", "Lab" ### Step 2: Assign and Configure Interfaces Go to **Interfaces > Assignments**. Each VLAN appears as an available interface. Assign each one, then configure it: - **IPv4 Configuration Type:** Static IPv4 - **IPv4 Address:** The gateway IP for that subnet (e.g. 10.0.10.1/24 for Trusted) Enable the interface and save. ### Step 3: Configure DHCP For each VLAN interface, navigate to **Services > ISC DHCPv4** (or Kea, depending on your OPNsense version) and enable DHCP: - **Range:** Leave room for static assignments. I typically use .100 to .200 for dynamic and reserve .1 to .99 for static mappings. - **DNS servers:** Point to your Pi-hole or Adguard instance if you run one, otherwise use your preferred public DNS. - **Gateway:** The OPNsense interface IP for that VLAN. ### Step 4: Firewall Rules This is where segmentation actually happens. Without firewall rules, VLANs are just addressing schemes - traffic still flows freely through your router. My baseline rules follow a simple philosophy: **deny everything between VLANs, then allow specific exceptions.** **For every VLAN interface, create these rules in order:** 1. **Allow DNS to OPNsense.** Allow UDP/TCP 53 to the VLAN's gateway IP. Devices need to resolve names. 2. **Allow DHCP.** This usually works automatically, but add an explicit allow for UDP 67/68 if needed. 3. **Block RFC1918 to other VLANs.** Create a rule that blocks traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. This single rule prevents inter-VLAN traffic without needing to enumerate every subnet. 4. **Allow internet.** A default allow rule for traffic destined to non-RFC1918 addresses. **Exceptions I use:** - Trusted VLAN can access the Servers VLAN on specific ports (SSH, HTTP/HTTPS, SMB for NAS access). - IoT VLAN can reach specific services on the Servers VLAN (my Home Assistant instance needs to talk to smart devices, so I allow established/related connections back). - Nothing can initiate connections to the Management VLAN except the Trusted VLAN on the OPNsense web UI port. The order matters. OPNsense evaluates rules top to bottom and stops at the first match. Put your allow rules above the block-RFC1918 rule, or they will never be reached. ## Configuring Proxmox for VLANs If you run Proxmox, you need to tell it about your VLANs so virtual machines land on the correct segments. ### Option 1: VLAN-Aware Bridge (Recommended) Edit your Proxmox network configuration. You want your main bridge to be VLAN-aware: ``` auto vmbr0 iface vmbr0 inet manual bridge-ports eno1 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 1 10 20 30 50 99 ``` With a VLAN-aware bridge, you assign VLANs per VM in the Proxmox GUI. When creating or editing a VM's network device, set the **VLAN Tag** field to the appropriate VLAN ID. The VM's traffic is then tagged on that VLAN automatically. This is the cleanest approach. One bridge, all VLANs, per-VM tagging. ### Option 2: Separate Bridges per VLAN If you prefer explicit separation, create a bridge for each VLAN: ``` auto vmbr10 iface vmbr10 inet manual bridge-ports eno1.10 bridge-stp off bridge-fd 0 ``` This works but gets unwieldy with many VLANs. I moved away from this approach after the fourth bridge. ### OPNsense as a Proxmox VM If OPNsense runs on Proxmox (which I recommend for home labs - one box to rule them all), the setup is: 1. **Pass the physical NIC through** to OPNsense as a trunk port on the VLAN-aware bridge with no VLAN tag set. This means OPNsense receives all tagged traffic and handles VLAN routing itself. 2. **Add a second NIC** for the WAN interface, either a separate physical port or a bridge connected to your ISP router. 3. **The switch uplink port** must be configured as a trunk carrying all your VLAN tags. This creates a clean architecture where Proxmox handles virtualisation and OPNsense handles all routing and firewalling. ## Managed Switch Configuration Your managed switch needs to know which ports carry which VLANs. The terminology varies between manufacturers, but the concepts are the same. ### Trunk Ports (Tagged) Trunk ports carry multiple VLANs simultaneously using 802.1Q tags. Configure trunk ports for: - The port connected to your OPNsense box (or Proxmox host) - Uplinks between switches - Ports connected to VLAN-aware access points ### Access Ports (Untagged) Access ports strip VLAN tags and present untagged traffic to the connected device. Most endpoint devices (PCs, printers, NAS boxes) connect to access ports assigned to a single VLAN. For example, your NAS connects to a port that is an untagged member of VLAN 50 (Servers). The NAS sends and receives normal untagged Ethernet frames and never needs to know VLANs exist. ### Example: TP-Link Switch VLAN Table

Port	VLAN 1 (Mgmt)	VLAN 10 (Trusted)	VLAN 20 (IoT)	VLAN 30 (Lab)	VLAN 50 (Servers)	VLAN 99 (Guest)
1 (OPNsense)	Tagged	Tagged	Tagged	Tagged	Tagged	Tagged
2 (Desktop)	-	Untagged	-	-	-	-
3 (NAS)	-	-	-	-	Untagged	-
4 (AP)	-	Tagged	Tagged	-	-	Tagged
5-7 (Lab)	-	-	-	Untagged	-	-
8 (Mgmt)	Untagged	-	-	-	-	-

Port 1 is the trunk to OPNsense carrying all VLANs. Port 4 is the trunk to the access point carrying the SSIDs you want broadcast over Wi-Fi. ## Testing Your Segmentation Do not assume it works. Test it. From a device on each VLAN, try to: 1. **Ping the default gateway.** This should work on every VLAN. If it does not, check your interface assignments and DHCP config. 2. **Ping a device on another VLAN.** This should be blocked (unless you created a specific allow rule). If pings succeed between VLANs you did not explicitly allow, your firewall rules are wrong. 3. **Access the internet.** Every VLAN except Management should have outbound internet access. Management only needs it for OPNsense updates. 4. **Test your exceptions.** Can your trusted workstation reach the NAS via SMB? Can your phone reach Home Assistant? Verify every allow rule works as intended. I keep a simple text file listing every test case and run through it whenever I change firewall rules. It takes ten minutes and has caught misconfigurations more than once. ## Common Mistakes **Forgetting to allow DNS.** Devices cannot resolve hostnames, so everything appears "broken" even though network connectivity is fine. Always allow DNS to your resolver as the first rule on each VLAN. **Blocking established connections.** If you allow Trusted to connect to Servers on port 443, the response traffic needs to get back. OPNsense handles this with stateful firewall rules (it tracks connections automatically), but if you are writing manual rules elsewhere, remember to allow established and related traffic. **Putting the management interface on an accessible VLAN.** Your OPNsense web UI, Proxmox console and switch management pages should only be reachable from the Management or Trusted VLAN. Do not leave management interfaces exposed to IoT or Guest. **Over-segmenting.** Every VLAN you add is a firewall ruleset you need to maintain. Six VLANs is practical. Twenty is a full-time job. Segment by trust level, not by device type. ## Applying This to the Real World I run this exact setup as both my home network and my test environment for work. When I need to validate a [network segmentation strategy](/blog/2026-03-09-network-segmentation-guide/) before proposing it to the board, I prototype it at home first. When I want to test whether a new [privileged access management](/blog/2026-03-07-privileged-access-management/) tool works with segmented networks, I have a safe environment to do it. The crossover between home lab and professional IT is the real value here. Enterprise segmentation uses the same principles - VLANs, firewall rules, least-privilege access - just at a larger scale with more expensive hardware. If you can segment a home lab, you understand the fundamentals well enough to design or evaluate an enterprise network. --- ## Where to Go from Here Once your basic segmentation is working, consider these next steps: - **Intrusion detection.** OPNsense includes Suricata for IDS/IPS. Run it on your inter-VLAN traffic to catch suspicious patterns. - **DNS filtering per VLAN.** Different Pi-hole or Adguard profiles for different segments. Block ads on Trusted, block everything dodgy on IoT, allow everything on Lab. - **Firewall logging and monitoring.** Export OPNsense logs to a syslog server or Grafana dashboard. Visibility is the whole point of segmentation. - **802.1X authentication.** For the truly committed, RADIUS-based port authentication ensures devices land on the correct VLAN automatically based on their credentials. Network segmentation is not glamorous. Nobody posts their firewall rules on Reddit for upvotes. But it is one of those foundational practices that makes everything else in your home lab more secure, more manageable and more professionally relevant. Get it right once, and you will wonder how you ever ran a flat network.

OPNsense

Home Lab Network Segmentation: A Practical Guide with VLANs, OPNsense and Proxmox