Six VLANs and a Juniper Switch: Networking the Lab Properly
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-grade router with firmware from 2019.
The second rule is that fixing this requires enterprise switches, and enterprise switches require a Juniper CLI obsession that is, clinically speaking, a personality trait.
Why Enterprise Gear at Home
Juniper EX3300 switches appear 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 RFC documents for fun. The cost difference between a managed consumer switch and a used enterprise switch is often less than $100. The operational difference is considerable.
The lab runs two EX3300s: a core switch at 172.16.100.254 and an office switch for workstations and wireless uplinks. They’re stacked in a comms cabinet that also houses the OPNsense firewall, the Aruba wireless controller, and a Synology NAS — a setup that looks impressive until you explain it’s in a spare room and not, in fact, a data centre.
The VLAN Architecture
Six VLANs, each with a purpose:
| 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 genuine teeth: guests get an address, a public resolver, and the internet, and nothing else. IoT devices, by contrast, share the wireless VLAN with the phones and laptops. That’s a compromise rather than a design — a dedicated IoT VLAN is the obvious next segmentation, and the honest reason it doesn’t exist yet is that every smart device in the house would need re-onboarding to a new SSID on a wet weekend.
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 policy that governs what leaves the building. It sits on the transit VLAN and sees north-south traffic, not east-west.
Which means the honest description of inter-VLAN policy is: there isn’t one. VLANs here provide broadcast-domain separation and a clean addressing scheme, 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, deliberate gap — flagged in a later security audit, considered, and consciously accepted for a single-occupant home lab where the blast radius is measured in embarrassment rather than dollars.
I’d rather write that down 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 a different VLAN: the primary home WiFi maps to the client VLAN, IoT devices get their own SSID that lands in the IoT VLAN, and a guest network is completely isolated.
The Aruba controller is one of those pieces of enterprise kit that is dramatically overspecified for a home environment and yet, once you’ve used a proper wireless controller, consumer access points feel like trying to manage production servers via VNC.
The Use Case: Constraining AI Workloads
The practical reason this architecture exists: when you’re running AI agents with access to network infrastructure tools, you want the access to be deliberate rather than incidental.
The enforcement, 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 different account entirely. The Aruba MCP server is read-only by construction. The interesting boundary 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 legible 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 running 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 that safe.
Synology as the Single Source of Truth for DNS
The Synology NAS doubling as the DNS authority for sdx.local is a decision that has held up well. The NAS has its own UPS, backs up its own configuration nightly, and has proven more reliable over time than the OPNsense firewall (which has had two power supply incidents and one memorable afternoon of CARP failover testing that did not go according to plan).
Every VM in the lab, every host, every service registers its DNS entry in the Synology DNS server. The result is that kali.sdx.local, vault.sdx.local, litellm.sdx.local, and about 60 other hostnames resolve cleanly from anywhere in the lab network without resorting to hardcoded IP addresses in config files — a habit which, once acquired, is very difficult to debug out of old infrastructure.
What Came Next
A segmented network gives you the foundation. What it doesn’t give you is identity — a way for services to know who they’re talking to, for humans to authenticate with something better than shared passwords, and for secrets to live somewhere safer than plaintext environment variables. That required building an internal Certificate Authority, an identity provider, and a password vault. Three separate services, one very 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. It was replaced on 6 June by a two-member EX3400-24P stretched virtual chassis: one switch in each room, one logical device at 172.16.100.254, the office EX3300 retired along with it. The VC backbone runs over the two existing Cat6 room-to-room runs 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 been down for an unknown period 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 to 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 the secondary, after a June incident where a dead upstream forwarder on the NAS put ~2.5 seconds onto every external lookup lab-wide. OPNsense forwards
sdx.localto the NAS, which is still authoritative. Both resolvers run Unbound in forwarding mode with DNSSEC off — recursive validation plus a WAN flap is what pegged the firewall’s CPU at 100% and took the router offline back in May. - The guest network grew a password.
Qnet-Guestwas an open SSID with a captive portal; it’s now WPA2-PSK with client isolation and a session ACL that denies all RFC 1918 destinations. - The flat-internal-network gap named above was formally raised and formally accepted in the June 2026 security audit. It remains the largest open architectural compromise in the lab, and it’s there on purpose.