Segmenting a Flat Homelab Network, One Phase at a Time

Every device on my homelab network used to share one flat zone. Personal laptops, phones, IoT devices, and the management plane for Authentik, Semaphore, and Komodo all sat on the same broadcast domain with no isolation between them. That's fine for a small setup, but it means a compromised smart plug and a compromised identity provider are equally reachable from the same starting point. This project is the ongoing work to fix that, one deliberately small phase at a time rather than one big flag-day cutover.

Why Go Slow#

The original question that kicked this off was actually about something else entirely: whether Traefik needed to move into a dedicated DMZ zone. Working through that with a couple of specialist reviews turned up a more useful reframing. Traefik has no direct inbound WAN exposure at all, since everything reaches it through an outbound Cloudflare Tunnel, so a DMZ move for Traefik specifically wasn't the highest-value change available. The bigger risk was that personal Wi-Fi devices and the entire management and identity plane shared one flat zone with nothing between them.

From there the plan became a phased rollout: seven phases, each independently revertible, each requiring its own explicit go-ahead before executing. Move slowly, verify each step live, and don't bundle unrelated changes into the same window.

What's Live So Far#

Three phases are in production:

• Phase 0: baseline audit of every host's IP across every config file that referenced it, plus tightening the default-to-DMZ firewall rule while the DMZ zone itself was still empty.
• Phase 1: moved IoT devices into their own dedicated firewall zone. Zero host IP changes required, just a zone reassignment.
• Phase 2: moved personal Wi-Fi devices onto their own VLAN and zone, isolated from the management and identity plane. This was flagged by both specialist reviews as the single highest risk-reduction move for the effort involved, and it's the phase that touches the most real day-to-day traffic.

Three more phases are planned but not yet started: standing up proper Management-zone rules and dry-run migrating the lowest-blast-radius host first, migrating the rest of the management tier in a specific order chosen so monitoring is proven working across zones before the identity provider itself moves, and finally standing up the DMZ zone rules for the app tier.

The Side Effects That Came With Phase 2#

Rolling out real firewall zones on a live network doesn't come free, and this rollout surfaced three separate side effects, none of which were the actual segmentation logic itself failing.

Logging overhead. Nearly every new zone policy had logging turned on by default, and on a gateway that was otherwise sitting comfortably idle, per-packet logging across nine new rules pushed CPU usage up meaningfully. Turning logging off on the rules that didn't need it dropped utilization back down substantially. New rules now default to logging off unless there's a specific reason to want the audit trail.

Intra-zone traffic silently broken. The predefined "block all traffic" rule that's supposed to isolate the Wi-Fi zone from Management and DMZ was written broadly enough that it also blocked device-to-device traffic between two personal devices on the same zone, breaking things like AirPlay, HomeKit, and printer discovery that never should have been affected. The fix was a custom allow rule for intra-zone Wi-Fi traffic, inserted ahead of the predefined catch-all in evaluation order, confirmed working with a direct ping test to a device on the same zone.

Wireless flapping that looked network-related but wasn't. A separate complaint came in about VPN connections dropping and reconnecting on a laggy pattern, which looked at first like it might be a side effect of the new zone rules adding processing overhead. It wasn't. The actual mechanism, found by reading the affected laptop's own kernel logs during a live drop, was a client-side radio issue: an 802.11k neighbor-report mismatch was causing the laptop to locally deauthenticate and immediately reconnect to the same access point every few minutes, independent of anything the gateway itself was doing. Root cause traced back to the access points' radio state getting left in an inconsistent condition during the SSID rebind that was part of the original rollout, since forcing every client to reassociate at once is exactly the kind of event that can leave 802.11k neighbor state stale. Rebooting both access points cleared it completely, confirmed by over half an hour of stability with no VPN connected, followed by a stable VPN session afterward.

Along the way I also disabled a dynamic DNS client that had been force-updating a record every couple of minutes for hours on end, a leftover from before the Cloudflare Tunnel existed to handle all external routing, and confirmed it had nothing to do with any of the actual instability being investigated.

A Useful Discovery: Config Changes Cause Their Own Disruption#

One of the more interesting findings from digging through gateway logs directly was that the platform runs a full configuration re-migration cycle, touching the entire config tree rather than just whatever actually changed, on every single write, whether that write comes from the UI or the API. Watching the logs during active rule editing showed clusters of these full reprovision cycles within the space of a minute. Watching the same logs for an extended window afterward, with zero further edits, showed none at all. That's a reasonable explanation for why the original rollout weekend felt disruptive in the moment: building out several phases of rules in one sitting means many rapid successive writes, each briefly interrupting DHCP and other services, without any of it pointing to a standing defect in the configuration itself.

Where It's Headed#

Phases 3 through 6 are scoped and documented but intentionally not started yet. Each one gets the same treatment the first three did: a live check of current zone and policy state before touching anything (an early version of this project's own documentation had already gone stale once, claiming the rollout was paused when it had actually shipped), a plan for what specifically moves and in what order, and a verification pass before calling it done.

For the host-level counterpart to this project, see Locking Down 19 Wide-Open Container Ports Across the Homelab.