Six VLANs and a Juniper Switch: Networking the Lab Properly
Flat networks are fine until they aren't. Segmenting a home lab with enterprise gear, OPNsense, and the kind of routing table that impresses nobody at dinner parties.
The first rule of home networking is that a flat network is a ticking clock. Everything talks to everything, your IoT devices share a broadcast domain with your servers, and the only thing standing between your NAS and your smart fridge is a prayer and a consumer router running firmware from 2019.
The second rule is that fixing this calls for enterprise switches, and enterprise switches come with a Juniper CLI habit that is, clinically speaking, a personality trait.
Why Enterprise Gear at Home
Juniper EX3300 switches show up on eBay with surprising regularity, usually retired from small businesses upgrading to something newer. They support 802.1Q VLANs, RSTP, LACP, and a full JunOS CLI that rewards the kind of person who reads RFCs for fun. The price gap between a managed consumer switch and a used enterprise switch is often less than $100. The operational difference is huge.
The lab runs two EX3300s: a core switch at 172.16.100.254 and an office switch for workstations and wireless uplinks. They sit in a comms cabinet alongside the OPNsense firewall, the Aruba wireless controller, and a Synology NAS - a setup that looks impressive right up until you explain it’s in a spare room and not a data centre.
The VLAN Architecture
Six VLANs, each with a clear job:
| VLAN | Subnet | Purpose |
|---|---|---|
| Wired access | 172.16.10.x | Wired clients, out-of-band management |
| WLAN access | 172.16.20.x | Wireless clients - phones, tablets, laptops, IoT |
| Guest | 172.16.30.x | Visitors, internet-only access |
| Lab | 172.16.50.x | KaliLinux, UbuntuClaw, DebIdentity, DebApps |
| Server | 172.16.100.x | NAS, switches, wireless controller, cameras |
| Transit | 172.16.250.x | Firewall uplink to the internet edge |
The guest VLAN is the one with real teeth: guests get an IP address, a public resolver, and the internet, and nothing else. IoT devices, on the other hand, share the wireless VLAN with our phones and laptops. That’s a compromise rather than a grand design - a dedicated IoT VLAN is the obvious next step, and the honest reason I haven’t done it yet is that re-onboarding every smart device in the house onto a new SSID is a wet-weekend job I keep finding excuses to postpone.
Who Actually Routes What
This is the part most home lab write-ups get wrong about their own networks, mine included for a while.
The core switch is the layer-3 gateway. Each VLAN has a routed interface on the Juniper, and traffic between VLANs is switched and routed in silicon on that box - it never touches the firewall. The core also serves DHCP for every VLAN from on-switch pools, including the option 43 payload that tells Aruba access points where to find their controller.
OPNsense at 172.16.250.254 is the edge: WAN termination, NAT, DNS, VPN, and the rules that govern what leaves the building. It sits on the transit VLAN and sees north-south traffic, not east-west.
That means the honest summary of inter-VLAN policy is: there isn’t one. VLANs here give me broadcast-domain separation and clean addressing, not enforcement. A compromised host on the wireless VLAN can route to the lab VLAN as freely as it can route to the internet. Adding inter-VLAN ACLs on the core is a known gap - I flagged it in a later security audit, weighed it up, and accepted it for a single-occupant home lab where the blast radius is measured in embarrassment rather than dollars.
I’d rather write that down plainly than let a diagram imply a firewall that isn’t there.
Aruba Wireless
The Aruba wireless controller at 172.16.100.110 manages three access points and handles SSID-to-VLAN mapping. Each SSID maps to its target VLAN, and the guest network stays completely isolated from internal subnets.
An Aruba controller is wildly overspecified for a house. Still, once you’ve used a proper wireless controller, consumer mesh routers feel like trying to manage production servers over VNC.
The Use Case: Constraining AI Workloads
The practical reason this setup exists is simple: when you give AI agents access to network tools, you want that access to be deliberate rather than accidental.
The real guardrail, though, isn’t at the network layer - it’s at the credential layer. The AI service account on the core switch is bound to a custom read-only login class that can view configuration and nothing else. Committing a change requires a separate account entirely, and the Aruba MCP server is read-only by construction. The boundary that actually matters turned out to be “what can this identity do”, not “what subnet is it on”.
That’s the correction I’d make to my own thinking from this period. Segmenting the network was worth doing - it made the addressing clean and gave the guest network a real edge - but it was never what stopped an AI agent from doing something stupid to a switch.
When Clawdia (the AI assistant on UbuntuClaw) later gained the ability to query Juniper switch state via MCP servers, it was scoped credentials and a read-only login class that made it safe.
Synology as the Single Source of Truth for DNS
Having the Synology NAS double as the DNS authority for sdx.local has held up well. The NAS has its own UPS, backs up its config nightly, and has proven more reliable over time than the OPNsense box (which has had two power supply incidents and one memorable afternoon of CARP failover testing that didn’t go to plan).
Every VM, host, and service in the lab gets a DNS record in the Synology DNS server. As a result, kali.sdx.local, vault.sdx.local, litellm.sdx.local, and around 60 other hostnames resolve cleanly from anywhere in the lab without hardcoded IP addresses in config files - a habit that, once started, is painful to untangle later.
What Came Next
A segmented network gives you the plumbing. What it doesn’t give you is identity - a way for services to verify who they’re talking to, for humans to log in with something better than shared passwords, and for secrets to live somewhere safer than plaintext env files. That meant building an internal Certificate Authority, an identity provider, and a password vault. Three separate services, one busy VM.
Update - August 2026
- Both EX3300s are gone - The core unit’s eUSB flash started corrupting config writes in May 2026 - SSH host keys and parts of the UI binaries would come back wrong after a commit. On 6 June I replaced it with a two-member EX3400-24P stretched virtual chassis: one switch in each room, one logical device at 172.16.100.254, and the office EX3300 retired alongside it. The VC backbone runs over the two existing Cat6 room-to-room cables using 10GBASE-T copper SFP+ modules.
- That backbone has one scar - In June, swapping a power supply on the office member split the virtual chassis because one of the two VC links had quietly gone down earlier and nobody was watching. The copper modules present themselves to Junos as fibre optics, so the switch doesn’t re-train them after a loss of signal - the member needed a reboot. There’s now a daily check that alerts Telegram if fewer than four VC port-links are up. Redundancy you don’t monitor isn’t redundancy.
- DNS was reordered - OPNsense is now the primary resolver and the NAS is secondary, after a June incident where a dead upstream forwarder on the NAS added ~2.5 seconds to every external lookup lab-wide. OPNsense forwards
sdx.localto the NAS, which stays authoritative. Both resolvers run Unbound in forwarding mode with DNSSEC off - recursive validation plus a WAN flap is what pegged the firewall CPU at 100% and took the router offline back in May. - The guest network grew a password -
Qnet-Guestused to be an open SSID with a captive portal. It’s now WPA2-PSK with client isolation and a session ACL that blocks all RFC 1918 destinations. - The flat internal routing trade-off was formally accepted - I raised it in the June 2026 security audit and decided to keep it as-is. It remains the largest open architectural compromise in the lab, and it’s there on purpose.
Update - October 2026
- 10GbE jumbo frames between REX and the NAS taught me a lesson about virtual switches - Enabling MTU 9000 across the storage path worked nicely until a hypervisor virtual switch on the NAS silently clamped its bound interface back to MTU 1500. Small SSH packets sailed through, while full 9000-byte frames with the Don’t Fragment bit set hit the switch port and vanished. Moving the NAS VMs off the 10GbE storage interface onto a dedicated 1GbE trunk restored end-to-end 9000-byte frames.
- OPNsense picked up CrowdSec and a road-warrior WireGuard tunnel - CrowdSec runs at the edge with local-only blocking enabled. I turned off the community blocklists after weighing up the risk of a hotel or mobile CGNAT IP landing on a shared feed and locking me out while travelling. A second WireGuard instance terminates a travel router and phone for full-tunnel access back home.
- OPNsense’s split rule stores were unified - I migrated all legacy per-interface XML rules into the modern MVC automation store, so the REST API and MCP server now see 100% of the active firewall policy.
- Aruba RF was rebuilt from a clean sheet - I replaced dynamic radio assignment with a static non-overlapping channel plan, converted one AP’s 5 GHz radio into a dedicated Air Monitor for rogue-AP and RF telemetry, and moved the security cameras and alarm panel onto the wired access VLAN with internet egress blocked at the firewall.