Segmenting your Home Lab: A VLAN Revamp with your UniFi gear

In my previous post, I explained how traveling broke my WireGuard VPN because of subnet overlaps with hotel Wi-Fi networks. The solution was migrating my entire home network from 192.168.0.0/23 (or similar consumer defaults) to a structured 10.[SITE].[VLAN].0/24 range (using 10.151.0.0/16 for my primary home site).

But simply re-numbering IPs was only half the job. Since I had to touch every client anyway, I decided to finally segment my network into separate virtual networks (VLANs).

Here are the key lessons I learned during the VLAN revamp.

Lesson #1: UniFi VLANs are Just Networks with an ID

If you’re coming from enterprise Cisco gear or command-line managed switches, the concept of a VLAN might feel low-level. You’re used to defining VLANs, configuring tagged/untagged trunk interfaces, and manually setting up virtual routing.

In the UniFi ecosystem, Ubiquiti abstracts this away. In the UniFi Network Controller, VLANs are just Networks.

To create a new VLAN in UniFi:

1. Go to Settings → Networks → New Network.
2. Give it a name (e.g., “IoT-Net”).
3. Assign it a subnet IP range (e.g., 10.151.30.1/24).
4. Toggle the VLAN ID setting and input your desired ID (e.g., 30).

Once you click save, UniFi automatically provisions the new VLAN across all your adopted UniFi switches and APs. The UniFi Gateway automatically creates a virtual sub-interface (e.g., br30 or a sub-interface on the LAN port) to act as the default gateway (10.151.30.1) for that VLAN. You don’t have to manually manage routing tables, encapsulation, or trunk links between UniFi devices—it just works.

Network Design Breakout

Here is the breakout of the final network design for Site 151:

Lesson #2: VLANs Transit Your Router (The Inter-VLAN Tax)

When setting up VLANs (Virtual Local Area Networks), it is easy to think of them as just magical separate virtual switches. You put your servers on VLAN 10, trusted clients on VLAN 20, IoT on VLAN 30, and guest devices on VLAN 40. They are isolated at Layer 2, which is great for security.

But what happens when your desktop (VLAN 20) needs to talk to your Home Assistant server (VLAN 30) on a typical home network with Layer 2 switches?

Because they are on separate VLANs, they cannot communicate directly at the switch level. The traffic must transit your router (gateway) to be routed from one subnet to the other. In a standard UniFi home setup, this means:

1. Your desktop sends a packet destined for VLAN 30.
2. The switch forwards it tagged to the UniFi Router.
3. The UniFi Router inspects the packet, applies firewall rules, and routes it to the interface for VLAN 30.
4. The router sends the packet back down to the switch.
5. The switch forwards it to the Home Assistant server.

  [ Desktop (VLAN 20) ]
            |
            | 1. Tagged Traffic (VLAN 20)
            v
  +-------------------+      2. Trunk Link (VLAN 20 Tagged)     +-----------------------+
  |                   |---------------------------------------->|                       |
  |    Core Switch    |                                         | UniFi Router/Firewall |
  |                   |<----------------------------------------|  (3. Route & Filter)  |
  +-------------------+      4. Routed Traffic (VLAN 30 Tagged) +-----------------------+
            |
            | 5. Tagged Traffic (VLAN 30)
            v
  [ Home Assistant (VLAN 30) ]

Traffic Bottleneck and SPOF

Because inter-VLAN traffic must travel up to the router and back down, you introduce two major issues:

1. Bandwidth Bottleneck: The link between your core switch and your router can quickly become saturated.
2. Single Point of Failure (SPOF): If your router reboots or fails, all inter-VLAN communication breaks—even if your local network switches are still powered on and functional.

For example, if you place security cameras on an isolated IoT VLAN (VLAN 30) and your Network Video Recorder (NVR, like Frigate) on your Server VLAN (VLAN 10), your cameras will stop recording if the router goes offline. Keeping your cameras and NVR on the same physical VLAN ensures they continue communicating directly through the local switch, completely immune to router reboots or gateway failures.

Lesson #3: Wired Hosts on Multiple VLANs are Dead Simple

You might be wondering how to get your virtual machines or container hosts to talk on multiple VLANs over a single ethernet cable. This was actually a lot easier than I thought once I understood how to configure the host’s network interfaces.

I’m using Debian 13 with the default ifupdown utility. Below is an example configuration that you can paste directly into /etc/network/interfaces (or inside /etc/network/interfaces.d/vlans):

# ==========================================
# Example /etc/network/interfaces VLAN Setup
# ==========================================

# The loopback network interface
auto lo
iface lo inet loopback

# 1. The physical interface on VLAN 10 (server)
auto enp10s0
iface enp10s0 inet static
    address 10.151.10.22/24
    gateway 10.151.10.1

# 2. VLAN 20 (client)
auto enp10s0.20
iface enp10s0.20 inet static
    address 10.151.20.22/24
    # no gateway here - only on primary interface
    vlan-raw-device enp10s0

# 3. VLAN 30 (IoT)
auto enp10s0.30
iface enp10s0.30 inet static
    address 10.151.30.22/24
    # no gateway here - only on primary interface
    vlan-raw-device enp10s0

Just run sudo systemctl restart networking (or use ifup/ifdown), and Debian will spin up virtual interfaces like enp10s0.20, enp10s0.30, and enp10s0.40, tagging outbound traffic appropriately.

NOTE: Your UniFi switch also will need to know how to manage VLAN traffic on this host’s port. My servers are configured on VLAN 10 as their Native VLAN, and have Allow All for their Tagged VLAN Management.

Tip: Aligning the 4th Octet for Multi-Homed Hosts

If you look closely at the Debian ifupdown configuration above, you’ll notice that the server’s IP address ends in .22 on every single VLAN it is connected to:

• 10.151.10.22 (VLAN 10)
• 10.151.20.22 (VLAN 20)
• 10.151.30.22 (VLAN 30)
• 10.151.40.22 (VLAN 40)

This is a deliberate design choice that makes network administration much easier. If you have core infrastructure hosts (like a hypervisor host, a DNS/DHCP server, or a monitoring node) that span multiple VLANs, keeping their host portion (the 4th octet) identical across all subnets keeps your network maps clean. You’ll always know that server X is .22, no matter which VLAN’s subnet you are looking at.

To make this work:

1. Reserve the first block of IPs: On every VLAN, reserve the range from .1 to .32 exclusively for static IP allocations.
2. Configure DHCP Pools outside this range: Set your UniFi DHCP pools to start at .33 (e.g., 10.151.x.33 to 10.151.x.254).
3. Map the static hosts: Assign your multi-homed static servers their respective ID in that .1 to .32 window.

Since this static block is reserved for core servers, routers, and managed switches, a pool of 32 static addresses per VLAN provides plenty of room for future homelab growth while keeping host IP addresses highly predictable.

Lesson #4: Wi-Fi Clients are a One-Way Ticket

Another key realization during this revamp was how VLANs behave on wireless networks versus wired ports.

On a physical switch, a port can be configured as a trunk, meaning it carries traffic for multiple tagged VLANs simultaneously (just like we did for our Debian server above).

Wireless networks don’t really work this way for clients. In a standard UniFi setup (using UniFi OS, a UniFi router, and UniFi APs), wireless SSIDs are tied to a single VLAN.

• SSID 1: “Main-Net” → Hard-mapped to VLAN 20.
• SSID 2: “IoT-Net” → Hard-mapped to VLAN 30.
• SSID 3: “Guest-Net” → Hard-mapped to VLAN 40.

When your phone connects to “Main-Net”, it performs a standard Wi-Fi handshake. The AP handles all the encapsulation; it takes your untagged wireless frames and tags them as VLAN 20 before dropping them onto the physical switch.

From the phone’s perspective, it has no idea VLANs even exist—it just gets an IP on the 10.151.20.0/24 subnet. Unlike a wired server, a single Wi-Fi client cannot easily “trunk” multiple VLANs over its wireless connection.

Lesson #5: Multi-VLAN DHCP and DNS with dnsmasq

If you run your own central DNS and DHCP server (like dnsmasq, Pi-hole, or AdGuard Home) rather than relying on your UniFi router’s built-in services, you face a new challenge: DHCP works via Layer 2 broadcast packets.

When a new device connects to a network, it sends out a DHCPDISCOVER broadcast packet to 255.255.255.255 asking for an IP. Because routers do not forward broadcasts between subnets/VLANs by default, a DHCP server sitting on VLAN 10 cannot hear a broadcast sent by a device on VLAN 20.

To solve this without setting up complex DHCP relay helpers (which require configuring options on the gateway), you can simply place your dnsmasq server directly onto every VLAN it needs to serve. Since we’ve trunked all the VLANs to the host using Debian’s ifupdown (shown in Lesson 3), we can tell dnsmasq to listen and serve distinct ranges on each interface.

Here is an example dnsmasq.conf layout for this setup:

# ==========================================
# Example /etc/dnsmasq.conf Multi-VLAN Setup
# Only manage DHCP for server, client, and IOT vlans (not infra or guest)
# ==========================================

# 1. Listen only on the specified VLAN interfaces
interface=enp10s0
interface=enp10s0.20
interface=enp10s0.30

# Bind only to the interfaces we are listening on
bind-interfaces

# 2. Define DHCP Ranges and set tags for each VLAN
# Format: dhcp-range=set:TAG,start_ip,end_ip,subnet_mask,lease_time
# Note: 
#  .1->.32 for trunked static hosts
#  .33 -> .128 for static ips
#  .129 -> .254 for dhcp ips
dhcp-range=set:vlan10,10.151.10.129,10.151.10.254,255.255.255.0,12h
dhcp-range=set:vlan20,10.151.20.129,10.151.20.254,255.255.255.0,12h
dhcp-range=set:vlan30,10.151.30.129,10.151.30.254,255.255.255.0,12h

# 3. Override Default Gateway (Option 3) per VLAN
# By default, dnsmasq advertises its own interface IP as the gateway.
# We override this to point to the actual UniFi Router IP (.1) on each VLAN.
dhcp-option=tag:vlan10,option:router,10.151.10.1
dhcp-option=tag:vlan20,option:router,10.151.20.1
dhcp-option=tag:vlan30,option:router,10.151.30.1

# 4. Set DNS Servers (Option 6) per VLAN
# Point clients to the server's own IP (.22) on their respective VLAN.
dhcp-option=tag:vlan10,option:dns-server,10.151.10.22
dhcp-option=tag:vlan20,option:dns-server,10.151.20.22
dhcp-option=tag:vlan30,option:dns-server,10.151.30.22

With bind-interfaces active, dnsmasq listens specifically on each virtual interface. When a broadcast packet arrives on enp10s0.20, dnsmasq knows it came from VLAN 20, assigns it a lease in the 10.151.20.0/24 range, and advertises the correct router (10.151.20.1) and DNS server (10.151.20.22) for that network.

Wrap-up

While migrating to VLANs takes some initial planning—especially when configuring firewall rules to allow or block cross-VLAN traffic—the result is a much more secure and professional layout. My noisy IoT gadgets are isolated, my server interfaces are cleanly separated, and I have complete control over what gets routed where.