Home Network Segmentation: A Security Engineer’s Setup in 2026

Last updated: July 2026

Most home networks are flat. Your laptop with your banking session open sits on the same segment as a smart thermostat running firmware from three years ago that nobody’s patched. That’s fine until the thermostat gets popped and suddenly it can talk to your NAS.

Network segmentation — dividing the home network into isolated zones with controlled inter-zone traffic — solves this at the architecture level. It doesn’t require enterprise equipment. It does require a router capable of running proper firewall rules and VLAN configuration.

Here’s a practical home network segmentation setup built for security-conscious practitioners. This is the foundational module of a complete home lab — see the full guide to building a home cybersecurity lab for how it connects to offensive practice, malware analysis, and detection modules.

Why This Matters Specifically for a Research Lab

If you’re running a security research lab rather than just a normal household, the risk profile is sharper than the thermostat example above. Running a lab on a flat network without segmentation is the kind of thing that seems fine until it isn’t:

Lateral movement from lab to personal devices. A VM you’ve intentionally compromised to study post-exploitation behavior is on the same network as your bank-connected laptop. If the malware you’re analyzing is network-aware, you’ve created a real exposure.

Contamination of personal credentials. Running credential-harvesting tools against lab targets in an environment where your personal devices are also responding creates obvious risks — particularly with broadcast-based protocols like NetBIOS, LLMNR, and mDNS.

Accidental scope expansion. A port scan or vulnerability scan intended for your lab subnet hits real devices if it’s run against your home network instead. A tool that sends broadcast traffic reaches everything on the segment, lab boundary or not.

The Security Lab VLAN (99) described below exists specifically to contain these risks — treat it as genuinely isolated, not just logically separate.

The Core Concept: Trust Zones

Segmentation is fundamentally about trust. Different devices warrant different trust levels based on two factors: how much you trust the device itself, and how sensitive the assets it can reach are.

A practical trust tier model for a home network:

Trusted (management zone): Your primary workstation, security research lab, devices you fully control and regularly update. Can initiate connections to most other zones. Should not be reachable from lower-trust zones.

Semi-trusted (personal devices): Phones, tablets, family member devices, laptops used for general browsing. Can reach the internet and shared resources (NAS, media server). Should not reach the management zone without explicit rules.

IoT: Smart TVs, cameras, thermostats, smart speakers, printers, game consoles, any device with embedded firmware you don’t control. Internet access yes; access to other internal zones — no. This is the critical isolation.

Guest: Temporary access for visitors. Internet only, isolated from everything internal.

Server/DMZ: Anything hosting services (Plex, Home Assistant, self-hosted apps). May need to receive inbound connections from other zones; should have tightly controlled outbound.

Hardware Requirements

The router: A consumer router from most major brands (ASUS, TP-Link, Netgear consumer line) will not support this architecture. You need a router that supports:

• VLANs (802.1Q tagging)
• Per-VLAN firewall rules (not just a “guest network” with no control)
• DHCP per VLAN
• Ideally: stateful firewall, DNS per zone

The options:

Protectli FW4B or FW6 running OPNsense/pfSense: The most capable and flexible option. Protectli makes Intel-based mini PCs purpose-built to run open-source firewall software. OPNsense (or pfSense) provides enterprise-grade routing, VLAN support, firewall rules, IDS/IPS (Suricata integration), DNS filtering, and VPN — for a one-time hardware cost around $200-400 and no subscription. This is the right choice for anyone who wants real control.

Ubiquiti Dream Machine (UDM) or Dream Router: Consumer-to-prosumer line with excellent VLAN and firewall support, polished management interface, and integration with UniFi access points and switches. Higher cost than Protectli + OPNsense but more turnkey. The subscription model (for remote management features) is optional.

GL.iNet routers running OpenWrt: Capable devices running OpenWrt, which supports full VLAN and firewall configuration. More technical to configure than UniFi; less capable than a full OPNsense box. Good middle ground for price vs. capability.

Separate physical networks (no VLAN hardware required): If you’d rather not touch VLAN configuration at all, a spare consumer router dedicated entirely to lab traffic — with its own SSID and IP range, plugged into your main router’s WAN-side or double-NAT behind it — gets you real isolation with zero VLAN learning curve. It’s blunter than VLANs and less flexible, but getting data between lab and personal environments requires a deliberate action, which is itself a security benefit rather than a limitation.

The switch: For wired VLAN support, you need a managed switch that supports 802.1Q VLAN tagging. The Netgear GS308E (8-port, ~$30) or GS316E (16-port, ~$50) are the most cost-effective managed switches available. They support VLAN tagging and port assignment through a web interface. Sufficient for most home setups.

Access points: Wi-Fi APs need to support multiple SSIDs mapped to VLANs. UniFi APs do this natively. Consumer APs generally don’t. If you’re using a consumer AP/router combo, you’ll need to either replace it or configure it in bridge mode and rely on the upstream router for VLAN logic — which usually requires a more capable AP for the Wi-Fi side.

VLAN Design

A practical VLAN assignment for a home security lab:

| VLAN | Name | Subnet | Purpose |
|—|—|—|—|
| 10 | Management | 10.10.10.0/24 | Trusted workstations, security lab |
| 20 | Personal | 10.10.20.0/24 | Phones, family devices |
| 30 | IoT | 10.10.30.0/24 | Smart devices, cameras, printers |
| 40 | Guest | 10.10.40.0/24 | Visitor Wi-Fi |
| 50 | Servers | 10.10.50.0/24 | Plex, NAS, Home Assistant |
| 99 | Security Lab | 10.10.99.0/24 | VMs, CTF, research — isolated |

The Security Lab VLAN (99) is particularly important for security practitioners: it allows running vulnerable VMs, malware analysis, and red team tools without that traffic touching the rest of the network.

Firewall Rules

The rule architecture follows a default-deny philosophy: traffic between VLANs is blocked by default, with explicit allow rules for what should flow.

Management VLAN (10) — most privileged:

• Allow outbound to all VLANs (management needs to reach everything)
• Allow inbound from Servers VLAN (for admin access to hosted services)
• Block inbound from IoT, Guest, Personal (they can’t initiate to management)

Personal VLAN (20):

• Allow outbound to internet
• Allow outbound to Servers VLAN (for Plex, NAS access)
• Block outbound to Management, IoT (no reason for personal devices to reach IoT or management)
• Block all inbound from other VLANs

IoT VLAN (30) — the critical isolation:

• Allow outbound to internet only
• Block ALL inter-VLAN traffic — inbound and outbound to other internal VLANs
• Exception: specific allowed connections if a device genuinely needs to talk to Home Assistant on the Servers VLAN (create specific rules, not broad allow)

Guest VLAN (40):

• Allow outbound to internet only
• Block everything internal

Servers VLAN (50):

• Allow inbound from Personal and Management VLANs (for service access)
• Allow outbound to internet (for updates, remote access)
• Block inbound from IoT and Guest
• Block outbound to Management VLAN

Security Lab (99):

• Block ALL inter-VLAN traffic by default
• Allow internet access when needed (can be toggled)
• Complete isolation from production network

DNS Per Zone

DNS is a significant data source for network monitoring. Running a local resolver (Pi-hole, Adguard Home, or OPNsense’s built-in Unbound) per VLAN provides:

• Ad and tracker blocking per zone (stricter for IoT, looser for management)
• Query logging per zone for security monitoring
• The ability to block IoT devices from reaching their cloud services (useful for local-only IoT control)
• Visibility into what devices are doing at the DNS level

Pi-hole configuration for multi-VLAN: Run Pi-hole as a VM or container on the Servers VLAN (or directly on the OPNsense box). Configure each VLAN’s DHCP to serve that Pi-hole address as the DNS server. Block outbound DNS (UDP/TCP 53) from each VLAN except to the designated resolver — this prevents devices from bypassing your resolver by hardcoding 8.8.8.8.

Practical Implementation Steps

1. Acquire hardware: Protectli FW4B + Netgear GS308E is the recommended starting stack
2. Install OPNsense on the Protectli (straightforward installation, good documentation)
3. Configure VLANs on OPNsense and the managed switch — assign trunk ports (carrying multiple VLANs) and access ports (single VLAN per physical port)
4. Configure DHCP per VLAN in OPNsense
5. Write firewall rules — start with deny-all between VLANs, add specific allows
6. Configure Wi-Fi — if using UniFi APs, create SSIDs mapped to VLANs; if using a consumer AP, put it on the Personal VLAN and accept that wireless devices share that trust level
7. Move devices to appropriate VLANs — connect smart devices to IoT, workstations to Management, etc.
8. Set up logging — OPNsense’s firewall logging shows inter-VLAN connection attempts, which is itself useful threat visibility

The initial setup takes an afternoon. The ongoing maintenance is minimal — occasional rule adjustments as you add devices.

My Actual Setup and What I Got Wrong the First Time

I built my current home lab segmentation over two weekends about 18 months ago. Protectli FW4B running OPNsense, a Netgear GS308E on the wired side, and a couple of UniFi APs for wireless. The physical hardware took an hour to cable. The OPNsense configuration took most of a Saturday to get right — not because it’s hard, but because I kept finding devices I’d forgotten about that needed a home.

The mistake I made that cost me a few hours: I wrote the firewall rules correctly but forgot to block inter-VLAN DNS. IoT devices that had 8.8.8.8 hardcoded bypassed my Pi-hole entirely and I didn’t notice for a week until I looked at the DNS query logs and realized my smart TV was reaching out constantly to Google’s DNS while my Pi-hole showed zero queries from it. Lesson: block outbound UDP/TCP 53 from every VLAN to everywhere except your designated resolver. Don’t assume devices will use the DHCP-provided DNS.

The other thing I underestimated was how many things in my house assumed flat network access. My Roku couldn’t discover the Plex server on a different VLAN without an explicit firewall rule — I spent 45 minutes troubleshooting before remembering that was exactly what the segmentation was designed to prevent. Now I have a small allow-list for specific device-to-service connections across the Personal→Servers boundary, but everything else stays blocked.

What surprised me on the security visibility side: OPNsense’s firewall logs showed me that within 48 hours of completing the setup, I had a smart thermostat making outbound connection attempts to 23 distinct external IP addresses. That device had been on my network for two years on a flat network with access to everything. It’s now on the IoT VLAN talking to exactly one address — its manufacturer’s cloud endpoint. Everything else gets dropped and logged.

If you’re doing this for the first time, budget a full weekend, not an afternoon. The configuration is straightforward but the discovery process — finding all your devices, deciding where they belong, handling the “well, this device needs to talk to that one” exceptions — takes longer than the technical work.

One more piece of practical advice if you’ve already been running research tools on a flat network: do the segmentation work before your next active research session, not after. The cost of the configuration work is low compared to the cost of dealing with an incident caused by flat-network exposure while you already had something sensitive running.

What This Doesn’t Solve

Segmentation protects against lateral movement. It doesn’t protect against:

• Compromised devices on the same VLAN reaching each other (consider further microsegmentation or client isolation on Wi-Fi)
• Outbound connections from compromised IoT devices to attacker-controlled infrastructure (addressed partially by DNS filtering, addressed more completely by egress filtering rules)
• Physical access to the network
• Vulnerabilities in the router/firewall itself

For a security lab specifically, the Security Lab VLAN should be treated as completely untrusted from the rest of the network — no exceptions.

Two years ago I would have told you this was overkill for a home network. Then I watched a smart thermostat try to phone home to 23 different IPs in one weekend. It’s not overkill. It’s the same logic you’d apply at work, applied to the network your kids’ tablets and your tax documents both happen to share.

Sources:

1. pfSense documentation — https://docs.netgate.com/pfsense/en/latest/
2. OPNsense documentation — https://docs.opnsense.org/
3. SANS Institute, “Securing the Home Network” — https://www.sans.org/
4. Cisco VLAN best practices white paper — https://www.cisco.com/c/en/us/support/docs/lan-switching/vlan/10023-3.html