I Got Lazy With My Home Network—So I Rebuilt It Properly (1/3)

A few years ago I downsized from a full-size rack to... just my ISP router. Practical? Sure. Boring? Absolutely.

Now I'm getting back into homelabbing, this time with mini PCs and SBCs running a multi-node Kubernetes cluster to sharpen my skills. But before I could spin up workloads, I needed to rebuild my home network with proper segmentation, dual-site connectivity to a secondary location (my backup lab location), and secure VPN access when traveling.

This 3-part series documents that rebuild:

Part 1 (this post) - Got Lazy With My Home Network—So I Rebuilt It Properly

Part 2 - Turning One LAN Into Five Networks: VLANs + Wi‑Fi Segmentation at Home

Part 3 - Making It Two Locations: A Routed WireGuard Tunnel Between My Labs

I tore down my old "it mostly works" home network and rebuilt it as a small, intentional platform: segmented VLANs, predictable addressing, and a path to a dual‑site homelab connected by a site‑to‑site VPN.

This post sets the context, the goals, the hardware, and the VLAN/IP plan, so Part 2 can focus on implementation without constantly stopping to explain why the design looks the way it does.

Why I tore down and rebuilt my home network

Back in the days, I had my home network in full control, this was the pre-IoT era. Every room had network jacks, a few access points spread around the house, and servers running inside a 42U rack cabinet with network gear blinking all night, all centralized in my office.

But life happens. I moved to a smaller house with no space for a full rack. Most of the equipment was donated; only a couple of computers and the cabinet itself remain, stored at my parents' house, waiting for a new life.

Suddenly I was using just a laptop. No more servers. The smart home "devices" were just lightbulbs and power plugs, all relying on the ISP router's WiFi (which, to be fair, isn't terrible). I was traveling constantly, focused on work, with no time left for hobbies—so I never really missed the gear I used to manage.

But slowly, the homelab interest started reclaiming its space. A Raspberry Pi here, a VPN gateway there, a NUC box... and the pitiful sight of an old Mac Mini gathering dust for years, begging to be repurposed. That's when I saw the potential: mini PCs as a Kubernetes cluster—low power consumption, minimal space.

Then a new concern emerged: my home network was a mess. I had no sense of what was connected, and important concepts like security boundaries and reliability were nowhere to be found. My pragmatic "mostly works" approach had to stop. That's why I tore down everything and rebuilt my home network from scratch.

Requirements for the "new" homelab era

The rebuild was driven by two practical pain points:

Isolation and reliability

One misbehaving device shouldn't impact everything else, and untrusted devices shouldn't reach critical infrastructure.

When everything shares a single broadcast domain, a chatty IoT gadget or a device stuck in a DHCP loop can degrade performance for the entire household. Worse, many consumer IoT devices have weak or outdated firmware, and guest devices are inherently untrusted—without network segmentation, a compromised device on the same flat LAN can potentially reach router admin panels, NAS management interfaces, or lab VMs.

Segmentation contains both reliability issues and security threats to their own VLAN, so a malfunctioning (or compromised) smart bulb doesn't slow down video calls, access management interfaces, or interfere with homelab services.

Future expansion

I wanted a foundation that could later support a Kubernetes‑style lab without re‑addressing the entire house.

When you start planning multi-node clusters, persistent storage backends, or service meshes, clean subnet boundaries and predictable addressing save hours of debugging routing and firewall rules.

Getting the VLAN and IP scheme right now means I won't have to renumber everything when I scale from a single mini PC to a three-node cluster spanning two sites.

The concrete requirements

These pain points translated into a specific set of technical requirements:

• VLANs for segmentation – separate networks for family, IoT, homelab, and management

• Multiple SSIDs – different Wi-Fi networks mapping to different VLANs, so guests and IoT devices don't share the same wireless space as trusted devices

• Site-to-site VPN – connecting my home network to a secondary location so both labs can communicate as if they were on the same LAN

• Point-to-site VPN – remote access when traveling, letting me reach any device on any VLAN from anywhere without fumbling with port forwards or exposing services to the internet

• Seamless admin access – as the network admin, I should be able to connect from anywhere (home, secondary location, or traveling) to every device across all VLANs without extra steps

The goal was simple: strong boundaries for everyone else, zero friction for me.

Hardware inventory and high-level topology

This rebuild uses prosumer gear that's flexible enough for a homelab but doesn't require enterprise-grade budgets or complexity. Most of it I already had; a few pieces (like the Omada AP and Netgear managed switch) I added specifically for VLAN capabilities.

Network gear

At my house (Site A):

• ISP router – provided by my ISP, running in "DMZ mode" to pass traffic to the Brume 2

• GL.iNet Brume 2 – the heart of the network, running OpenWrt with VLAN interfaces and acting as the WireGuard VPN server

• Netgear GS308Ev4 – 8-port managed switch handling VLAN trunking between the Brume 2, access points, and wired devices

• TP-Link Omada EAP610 – Wi-Fi 6 access point with per-SSID VLAN tagging, broadcasting separate networks for family, IoT, and homelab

• TP-Link 8-port gigabit switch – unmanaged switch extending wired connections to the second floor (receives a single VLAN from the Netgear trunk)

At a secondary location (Site B):

• ISP router – their ISP-provided router

• Xiaomi Mi Router 4A Gigabit Edition – flashed with OpenWrt, acting as the WireGuard VPN client and routing the homelab VLAN at Site B

• TP-Link 5-port gigabit switch – unmanaged switch connecting the Site B homelab devices

For travel:

• GL.iNet Beryl AX – travel router that can connect to the site-to-site VPN as a point-to-site client, giving me seamless access to both sites from anywhere

Devices to connect

Active devices:

• MacBook (my daily driver)

• Lenovo ThinkPad (work machine)

• Raspberry Pi 2 (small services, monitoring)

• N150 NUC box (testing Kubernetes workloads)

• Family devices: desktop PCs, laptops, smartphones, smart TVs

• IoT devices: a bunch of smart lightbulbs and power plugs

Old devices waiting to be repurposed as homelab nodes:

• 5× HP G3 mini PCs (the future Kubernetes cluster)

• Mac Mini 2010 (lightweight services or storage node)

• MacBook 2008 (maybe a dedicated build server or CI/CD runner)

• Desktop PC with i7-7700 and 8GB RAM (heavier workloads or a hypervisor)

These old devices are why the dual-site setup matters: some will stay at my house, some will live at my parents' house, and the site-to-site VPN will let them connect to each other when need without extra effort.

High-level topology

Site A (my house):

ISP Router (DMZ)
     ↓ 
GL.iNet Brume 2 (OpenWrt, VLANs, WireGuard server)
     ↓ 
Netgear GS308Ev4 (managed switch, VLAN trunks)
     ├─→ TP-Link Omada EAP610 (Wi-Fi, per-SSID VLANs) → all wireless devices
     ├─→ TP-Link 8-port switch (2nd floor, access mode) → wired desktop PCs
     └─→ Raspberry Pi 2, NUC box, future HP mini PCs (direct VLAN access)

Site B (secondary location):

ISP Router
     ↓ 
Xiaomi Router 4A (OpenWrt, WireGuard client)
     ↓ 
TP-Link 5-port switch
     └─→ Old MacBook, Mac Mini, desktop PC (homelab VLAN)

Travel setup:

GL.iNet Beryl AX (point-to-site VPN client)
     ↓ 
Connects to Brume 2 WireGuard server
     ↓ 
Access to all VLANs at both Site A and Site B

The Brume 2 acts as the central hub: it terminates the WireGuard tunnel from Site B, routes between VLANs at Site A, and allows point-to-site VPN clients (like the Beryl AX when traveling or my laptop) to reach everything. The Xiaomi at Site B initiates and keeps the tunnel alive, since it's behind NAT with no public IP or port forwarding.

Designing a VLAN and IP scheme that will scale

Before touching any configs, I mapped out the VLAN IDs and IP ranges with three goals: make them easy to recognize, avoid collisions between sites, and leave room for growth.

VLAN mapping

Address space design

I decided to use Class A private IP range (10.0.0.0/8) with a structured approach: the second octet represents the site, and the third octet represents the VLAN.

For example, 10.11.30.200:

• 11 identifies the site (in this case, my house)

• 30 identifies the VLAN (in this case, the homelab VLAN)

• 200 is the specific host within that network

This structure makes it instantly obvious where a device lives just by looking at its IP address. When I add the second site later, it will use 10.22.x.x, making cross-site routing and firewall rules straightforward—no subnet overlap, no NAT headaches, and clear visual distinction between locations.

Room for growth

Each VLAN gets a full /24 (254 usable IPs), which is overkill for now but leaves room to grow. If the Kubernetes cluster scales to 10+ nodes across both sites, or if I add more IoT devices or guest networks, I won't need to re-subnet anything—I just add more devices to the existing VLANs.

Management isolation

VLAN 10 is reserved for network infrastructure (router, switch, AP) and nothing else. Family devices, IoT gadgets, and even homelab workloads can't directly reach management interfaces unless firewall rules explicitly allow it. This means a compromised IoT device or a rogue VM can't start poking at the router's admin panel.

Wrapping up Part 1

That's the foundation: the story of why I rebuilt, the requirements that drove the design, the hardware doing the work, and the VLAN/IP scheme that ties it all together.

In Part 2, I'll show you how to implement this at Site A: configuring VLAN interfaces on the Brume 2, setting up VLAN trunking and access ports on the Netgear switch, mapping SSIDs to VLANs on the Omada AP, and writing the firewall rules that enforce isolation between networks.

In Part 3, we'll extend this to Site B, configure the site-to-site WireGuard tunnel, and set up point-to-site VPN access so everything works seamlessly whether you're at home, at the secondary site, or halfway around the world.