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

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

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.