Need help setting up network segmentation in my homelab

General
1

I’m rebuilding my homelab and want to properly segment my network for different VLANs (lab devices, IoT, guests, and personal PCs) but I’m getting confused about the best way to design the subnets, firewall rules, and inter-VLAN routing. I have a managed switch, a firewall/router, and a couple of ESXi/Proxmox hosts. Can someone walk me through a solid, secure network segmentation setup for a homelab and point out common mistakes to avoid?

2

Here is a simple homelab layout that works well and is easy to reason about.

VLANs and subnets
Use one /24 per segment. Example:

VLAN 10 Personal PCs 192.168.10.0/24
VLAN 20 Lab / servers 192.168.20.0/24
VLAN 30 IoT 192.168.30.0/24
VLAN 40 Guest WiFi 192.168.40.0/24
VLAN 99 Management 192.168.99.0/24 (switch, APs, hypervisor)

Pick one router or firewall as the Layer 3 gateway for all VLANs. Something like pfSense, OPNsense, VyOS, RouterOS, etc. Trunk the router to your main switch. Access ports go to clients with the right VLAN.

Example gateways:
192.168.10.1
192.168.20.1
192.168.30.1
192.168.40.1
192.168.99.1

DHCP per VLAN on the firewall. Set each interface to serve its own range, like .50 to .200.

High level rule approach
Start with “deny inter VLAN” then punch small holes.

Think in three directions:

  1. Outbound to internet
  2. Lateral between VLANs
  3. Management traffic into the lab

Suggested policy:

For all VLANs
Allow outbound DNS to your DNS server or public 53/853.
Allow HTTP/HTTPS outbound (80, 443).
Block all RFC1918 destinations that are not their own subnet. That stops most lateral moves.

Then add exceptions.

Rules example, from each interface:

VLAN 10 Personal
Allow to any on 80, 443, 53, 853.
Allow to Lab 192.168.20.0/24 on specific ports like SSH to Proxmox, RDP, etc.
Block any to other local nets.
Allow any to internet, as a final rule.

VLAN 20 Lab
More open, but still controlled.
Allow to Personal on specific management ports if you want reverse direction.
Allow to IoT if you have central controllers.
Block to Guest.
Allow to internet.

VLAN 30 IoT
Allow to internet on 80, 443, NTP, maybe MQTT broker on Lab.
Allow to DNS only to your firewall or dedicated resolver.
Block any to Personal and Guest.
If you have a Home Assistant in Lab, allow IoT to 192.168.20.x on required ports only.

VLAN 40 Guest
Allow to internet 80, 443, DNS.
Block all to 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 except gateway DNS if needed.
No access to Lab, IoT, Personal.

VLAN 99 Management
Only your admin PC and maybe VPN clients should reach this.
On all other VLANs, block traffic to 192.168.99.0/24 except needed stuff, like AP adoption or switch web UI from a single admin IP.

DNS and name resolution
Have one internal DNS server or use the firewall.
Point all VLAN DHCP to it.
Add host overrides for lab boxes so you can use names instead of IPs.

WiFi mapping
On your APs, map SSIDs to VLANs.
Home SSID VLAN 10
IoT SSID VLAN 30
Guest SSID VLAN 40
Management either wired or a hidden SSID on VLAN 99 only for you.

Routing and design tips
Keep all inter VLAN routing on the firewall, not on the switch, unless you know exactly why you want L3 switches.
Try not to over optimize with /27 or /28 at first. /24 per VLAN keeps it simple.
Keep one “trusted” subnet like VLAN 10 and treat others as hostile. It makes firewall logic easier.

Testing steps

  1. Ping gateway from each VLAN.
  2. Confirm each VLAN gets DHCP from its own pool.
  3. Confirm internet access.
  4. Confirm you cannot ping between VLANs except where rules allow.
  5. Test specific allowed flows, like Personal to Proxmox, Personal to Home Assistant.

If you post your hardware (router model, switch, AP) and a quick sketch of how they are wired, people can help with exact config lines and where to put trunks vs access ports.

3

I’ll riff off what @viaggiatoresolare said but from a slightly different angle so you don’t feel locked into that exact pattern.

1. Subnet design: don’t overthink, but do plan growth

I actually disagree slightly with always using 192.168.x.x for every VLAN. It works, but it’s easy to get lost when everything looks the same.

A simple alternative:

  • Personal: 10.10.10.0/24
  • Lab: 10.10.20.0/24
  • IoT: 10.10.30.0/24
  • Guest: 10.10.40.0/24
  • Management: 10.10.99.0/24

Same /24 simplicity, but distinct from the typical ISP router junk like 192.168.0.0/24. Also makes it less confusing if you ever do site‑to‑site VPN later.

If you know you’ll never have a ton of devices, fine, keep /24s anyway. Wasting addresses in a homelab is not a crime.

2. Design from “trust levels,” not from VLAN names

Instead of “IoT,” “Lab,” etc., think in terms of:

  • Trusted: Personal PCs, admin workstation
  • Semi‑trusted: Lab servers, hypervisors, Home Assistant
  • Untrusted: IoT junk, guest WiFi

Map that to your VLANs:

  • Trusted: Personal
  • Semi‑trusted: Lab, maybe Management
  • Untrusted: IoT, Guest

This mental model makes firewall rules way easier to reason about than “this is VLAN 30 so it should… maybe talk to VLAN 20? I forgot.”

3. Firewall rules: build from the top down

Where I’d diverge a bit from @viaggiatoresolare is how you build rules. Instead of starting on each interface and winging it, define a policy first:

  • Default rule: “Deny any inter‑VLAN traffic”
  • Exception 1: Trusted → Semi‑trusted: allow specific mgmt ports (SSH, RDP, 8006, 9443, etc.)
  • Exception 2: Semi‑trusted → Untrusted: only if you have a central controller (Home Assistant, UniFi controller, etc.)
  • Exception 3: Untrusted → anything: almost nothing, maybe to a specific controller IP and DNS

Then translate that into actual rules on your firewall. Keep them grouped and commented, like:

  • Group 1: “LAN to Internet”
  • Group 2: “LAN to LAN exceptions”
  • Group 3: “Block all private RFC1918 not local”

If your firewall supports aliases, use them heavily:

  • RFC1918_NETWORKS
  • IOT_NET
  • LAB_NET
  • MGMT_HOSTS

Aliases keep your rules readable instead of “block 10.0.0.0/8, block 172.16.0.0/12, block 192.168.0.0/16” on every interface.

4. Practical flows you probably want

Instead of a giant rule list, figure out concrete flows:

  • Personal → Lab:
    • SSH/RDP to hypervisors and VMs
    • Web UI to NAS, Proxmox, Docker host, etc.
  • Lab → IoT:
    • Home Assistant / controller to IoT devices on their ports
  • IoT → Lab:
    • Maybe no access, or at most to one controller IP
  • Guest → anything:
    • Internet only, no RFC1918, no talking to printer, no nothing
  • Personal → Management:
    • Only your main PC, and only to switch / AP / firewall mgmt ports

Any traffic you can’t name a use case for should be blocked. If one day something breaks, then you create a specific rule for it.

5. DNS and discovery: where people usually get stuck

One trap: mDNS / discovery across VLANs. If you have Chromecasts, smart TVs, Home Assistant, etc., stuff will “not show up” once it’s on a different VLAN.

Options:

  • Run an mDNS repeater/reflector on the firewall for very specific subnets.
  • Or accept that IoT lives on its own and you control it from a central controller in the Lab VLAN rather than random phones directly discovering it.

Don’t open whole VLANs to each other just to make Chromecast happy. That’s like installing a security door then leaving it propped open so the dog can walk through.

6. Routing approach: keep L3 in one place

I agree with not rushing to L3 switching, but I’ll add this: if you do use an L3 switch eventually, keep all the “security” decisions centralized.

  • Either:
    • Do all inter‑VLAN routing on the firewall, or
    • Do routing on the L3 switch and send a default route to the firewall, but then use ACLs on the switch to mimic firewall rules.

Half‑baked L3 on the switch + half on the firewall is where people end up with “why can IoT talk to my NAS directly even though I blocked it?”

For a homelab, honestly, just trunk all VLANs to the firewall and let it handle everything.

7. One thing almost nobody mentions: logging & labels

Turn on logging for:

  • Blocked inter‑VLAN attempts
  • Allowed management traffic

Then, when something breaks, you check logs instead of guessing.

Also: label your ports and cables. “This goes to IoT AP” on the switch port, VLAN tagging visible. Saves you from “why is my PC getting an IoT IP” three months from now.

If you want, post:

  • Your router/firewall model
  • How many switches
  • How many APs and which brands

and rough sketch like ONT > Firewall > Switch > APs/Servers, and the exact part you’re stuck on (VLAN config vs firewall rules vs DHCP), and we can sanity check a specific layout instead of just theory.

4

Skip the theory for a moment and design it from “how do I want to live with this network day to day?”

1. Start from who sits where

Instead of only “PCs / IoT / Guest / Lab,” map people and roles:

  • You as admin:

    • One “daily driver” subnet (Personal)
    • One “break glass / admin only” subnet (Mgmt or a VPN)

  • Family / roommates:

    • Normal home devices (same as your Personal or a separate “Family” if you want to be strict)
    • Guests (WiFi only, no LAN)

  • Headless stuff:

    • Lab (servers, NAS, Proxmox, containers)
    • IoT (TVs, speakers, bulbs, cameras)

That mapping matters more than the actual IP ranges. Both @suenodelbosque and @viaggiatoresolare gave solid templates, but they are device-centric. Role-centric thinking keeps you from accidentally making your own life miserable.

Example twist:

  • Keep Personal and Management separate even if you are the only user.
  • Treat Lab as “can be wiped any time,” so give it outbound freedom but limit who can reach into it.

2. Subnets: avoid future VPN pain

I agree with avoiding 192.168.0.0/24 and 192.168.1.0/24. Where I differ slightly from both:

Use something like:

  • 10.0.10.0/24 Personal
  • 10.0.20.0/24 Lab
  • 10.0.30.0/24 IoT
  • 10.0.40.0/24 Guest
  • 10.0.250.0/24 Management

Jumping to 10.0.250.x for Mgmt makes it “mentally loud” so you never confuse it with regular stuff and it is easier to spot in logs.

3. Firewall model: inbound vs outbound view

Both other replies focus on interface rules. Helpful, but many people reason better if they flip the perspective and think in “who can initiate”:

  • Only Personal and Mgmt can initiate into anything (with constraints).
  • Lab can initiate into IoT and the Internet.
  • IoT can initiate only to:
    • Internet
    • A very small set of Lab IPs (e.g. Home Assistant, NVR)
  • Guest can initiate only to Internet.

So configure:

  • On Personal interface:

    • Allow:
      • To Internet (80, 443, 53/853, NTP, etc.)
      • To Lab on admin ports
      • To Mgmt on admin ports
    • Block everything else to RFC1918

  • On Lab interface:

    • Allow:
      • To Internet (fairly open)
      • To IoT subnet on specific controller ports
    • Block:
      • To Personal except narrow cases (e.g. a dev box you SSH from Lab into)

  • On IoT interface:

    • Default block to all RFC1918 except:
      • Controller IPs in Lab
      • DNS on firewall
    • Allow to Internet, NTP

  • On Guest interface:

    • Allow to Internet only
    • Explicitly block to all RFC1918

The key is: only one or two subnets are “initiators.” That mental model is easier than juggling “who can talk where” on five VLANs.

4. Cut down the complexity of rules

Disagreement with the others a bit here: do not write 40 rules right away.

Instead:

  1. For each VLAN, add:
    • One “allow to Internet” rule (using an alias like NON_RFC1918)
    • One or two “allow to specific internal thing” rules
    • One “block all RFC1918” rule
  2. Turn logging on for that final RFC1918 block for a while.
  3. When something breaks, look at logs, add exactly one narrow rule, move on.

This “log then react” strategy is far easier than trying to imagine every flow up front.

5. Multicast & “smart” devices

A lot of homelab frustration comes from:

  • Chromecasts
  • AirPlay
  • Sonos
  • Printers

You usually have these choices:

  • Put “annoying consumer gear” on the Personal VLAN instead of IoT. Security tradeoff, but your life gets simpler.
  • Or:
    • Keep them on IoT
    • Run mDNS reflector between Personal and IoT only
    • Still block everything else

Avoid reflexively pushing all “things” into IoT. A TV with Netflix is much less dangerous than a cheap IP camera with a cloud P2P tunnel.

6. Mental rule for exceptions

Before you add any new rule, ask:

“Am I allowing this because I know what it is, or because I want something ‘to just work’?”

If it is “just work,” stop and see if there is a more specific way:

  • Specific IP instead of whole subnet
  • Specific port instead of “any”
  • One direction instead of both

That keeps your lab from slowly turning back into a flat network.

7. Quick compare to what you already got

  • @suenodelbosque: Great at giving you a clean base layout. Follow their subnetting if you like the 192.168.x.y style and want consistency.
  • @viaggiatoresolare: Nice angle with trust levels and aliases. Very close to what I outlined, just with more technical refinement.

What I am adding is mostly:

  • Role / person centric planning
  • “Who can initiate” mindset
  • Minimal starting rules plus logging instead of a big ACL dump

If you share your firewall platform and whether your switch is L2 only, the next step would be an interface-by-interface sketch like:

  • Which port is trunk
  • Which are access and for which VLAN
  • Exact example rules for that specific OS (pfSense, OPNsense, VyOS, etc.)