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 pfSense 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 |
|---|---|---|
| Infrastructure | 172.16.100.x | NAS, switches, wireless controller, cameras |
| VM Workloads | 172.16.50.x | KaliLinux, UbuntuClaw, DebIdentity, DebApps |
| Management | 172.16.250.x | pfSense, out-of-band management |
| WiFi Clients | 172.16.10.x | Phones, tablets, laptops |
| IoT | 172.16.20.x | Smart devices, sensors, anything untrusted |
| Guest | 172.16.30.x | Visitors, internet-only access |
The IoT VLAN exists specifically because your smart TV does not need to initiate connections to your AI infrastructure. This is not hypothetical. IoT devices regularly attempt to communicate with other hosts on the local network for reasons that are either benign telemetry or deeply concerning depending on your level of paranoia.
pfSense as the Brain
pfSense at 172.16.250.254 handles routing between all VLANs and provides the firewall policy that defines what can talk to what. The default inter-VLAN policy is deny-all. Traffic is explicitly permitted by rule — VMs on 172.16.50.x can talk to the NAS on 172.16.100.x, but IoT devices cannot reach anything outside their own VLAN except the default gateway for internet access.
This sounds restrictive. It is. It’s also what makes it possible to run a Kali Linux VM on the same physical host as your home automation system without having a very bad afternoon.
The pfSense instance also handles the DNS forwarding hierarchy. Queries for sdx.local go to the Synology NAS (primary DNS at 172.16.100.100), which is authoritative for the internal zone. External queries go to 1.1.1.1. The NAS being the DNS server is a deliberate choice — it has UPS-backed power and is one of the most reliable pieces of infrastructure in the stack.
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: Network Isolation for AI Workloads
The practical reason this architecture exists: when you’re running AI agents with access to network infrastructure tools, you need hard boundaries. An AI agent that can query your Juniper switch should not be able to reach your family’s devices by accident, by misconfiguration, or by anything else.
The VM VLAN (172.16.50.x) is isolated from client VLANs by default. AI services in this VLAN can reach out to the infrastructure VLAN for management operations (explicitly permitted), but they cannot initiate connections into the client or IoT VLANs. The firewall is the enforcement mechanism; the VLAN is the boundary.
When Clawdia — the AI assistant running on UbuntuClaw — later gained the ability to query Juniper switch state via MCP servers, this isolation meant that access was intentional and auditable, not a side effect of everything being on the same flat network.
Synology as the Single Source of Truth for DNS
The Synology NAS doubling as the primary DNS server 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 pfSense 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 with proper firewall rules 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.