How to Set Up a Proper Network for Your Home Lab


At some point every home lab outgrows the flat network it started on. Maybe a bad DHCP experiment took down the family Wi-Fi. Maybe you realized your Proxmox cluster, your kids’ iPads, and a bunch of IoT devices that phone home to who-knows-where are all on the same subnet with nothing between them. Either way, you’re here now.

A proper home lab network setup is the single biggest quality-of-life upgrade you can make. It’s also not as expensive or complicated as it sounds. If you’re brand new, start with the beginner’s guide and come back here.

Networks Matter More Than Hardware

Most people throw their budget at compute and treat the network as an afterthought. I did the same thing. The result was a single flat subnet where a misconfigured container could take down internet access for the whole house. Once that happens, you get the motivation to fix things pretty quickly.

Segmentation gives you the ability to experiment without risk. That’s the point of a lab.

VLANs

VLANs let you carve one physical switch into multiple logical networks. Instead of buying separate hardware for each network segment, you configure VLANs on a managed switch and define rules for how they talk to each other.

Here’s roughly how mine is set up:

  • VLAN 10 — Management: Switch consoles, hypervisor management interfaces, IPMI
  • VLAN 20 — Lab: Proxmox VMs, Docker hosts, Kubernetes experiments
  • VLAN 30 — Home: Family devices, phones, laptops
  • VLAN 40 — IoT: Smart home devices, cameras, anything that talks to the cloud unpredictably

VLANs without firewall rules between them are just labels. The actual segmentation happens at the router/firewall level.

Switches

You need a managed switch (or at minimum a “smart” switch) that supports 802.1Q VLAN tagging. Unmanaged switches won’t do this.

  • TP-Link TL-SG108E → — $25-30, 8 ports, VLAN support, port mirroring, IGMP snooping. This is the default starter recommendation in r/homelab for a reason — it handles four VLANs without complaint and costs less than lunch.
  • TP-Link TL-SG3210XHP-M2 → — PoE plus 2.5G uplinks. For when the 8-port doesn’t cut it anymore.
  • Ubiquiti USW-Pro-24-PoE → — Full UniFi ecosystem, 24 ports, PoE. The big league.

You will outgrow 8 ports. Everyone does. But start there anyway.

UniFi vs Omada

The ecosystem question comes up constantly, so here’s the short version:

UniFi has the better interface, larger community, and more mature ecosystem. The downside is Ubiquiti keeps pushing cloud-dependent features, prices have crept up, and their gateways run a locked-down OS that limits firewall flexibility. You also need to self-host the controller or buy a Cloud Key.

Omada (TP-Link) is cheaper for equivalent specs, especially PoE switches. The controller is free, self-hostable, and runs in a Docker container. The UI is less polished and community resources are thinner, but the actual networking features work.

My setup: Omada switches with a separate firewall. Cheaper hardware, full firewall control, no vendor lock-in on the routing side.

Firewall: pfSense vs OPNsense

Your consumer router won’t handle inter-VLAN routing with proper firewall rules. The two dominant open-source options:

pfSense — the veteran. Massive community, endless guides, runs on FreeBSD. Supports VLAN interfaces, NAT, WireGuard, OpenVPN, DNS, DHCP. If you can describe a network configuration, pfSense can do it.

OPNsense — a pfSense fork with a more modern UI and more frequent updates. Feature-wise they’re nearly identical. I use OPNsense because I prefer the plugin system and release cadence, but either works.

Run it on whatever you have — an old desktop with two NICs, a fanless mini PC, or a VM inside Proxmox with a dedicated NIC passed through. The VM approach is convenient but means your firewall dies if the hypervisor dies. Know the trade-off.

The Firewall Rules That Actually Matter

Once VLANs exist, these are the rules worth enforcing:

  1. Lab cannot reach Home. Kubernetes experiments don’t get to touch family devices.
  2. Home reaches internet but not Lab. Unless you explicitly allow a specific service.
  3. IoT reaches internet but nothing else. Smart plugs don’t need NAS access.
  4. Management is locked to your workstation. Switch consoles and IPMI stay isolated.

Start with “deny all inter-VLAN” and poke holes for specific services. Much safer than allowing everything and trying to close gaps later.

IP Addressing

Keep it simple and consistent:

  • 10.0.10.0/24 — VLAN 10 (Management)
  • 10.0.20.0/24 — VLAN 20 (Lab)
  • 10.0.30.0/24 — VLAN 30 (Home)
  • 10.0.40.0/24 — VLAN 40 (IoT)

Gateway is always .1. Reserve the first 50 addresses for static assignments. DHCP handles the rest. Track static assignments somewhere — a spreadsheet, a text file, whatever. phpIPAM and NetBox exist if you want something fancier, but a spreadsheet is fine and you’ll actually maintain it.

Run Your Own DNS

A local DNS server is one of the most practical services you can run. I use Pi-hole in a Docker container on the lab VLAN as DNS for all VLANs. It gives you:

  • Ad blocking across every device on every VLAN
  • Local DNS records so you can reach things by name (proxmox.lab.home) instead of memorizing IPs
  • Visibility into what’s making DNS queries and where traffic goes

Point each VLAN’s DHCP config at your Pi-hole. Set a public resolver (like 1.1.1.1) as the secondary so the house doesn’t lose internet if Pi-hole goes down while you’re tinkering with it.

Order of Operations

If I were starting over:

  1. Get a managed switch — even the TL-SG108E → is enough
  2. Set up OPNsense or pfSense on dedicated hardware or a VM
  3. Create two VLANs (lab and home) — expand later
  4. Write firewall rules — deny all between VLANs, open what you need
  5. Set up Pi-hole or AdGuard Home with local DNS records
  6. Document the whole thing

You don’t need to do this in a weekend. I built my setup over a few months. The most important step is getting that first boundary between your lab and your home network. Everything else builds from there.