Building a Production-Grade Home Network with UniFi VLANs

Your home network doesn’t have to be a flat, insecure mess where your smart toaster can talk to your NAS. With UniFi gear and some intentional design, you can build network segmentation that rivals enterprise setups—without the enterprise price tag. This is how I architected a 10-VLAN home network that isolates everything from security cameras to a 7-node Kubernetes cluster.

Part 1: The Design Philosophy

Why Segment at All?

Most home networks run everything on a single subnet. Your laptop, your Ring cameras, your kids’ tablets, and your IoT light bulbs all share the same network space. This creates several problems:

1. Security exposure: A compromised smart device can sniff traffic from your work laptop
2. Broadcast storms: Every device sees every other device’s discovery traffic
3. No traffic prioritization: Your VoIP call competes with your kid’s Netflix stream
4. Debugging nightmares: “Something on the network is slow” becomes impossible to diagnose

The solution: VLANs (Virtual Local Area Networks). Each VLAN is a logically separate network that requires explicit routing to communicate with others.

The IP Addressing Scheme

I designed an IP scheme where the VLAN ID matches the third octet. This makes troubleshooting trivial—you can look at any IP and immediately know which network it belongs to:

10.X.Y.Z
├── X  = Site identifier (pick any number 1-254)
├── Y  = VLAN ID (matches third octet)
└── Z  = Host (.1 = Gateway, .2-.5 = Reserved, .6-.254 = DHCP)

At a glance:

• 10.X.5.45 → Main network (VLAN 5)
• 10.X.25.127 → Servers network (VLAN 25)
• 10.X.45.86 → IoT network (VLAN 45)

No mental math required. The VLAN is in the IP.

Understanding Private IP Ranges (RFC 1918)

Before diving into the architecture, let’s clarify why I use 10.x.x.x for most networks but 192.168.x.x for one. Both are private IP ranges defined in RFC 1918—addresses reserved for internal networks that aren’t routable on the public internet.

There are three private ranges:

Why I chose 10.x.x.x for most networks:

The 10.0.0.0/8 range gives me 16 million addresses to work with. More importantly, I can use the second and third octets semantically:

• Second octet (10.X.y.z) = Site identifier (useful if you have multiple locations)
• Third octet (10.x.Y.z) = VLAN ID

This scheme scales elegantly. I can add 254 VLANs per site, each with 254 hosts, without ever running out of space or needing to restructure.

Why 192.168.x.x for the GPU Farm:

The GPU Farm intentionally uses 192.168.99.0/24 instead of following the 10.X.Y.Z pattern. This is a deliberate visual signal—when you see a 192.168.x.x address, you immediately know you’re dealing with the isolated, untrusted compute network. It’s a “this doesn’t belong to the main infrastructure” marker that makes misconfiguration harder.

Most consumer routers default to 192.168.1.1, so this range often carries the mental association of “basic home network.” By reserving it for the GPU Farm, I’m saying: this network plays by different rules.

The Hidden Cost of 192.168.x.x:

There’s a significant downside to using 192.168.x.x that I learned the hard way: it’s the most collision-prone range on the internet.

Here’s why this matters:

1. VPN Routing Conflicts: Nearly every consumer router defaults to 192.168.0.x or 192.168.1.x. When you VPN into your home network from a coffee shop, hotel, or office that uses the same range, routing breaks. Your machine doesn’t know if 192.168.1.50 means your home NAS or the hotel’s printer—it picks the local route and your SSH connection never reaches home.

2. SSH Through Jump Hosts: If you SSH through a bastion server into a network that shares your local subnet, packets get misrouted. You type ssh 192.168.1.100 expecting to reach your server, but the traffic stays local because your routing table says “192.168.1.0/24 is right here.”

3. Site-to-Site VPN Nightmares: Organizations using 192.168.x.x often need to NAT everything when establishing tunnels to partners. One networking thread mentioned 8 out of 10 IPSec tunnels required NAT due to conflicts—all in the 10.x.x.x space because “everyone” migrated there. The irony: if you pick an uncommon 192.168.x.x subnet, you might actually have fewer conflicts than the crowded 10.0.0.0/24 everyone defaults to.

4. Remote Work Complications: Your employees work from home. Their home routers use 192.168.1.x. Your corporate network uses 192.168.1.x. VPN connected, but nothing works. IT spends hours debugging before realizing it’s a subnet collision.

The Mitigation: If you must use 192.168.x.x, pick an unusual third octet—192.168.42.x, 192.168.99.x, or 192.168.200.x. Avoid .0.x and .1.x like the plague. Better yet, use 10.x.x.x for anything you’ll need to reach remotely and reserve 192.168.x.x for truly isolated networks (like my GPU Farm) that you’ll only access locally.

Part 2: The 10-VLAN Architecture

Here’s the complete network topology:

Why These Specific Segments?

Default (VLAN 1): This is where network infrastructure lives—access points, switches, the UDM Pro itself. Nothing user-facing should be here.

Main (VLAN 5): The trusted network. Phones, laptops, tablets that need full access to everything. mDNS enabled for Chromecast/AirPlay discovery.

Security (VLAN 15): Cameras and locks get their own network. These devices are notoriously insecure and shouldn’t mingle with anything else. Separate SSID for easy onboarding.

Servers (VLAN 25): The homelab backbone. NAS, Kubernetes control plane, all worker nodes. This is where the infrastructure lives:

K3s Cluster Layout:
├── Control Plane (laptop)
├── Workers:
│   ├── 2x Mini PCs
│   ├── 2x Small Form Factor desktops
│   ├── 1x Laptop
│   └── 1x Desktop (GPU workloads)
└── NAS

Clusters (VLAN 26): Kubernetes assigns pod and service IPs from this range. Separating workload traffic from node management traffic.

IoT (VLAN 45): Smart bulbs, smart switches, anything that phones home to unknown servers. Isolated but with mDNS forwarding so voice assistants can still discover them.

Guest (VLAN 55): Internet access only. No local network access. Auto-scaling enabled for capacity.

Work (VLAN 65): Corporate devices that might have VPN clients or MDM software. Isolated from personal devices but can reach the Servers VLAN.

Voice (VLAN 75): VoIP phones with QoS prioritization. Latency-sensitive traffic gets priority.

GPU Farm (VLAN 99): The only network with isolationEnabled: true. These GPU nodes run untrusted workloads and should never initiate connections to anything else.

Part 3: Wireless Network Mapping

Each VLAN that needs wireless access gets a dedicated SSID:

This approach means onboarding a new device is trivial: connect it to the right SSID, and it automatically lands on the correct VLAN with the appropriate firewall rules.

Part 4: mDNS and Cross-VLAN Discovery

Here’s where it gets tricky. VLANs isolate traffic, but some services rely on mDNS (multicast DNS) for discovery—think AirPlay, Chromecast, Sonos, and smart home integrations.

The solution: mDNS forwarding between specific VLANs.

This lets your phone on Main discover and control IoT devices, while guests and work devices remain completely isolated.

Part 5: The Kubernetes Integration

The Servers VLAN hosts a 7-node K3s cluster. All nodes expose Ollama (local LLM inference) on port 31434:

# Any node can serve LLM requests
curl http://10.X.25.108:31434/api/generate -d '{"model": "llama2", "prompt": "Hello"}'

The cluster architecture:

┌─────────────────────────────────────────────────┐
│                 Servers VLAN (25)               │
├─────────────────────────────────────────────────┤
│  ┌──────────────┐    ┌──────────────────────┐  │
│  │ Control Plane│    │      Workers         │  │
│  │   (Laptop)   │    │  2x Mini PCs         │  │
│  │  (K3s API)   │    │  2x SFF Desktops     │  │
│  │              │    │  1x Laptop           │  │
│  │              │    │  1x Desktop (GPU)    │  │
│  └──────────────┘    └──────────────────────┘  │
│                                                 │
│  ┌──────────────┐                              │
│  │     NAS      │                              │
│  │              │                              │
│  └──────────────┘                              │
└─────────────────────────────────────────────────┘

Part 6: Lessons Learned

1. Don’t Put Everything on Default

I made this mistake initially. Looking at my IoT inventory, every device was on VLAN 1 (10.X.1.x) instead of their designated VLANs. The architecture existed, but devices weren’t onboarded correctly.

Fix: Either reconnect devices to the correct SSIDs or use MAC-based VLAN assignment in UniFi.

2. Reserve IPs for Static Assignments

Each subnet reserves .2-.5 for static assignments. This prevents DHCP from handing out an IP you later want to assign statically.

3. The GPU Farm Exception

Notice the GPU Farm uses 192.168.99.0/24 instead of the 10.X.Y.Z scheme. This is intentional—it runs untrusted workloads and is fully isolated. The different subnet is a visual reminder that this network plays by different rules.

4. Document Everything via API

I pulled this network configuration directly from the UniFi Integration API:

# Get all networks
GET /integration/v1/sites/{site_id}/networks

# Get specific network details
GET /integration/v1/sites/{site_id}/networks/{network_id}

This ensures documentation stays accurate—it’s generated from the source of truth, not manually maintained.

Part 7: Quick Reference Card

Keep this handy for troubleshooting:

Main devices:      10.X.5.x   (VLAN 5)
Cameras/locks:     10.X.15.x  (VLAN 15)
Servers/NAS:       10.X.25.x  (VLAN 25)
K8s workloads:     10.X.26.x  (VLAN 26)
Smart home:        10.X.45.x  (VLAN 45)
Guests:            10.X.55.x  (VLAN 55)
Work laptops:      10.X.65.x  (VLAN 65)
VoIP phones:       10.X.75.x  (VLAN 75)
GPU nodes:         192.168.99.x (VLAN 99, isolated)

Key Takeaways

1. VLAN ID = Third octet makes debugging trivial. You see the IP, you know the network.

2. Separate SSIDs per VLAN simplifies onboarding. Connect to the right network, get the right isolation.

3. mDNS forwarding is the bridge between security (isolation) and usability (discovery). Enable it only where needed.

4. Document from the API not from memory. UniFi’s Integration API gives you the ground truth.

5. Isolation isn’t all-or-nothing. Most networks allow inter-VLAN routing with firewall rules. True isolation (isolationEnabled: true) is for special cases like untrusted GPU workloads.

Your home network can be as sophisticated as you need it to be. Start with two VLANs (trusted and IoT), then expand as your homelab grows. The UniFi ecosystem makes this accessible without needing a CCNA.