Home Network 2026

Early in my career, I built a home lab to learn skills I didn’t yet have. At first it was pretty elaborate. I’m talking a reverse proxy with my own 2FA IDP, Active Directory/WSUS/SCCM/PXE servers, secure remote access, Kubernetes clusters, and a bunch of other services that were honestly more than I needed. This complex design also increased management overhead and the overall attack surface. Thankfully it wasn’t wasted effort, as I learned a ton along the way.

These days it’s much more streamlined and purpose built. It’ll never be perfect and will keep evolving, but below is my current home network - a setup that matches my current risk‑versus‑convenience balance and personal interests. Hope you enjoy!

Design Principles

• Assume breach and least privilege
• Layered defense
• High-fidelity alerting
• Effective end-to-end network analysis
• Privacy first
• User convenience

Guest Network

When guests visit and use the Wi‑Fi, I like to keep them clearly separated from my own tinkering. That’s why I run a dedicated “router” outside the main home network, directly connected to the Internet Service Provider’s (ISP) optical network terminal (ONT). It also serves as a quick fallback to confirm whether the ISP is actually down or if one of my experiments caused an outage.

This router is just a standard off‑the‑shelf home router, not the one supplied by the ISP. If you don’t want a full‑blown home network like mine, I’d still recommend replacing the ISP‑provided router with your own. If your ISP won’t allow that, you can often put their device in bridge mode and place your own router behind it.

Why use your own router? ISPs typically retain remote access to their equipment, which puts them one hop away from devices on your network. With your own router, it essentially adds a firewall layer between the ISP and your devices (unless you open ports, enable UPnP, etc.). Even with the best intentions, a zero‑trust/assume‑breach mindset says we should limit that exposure. CISA reports PRC state‑sponsored actors have targeted telecom and ISP networks globally since at least 2021.¹ This additional layer imposes cost on potential attackers - which is the goal. Of course, that assumes you also lock down your own router, or this point doesn’t really hold.

Home Network

Within the home network, I split things into two main layers. The first is the management plane - the core networking gear that all traffic passes through. The second is the VLAN layer, which gives me fine‑grained segmentation for the many devices in the house.

Management Plane

Let’s start with the management plane. I use a device I call the “network controller” (a loose term for simplicity). It’s essentially a firewall/router/switch combo that manages the VLANs and routes traffic between them with finely tuned access‑control rules. It also handles tasks like pushing firmware updates to my managed switches and access points.

1. The key point is that all household traffic flows through this controller - both east‑west (internal) and north‑south (external). If a device talks to another device, regardless of VLAN, it passes through the controller. If a device talks to the internet, it also passes through the controller. This configuration allow for things like port mirroring and deep packet inspection to be a breeze for set up. From this vantage point I can see end‑to‑end traffic for any household device. Trying to investigate a security incident with gaps in telemetry? Not in this household!

2. If this appliance were compromised, an attacker could control traffic across the entire home network - which makes the controller a high‑value target. They could perform DNS poisoning, machine‑in‑the‑middle attacks on unencrypted protocols, reach services that weren’t directly exposed before, and more. Threat actors also like living on these appliances due to limited EDR/XDR coverage, so endpoint detection is generally weaker. For those reasons, only two devices in my network can talk directly to the management plane network and the controller’s web interface - which is likely the most practical compromise path.

3. VLANs are built around least privilege. For example, IoT devices can’t initiate connections to my phone, but my phone can initiate connections to IoT devices to preserve functionality. I’ll expand on this later below.

4. All household DNS are forced through the controller, which then enforces DNS‑over‑HTTPS to Cloudflare via Pi‑hole. This reduces DNS exfiltration (which often goes unnoticed) and makes devices using alternate DNS resolvers stand out as anomalies. Pi‑hole also provides network‑wide ad blocking. Ads can also be a malware vector, which this helps mitigate.

5. A bit controversial, but I also use geo-IP blocking to reject traffic from specific countries entirely. I haven’t found any legitimate need for household devices to reach those regions. If an edge case comes up, I can temporarily use my phone’s data plan. The net effect is added friction for attackers, who’d need at least part of their infrastructure to geolocate within allowed countries to interact with my home network.

6. I run a hypervisor directly on the management plane. It hosts multiple VMs, including the services that power my home SOC (more on that below). Each VM is pinned to its appropriate VLAN, and none can initiate connections back to the management plane. The management plane can, however, send telemetry-like network logs for those VMs to process.

There’s more I’ve done at the controller to harden the network, but the list is getting long - so I’ll stop here. I might have some future posts for a deeper dive on certain topics.

Virtual Local Area Networks (VLANs) Plane

Finally, here’s a simplified breakdown of the VLANs that make up most of the home network. They’re also built around least privilege: if traffic from VLAN1 to VLAN2 doesn’t make sense, it’s blocked. If only VLAN1 should initiate connections to VLAN2, that’s enforced as well. The benefit of fine‑grained access control is that anything outside those rules becomes highly anomalous, which is perfect for high‑fidelity alerting.

1. Less Secure Devices - for primary household devices (desktops, tablets, phones) used for everyday tasks like browsing, social media, and email. The exception is my desktop - it’s the only machine with enough VRAM, so I use it to run local LLMs. Local models offer better privacy and fewer restrictions, which is useful for deeper security research that cloud models may refuse to discuss. Since I sometimes analyze data from questionable sources, I run those models inside a VM for an extra layer of isolation. To make that work, I use GPU paravirtualization, which lets me allocate 0–100% of the GPU to one or more VMs.

   

2. Secure Devices - currently a single device, and it’s the only one allowed to directly access the management plane. It’s my admin‑only machine, kept clean and purpose‑built to minimize infection risk.

3. SOC - core detection and alerting stack for the home network. Graylog ingests logs from multiple telemetry sources (including the controller). Wazuh agents run on applicable endpoints and forward data to the Wazuh server for analysis. When Graylog or Wazuh matches an alert rule I’ve defined, it uses a local Signal API to notify my phone. I’m intentional about only alerting on truly anomalous or high‑value events. Alert fatigue from false positives is tiresome. This tailored approach is what makes a one‑person SOC like mine actually productive.

   

4. Smart Home Admin - every time I travel, I end up missing the automations I rely on, like lighting that shifts throughout the day to support my circadian rhythm. My smart home runs on three core systems: Hubitat, Philips Hue, and Lutron. That stack has delivered what I care about for years: fully offline operation, stability, and low‑latency control via Zigbee and Z‑Wave.

5. IoT - home to all of my IoT gear (TVs, printers, smart lights, washing machine, etc.) Most of these devices aren’t allowed to initiate connections to other VLANs because there’s no legitimate need. Some IoT telemetry can actually serve as an interesting defensive security signal for your home.

6. Research/Untrusted - I’ll sometimes drop a VM into this VLAN when I want it completely cut off from the internet and the rest of the home network when analyzing sketchy binaries. I accept that truly advanced malware could still escape a VM; at that point, fair play! I just hope I’d capture the exploit along the way.

7. Game Consoles - Online gaming can have unusual risks, even when uPNP is disabled. For example, did you know about a remote code execution (RCE) exploit against Animal Crossing: New Leaf on the 3DS against online users?²

Summary

Just to be clear, this home network is overkill, but it’s fun (to me). What began as a simple lab to learn fundamentals early in my career evolved into a worthy, security‑focused home network that would hit ‘four nines’ of availability if my ISP and electricity service were commercial grade. The path wasn’t always straight, detours turned into lessons, but the extra effort has made me more impactful in every professional role since.

If you’re early in your security career, I’d encourage you to build a lab and apply what you learn - even outside your primary domain. That’s especially important if your day job doesn’t give you enough opportunities to grow. The tech stack changes constantly, and your personal technical debt grows with it. If you don’t prioritize continuous learning, you’ll eventually fall behind. This is the way of security.