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

Image: home network router switch firewall setup rack

—

Most home networks are flat — every device, from the laptop with your financial accounts to the cheap smart thermostat running three-year-old firmware, sits on the same network segment with unrestricted lateral access to everything else. This is fine until it isn’t: a compromised IoT device can reach your NAS, your media server can be pivoted to access your work laptop, and a vulnerable printer can become a pivot point for everything on the network.

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.

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.

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 (simple 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.

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.

A flat home network is a single security boundary protecting everything. A segmented home network is multiple boundaries — and a compromised smart lightbulb stays on the IoT VLAN, not pivoting into your financial accounts. The architecture isn’t complicated; the hardware is inexpensive; and the improvement in your actual security posture is significant.