DEV Community: Nuno Amaral

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

Nuno Amaral — Wed, 18 Feb 2026 16:40:45 +0000

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 - 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 (this post) - Making It Two Locations: A Routed WireGuard Tunnel Between My Labs

Recap and what Part 3 covers

In Part 1, I explained why I tore down my “it mostly works” home network and rebuilt it with clear boundaries: VLAN segmentation, predictable addressing, and a design that could eventually stretch across two locations. In Part 2, I implemented that design at Site A (my house): the GL.iNet Brume 2 runs OpenWrt with VLAN interfaces, the Netgear managed switch carries those VLANs end-to-end, and the Omada AP maps SSIDs to VLAN IDs so Wi‑Fi clients land in the right networks.

Part 3 is where the lab becomes truly dual-site. I turn my parents’ house into “Site B” using a Xiaomi router flashed with OpenWrt, then connect Site A and Site B using a routed site‑to‑site WireGuard tunnel (Brume 2 as the hub/server, Xiaomi as the spoke/client). From there, the focus is on the practical glue that makes this usable in real life: which subnets are routed over the tunnel, what firewall forwardings are allowed (and which are explicitly not), and how I can still reach both sites securely when traveling without poking holes in the segmentation work from Part 2.

Why the Xiaomi, and how the tunnel starts

The router I used at Site B (my parents’ house) started life as a basic Wi‑Fi extender, but it turned out to be the ideal “cheap lab edge” once I realized it could be flashed to OpenWrt. With OpenWrt on the Xiaomi, I can run WireGuard and have it establish a site‑to‑site tunnel back to my Site A router (the GL.iNet Brume 2), which turns that second location into a routable extension of my homelab instead of an isolated island.

On the Site A side, I kept the initial WireGuard setup intentionally simple by using the Brume 2’s native GL.iNet UI rather than building everything manually in LuCI. I chose WireGuard because it’s lightweight and a good performance fit for small routers, and I configured the VPN server with a dedicated tunnel IP—10.11.255.1 in my case—so the VPN has a clean “transit” network that stays separate from my LAN subnets.

To bootstrap the site‑to‑site link, I created a new WireGuard client/profile in the GL.iNet UI, and the Brume 2 generated a ready-to-import configuration file for the other end. That file is the starting point on the Xiaomi side: import it, bring up the tunnel, and then move from “the interface is up” to “the sites can actually route to each other” by aligning AllowedIPs, routes, and firewall forwardings in the next sections.

Site B: Xiaomi client setup (WireGuard-focused)

Site A is already prepared to accept a site‑to‑site peer, so the next job is turning the Xiaomi at Site B into a clean “WireGuard client that routes a subnet” device. In this post I’m deliberately not going deep into the Site B homelab itself; the point is getting a stable tunnel that can carry traffic between a Site B lab subnet (10.22.30.0/24 in the article) and the networks at Site A.

Flashing the Xiaomi to OpenWrt (high level)

The Xiaomi firmware flash is a one-time prerequisite, and I’m not going to replicate the steps here because they vary by model and hardware revision. The key takeaway is that once the router is running OpenWrt (and you can access LuCI), it stops being “just an extender” and becomes a proper edge router that can run a routed WireGuard tunnel.

Installing WireGuard support on OpenWrt

On a fresh OpenWrt install, WireGuard typically isn’t fully available in the UI until you install the kernel module and userland tools (and optionally the LuCI protocol helper). On the Xiaomi I installed the WireGuard packages first and rebooted, so the WireGuard protocol shows up cleanly when creating interfaces and peers.

Example (SSH):

opkg update
opkg install wireguard-tools kmod-wireguard luci-proto-wireguard reboot

A practical pitfall here is storage: some routers have limited free flash, so it’s worth checking before installing extra packages.

Importing the profile and bringing up the tunnel

With the Site A configuration exported and ready, the Xiaomi side becomes mostly an OpenWrt exercise: install WireGuard support, create a WireGuard interface, and then copy/import the peer settings so the Xiaomi knows how to reach the Brume 2. In my case I ended up with an interface named wg_site_a carrying the Xiaomi’s tunnel address, and a peer entry pointing at the Brume 2 endpoint with PersistentKeepalive enabled, since Site B sits behind NAT.

The detail that turns this from “remote access” into “site‑to‑site routing” is AllowedIPs plus route creation on the WireGuard client.

On the Xiaomi, with route_allowed_ips enabled, OpenWrt automatically installs routes for the peer’s AllowedIPs, so traffic destined for Site A subnets is forwarded into the WireGuard interface instead of the regular WAN.[
Also, remember AllowedIPs isn’t just a routing convenience: it’s WireGuard’s traffic selector—outbound destinations matching AllowedIPs go to that peer, and inbound packets from that peer are only accepted if their source IPs are within that peer’s AllowedIPs.[

Minimal firewall glue (so it routes, but stays contained)

To keep Site B intentionally small and safe, I didn’t open the tunnel to every local network on the Xiaomi. Instead, I put the WireGuard interface into its own firewall zone and allowed forwarding only between that zone and my “lab” interface at Site B (the one I use for homelab devices), which gives me bidirectional routing between the two labs without making the entire Site B router a wide-open bridge into everything.

Brume 2: firewall forwardings for site‑to‑site routing

At this point the tunnel can be “up” and still be useless if the firewall won’t let traffic cross it, so on the Brume 2 my work was almost entirely firewall plumbing. I didn’t create any WireGuard devices or interfaces manually on the Brume 2: configuring the WireGuard server in the GL.iNet UI took care of the server-side interface and peer scaffolding for me.

Treat the tunnel as its own zone

On the Brume 2 I keep the WireGuard server side grouped into its own firewall zone (I use wgserver), so it’s easy to reason about paths like “Management VLAN → VPN” or “Homelab VLAN → VPN.” This keeps the mental model clean: VLAN zones are internal networks, wgserver is the inter-site transit, and forwardings are the only doors between them.

Allow only the VLANs that should reach Site B

To keep the site‑to‑site link useful without flattening my segmentation, I only allow the tunnel to talk to two VLANs at Site A: VLAN 10 (management) and VLAN 30 (homelab). Concretely, that means adding forwardings in both directions:

wgserver → vlan10, vlan10 → wgserver, wgserver → vlan30, and vlan30 → wgserver.

The practical effect is exactly what I wanted: management clients in VLAN 10 can administer across sites, and lab workloads in VLAN 30 can reach lab services at Site B, while the other VLANs remain isolated from the tunnel by default.

Common pitfall: “handshake works, but nothing routes”

If you ever see a healthy WireGuard handshake but can’t ping anything across sites, the firewall forwardings are one of the first things to double-check. With OpenWrt’s zone model, “the interface exists” doesn’t imply “traffic is permitted”—those inter-zone forwardings are the difference between a connected tunnel and a routed inter-site network.

Travel access: two “road‑warrior” profiles on top of the site‑to‑site VPN

With the site‑to‑site tunnel in place, the last piece I wanted was the ability to reach everything when I’m away from home—without exposing any management services to the public internet. Instead of changing the site‑to‑site design, I simply added two more WireGuard profiles on the Brume 2: one for my GL.iNet Beryl AX travel router, and one for my daily-driver laptop for the cases where I’m not using the travel router.

Why two profiles

The Beryl AX profile gives me a “VPN bubble” I can carry anywhere, and in my case its WAN comes from USB phone tethering (not hotel Wi‑Fi). That means I plug my phone into the Beryl, the Beryl treats the phone as its upstream internet, and then it brings up WireGuard back to the Brume 2—anything behind the Beryl can use the VPN without needing individual client configs.

The laptop profile is the fallback for those times I’m traveling light, or when I only need access from a single device. It’s also useful at home when I want to join via VPN from the laptop directly instead of routing through the travel router.

What these profiles need to reach

These travel profiles are classic road‑warrior configs: they should be able to reach my trusted admin and lab networks at Site A, and they should also include the Site B lab subnet so I can manage the backup location through the existing site‑to‑site tunnel. The key idea is that the Brume 2 remains the hub: once a road‑warrior client is connected to it, the Brume 2 can route the client into the allowed Site A VLANs (per firewall policy) and onward to Site B across the site‑to‑site link.

Keeping access intentional (not “everything everywhere”)

I treat these travel profiles as privileged access, so I keep their reach aligned with my segmentation model: the goal is seamless admin and homelab access, not letting an untrusted travel network have a path into every VLAN. In practice, that means the travel profiles are designed to reach only the VLANs and subnets I explicitly manage (plus the Site B lab subnet), while everything else stays isolated unless I make a conscious decision to open it.

Lessons learned and future Kubernetes plans

This rebuild delivered what I wanted at the start: a network with strong segmentation at Site A, a real routed extension at Site B, and secure remote access when I’m away. The best part is that it’s predictable now—predictable addressing, predictable boundaries, and no more “I wonder what network this device is on.”

What worked better than my old “mostly works” setup

The biggest win was making the firewall the source of truth for segmentation. VLANs create the separate networks, but the forwardings between zones are what make (or break) isolation, so keeping those paths intentional gave me a clean “default deny between VLANs” posture while still allowing my management VLAN to reach what it needs.

The second win was treating the VPN the same way: not as a magic private backdoor, but as another zone with explicit forwardings. On the Brume 2 I leaned on the GL.iNet UI to handle the WireGuard server setup, and then I focused my effort where it matters: which VLANs are allowed to forward into the tunnel (and back).

Practical lessons I’m keeping for next time

Simple scaling beats cleverness. The “site is the second octet, VLAN is the third octet” scheme makes it simple to identify where an IP belongs (which site, which network) when you’re looking at routes, firewall rules, or client addresses.

Where Kubernetes fits next

This network redesign was always in service of the next phase: running a small multi-node Kubernetes cluster on low-power machines without turning the network into the bottleneck. I’ve got a pile of hardware waiting for that job—HP G3 mini PCs, a Raspberry Pi, and a few other older systems—and while I plan to run separate clusters per site, having the option to connect things across sites later (cleanly, without renumbering) is a nice capability to have.

The immediate plan is to start simple: get a cluster running on the Site A homelab VLAN, then treat Site B as its own independent lab environment. The nice thing is that the “network foundation” work is done—adding nodes should now feel like plugging machines into the right VLAN (or subnet) and letting routing and VPN do their job.

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

Nuno Amaral — Wed, 18 Feb 2026 16:17:57 +0000

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 - Got Lazy With My Home Network—So I Rebuilt It Properly

Part 2 (this post) - 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

Recap (from Part 1)

Part 1 set the "why" and the blueprint: rebuild the home network with strong VLAN isolation, predictable addressing, and a path to a dual-site homelab connected over VPN.

It also locked in the roles and topology: the GL.iNet Brume 2 (OpenWrt) is the Site A core router, with VLANs trunked through a managed Netgear switch and extended to an Omada AP where SSIDs map to VLAN IDs.

Finally, it defined the VLAN/IP scheme (10.11.VLANVLAN.0/24 at Site A) so Part 2 can focus purely on implementation without redesigning along the way.

Brume 2 (OpenWrt) as the core router — my take on the gear

I've had the Brume 2 for a while as a "VPN gateway" for otherwise non-managed devices (think streaming boxes), and that's where I learned that GL.iNet gear is genuinely excellent: solid build quality and a UI that's easy to live with, while still being OpenWrt underneath. That "easy mode" has limits though: the GL.iNet UI doesn't really cover advanced segmentation like VLANs, so the trick is to treat their UI as a convenience layer and switch to LuCI (or SSH) whenever you outgrow it.

When I connected the Brume 2 behind my ISP router, I found I couldn't use bridge mode anymore, so I went with the pragmatic approach: put the Brume 2 in the ISP router's DMZ to get it working quickly and keep the WAN side simple. DMZ on ISP routers is usually ‘forward all inbound to this host’ (not a true isolated network), so WAN-side admin services must remain closed; use VPN for remote management.

For VLAN segmentation on OpenWrt, there are two steps: first you create 802.1Q devices, then you create one interface per VLAN on top of those devices.

On the Brume 2, the LAN side is a bridge device (in my case named br-lan). The trick is to reuse that name and append the VLAN ID as a suffix when creating the new devices, for example:

br-lan.10 for VLAN 10 (management)
br-lan.20 for VLAN 20 (family)
br-lan.30 for VLAN 30 (homelab)
br-lan.40 for VLAN 40 (IoT)
br-lan.50 for VLAN 50 (entertainment)

After creating the VLAN devices, create one interface per VLAN (e.g., mgmt, family, lab, iot, entertainment) and attach it to the matching device (br-lan.10, br-lan.20, etc.). Set the interface protocol to Static address, assign the IPv4 address and subnet mask (for VLAN 30 / 10.11.30.0/24 I used 10.11.30.1/24), enable the DHCP server on that interface, and (optionally) create and assign a dedicated firewall zone right away (e.g., vlan30)—we’ll tighten the rules for those zones later.

This is straightforward in LuCI, but there's one setting that's easy to miss and can save you from weird behavior later: "Force DHCP on this network even if another server is detected."

One more gotcha: once you configure VLANs this way, the GL.iNet UI doesn't "understand" the VLAN interfaces—so the device list in their beautiful UI may look empty or incomplete, even while everything is working correctly at the OpenWrt level.

OpenWrt firewall: zones and isolation rules

VLANs create separate networks, but the firewall is what decides which of those networks can talk to each other (and to the internet). OpenWrt does this with firewall zones (groups of interfaces) and forwardings (allowed paths between zones).

Create (or confirm) one zone per VLAN

If you didn’t create a firewall zone while creating the VLAN interfaces, do it now: create one zone per VLAN (for example vlan10, vlan20, vlan30, vlan40, vlan50) and set the covered networks to the matching VLAN interface. This keeps the rest of the rules easy to understand because each zone maps 1:1 to a VLAN.

My baseline zone settings

For each VLAN zone, I kept the defaults permissive to avoid breaking basic connectivity (gateway, DHCP, DNS):

INPUT: ACCEPT
OUTPUT: ACCEPT
FORWARD: ACCEPT

This ensures clients can talk to the router on their VLAN and get online without needing a pile of extra “allow DHCP/DNS” rules.

Isolation is enforced by forwardings

The real segmentation happens in the zone forwarding section:

For “regular” VLANs (family, homelab, IoT, entertainment), I only allow forwarding to wan so they can reach the internet but not other internal VLANs.
For my admin VLAN (VLAN 10), I allow forwarding to wan and to the other VLAN zones so my laptop can manage devices across the whole network (e.g., vlan10 → vlan20, vlan10 → vlan30, vlan10 → vlan40, vlan10 → vlan50).

That gives me the best of both worlds: strong isolation by default, but full access from the one VLAN I trust.

Common pitfalls

Missing a vlanX → wan forwarding: clients get an IP but have no internet access.
Accidentally adding vlan30 → vlan10 (or vlan30 → any other internal VLAN): you effectively undo segmentation.
Putting untrusted devices into VLAN 10: VLAN 10 becomes “keys to the kingdom” once it can forward everywhere.

Netgear switch: trunks, access ports, and PVIDs (GS308Ev4)

VLAN tagging on a managed switch can feel confusing at first, but it becomes pretty clear once you internalize two ideas: access ports carry one VLAN (usually untagged), and trunk ports carry multiple VLANs (usually tagged). A short YouTube explanation that helped me a lot is here: https://youtu.be/C81pyQaJgj8

On my Netgear switch, I configured two trunk ports:

Port 8 → uplink to the Brume 2 (router-on-a-stick)
Port 7 → uplink to the Omada EAP610 access point (so multiple SSIDs can map to different VLANs)

Then I configured ports 1–5 as “one VLAN per port” access ports. Port 6 is disabled and kept available for future expansion.

My port layout

Port	Connected to	Type	Untagged VLAN (PVID)	Tagged VLANs allowed
1	Laptop (VLAN 10)	Access	10	None
2	Umng. Switch (VLAN 20)	Access	20	None
3	Rspb. Pi (VLAN 30)	Access	30	None
4	IoT server (VLAN 40)	Access	40	None
5	Smart TV (VLAN 50)	Access	50	None
6	(Disabled)	—	—	—
7	Omada EAP610	Trunk	1	10, 20, 30, 40, 50
8	Brume 2	Trunk	1	10, 20, 30, 40, 50

Why trunk PVID = VLAN 1

The switch requires a PVID on each port, and the PVID is simply the VLAN where untagged inbound frames are classified.

By setting the trunk PVID (native VLAN) to VLAN 1, any accidental untagged traffic on ports 7 or 8 won’t land in my management VLAN; all the VLANs I actually use (10/20/30/40/50) are carried across those trunks as tagged VLANs end‑to‑end.

Omada Wi‑Fi: mapping SSIDs to VLANs (EAP610)

The only equipment I bought specifically for this redesign was the TP‑Link Omada EAP610. I needed an access point that supports multiple SSIDs with per‑SSID VLAN tagging, and this was the only suitable model available locally—fortunately, it turned out to be a great fit: easy to manage and with enough coverage for my whole house.

A day after buying it, I also picked up a dedicated PoE injector so I could wall-mount the AP with just a single Ethernet cable going to it (data + power).

One SSID per VLAN (simple and predictable)

My approach was intentionally simple: I created one Wi‑Fi SSID per VLAN and assigned the corresponding VLAN ID in Omada. This keeps Wi‑Fi segmentation aligned with the VLAN design from the wired network, and makes it obvious which devices belong where.

Band choices: 2.4 GHz for IoT, 5 GHz for everything else

For the IoT VLAN, I used 2.4 GHz to maximize compatibility with older/cheaper devices. For the remaining VLAN-backed SSIDs, I used 5 GHz for better performance and less interference.

Common pitfalls

SSID VLAN tagging won’t work if the AP uplink isn’t a trunk carrying those VLANs (tagged) back to the switch/router.
In Omada, double-check you’re setting the VLAN ID on the SSID itself (and not in a different “override” place), otherwise clients may join but end up in the wrong subnet.

Final checks

At this point, the segmented network at Site A is fully built end-to-end: the Brume 2 routes and serves DHCP per VLAN, the Netgear switch carries those VLANs over trunks and breaks them out to access ports, and the Omada AP maps Wi‑Fi clients into the right VLANs.

Validation checklist

Before calling Part 2 “done”, I ran a quick set of tests from at least one device in each VLAN:

Verify IP addressing: the client gets an address from the expected subnet (10.11.VLANVLAN.0/24) and uses the router’s .1 address as its gateway.
Verify internet access: the client can reach the internet (DNS + outbound traffic works).
Verify isolation: from non-admin VLANs, you should not be able to reach devices on other internal VLANs; from the admin VLAN (VLAN 10 in my case), you should be able to reach the other VLANs for management.
Verify Wi‑Fi VLAN tagging: connect to each Wi‑Fi network and confirm it lands in the correct VLAN/subnet (this catches trunk/tagging mistakes fast).

Security notes (kept simple on purpose)

This setup doesn’t have a “broken” security flaw, but it does have a couple of soft spots that are worth calling out. I’m aware of them, and I’m comfortable with the trade-offs for a home lab where I control physical access and keep the admin side tightly held.

FORWARD=ACCEPT everywhere: with INPUT/OUTPUT/FORWARD = ACCEPT on every VLAN zone, the firewall isn’t enforcing least-privilege inside a zone. In OpenWrt’s zone model, segmentation is primarily enforced by inter‑zone forwardings (for example vlan30 → wan, or vlan10 → vlan30), because those forwardings are the explicit “doors” between zones. This baseline is acceptable for a homelab only if you keep the forwardings list minimal (typically vlanX → wan for internet, and only intentional admin paths like vlan10 → vlan30), and avoid creating any accidental inter‑VLAN forwardings that would flatten your isolation.
VLAN 10 is powerful: the risk shows up when you intentionally allow your admin VLAN (VLAN 10) to forward to all other VLANs: anything that ends up in VLAN 10 becomes “trusted” and can reach everything by design. In my case, only my personal laptop joins VLAN 10 and only when I’m doing admin work, so I consider the residual risk acceptable for simplicity.
DMZ awareness: putting the Brume 2 in the ISP router’s DMZ is a pragmatic choice, but it makes it extra important to ensure you’re not accidentally exposing LuCI/SSH (or any other management services) on the WAN side. Remote access should be via VPN, not open admin ports.

If you’re using GL.iNet’s UI on top of OpenWrt, remember that once you move to VLAN interfaces, the GL.iNet device list may no longer reflect your clients properly—LuCI/SSH becomes your source of truth.

What’s next (Part 3)

With Site A complete, the next step is to extend the same “predictable subnets + strict boundaries” mindset to Site B (my parents’ house) and connect both sites with a site-to-site WireGuard tunnel, plus add secure travel access so I can manage everything without exposing services to the public internet.

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

Nuno Amaral — Wed, 18 Feb 2026 15:37:33 +0000

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

VLAN ID	Subnet	Purpose	Who uses it
10	10.11.10.0/24	Management	Router admin interfaces, managed switch, AP controller
20	10.11.20.0/24	Family	Laptops, phones, tablets —trusted personal devices
30	10.11.30.0/24	Homelab	Raspberry Pi, NUC, HP mini PCs, any device running lab workloads
40	10.11.40.0/24	IoT	Smart lightbulbs, power plugs, other IoT gadgets with questionable firmware
50	10.11.50.0/24	Entertainment	Media devices, smart TVs, gaming consoles, streaming boxes

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.