Can you help me set up a reliable homelab network?

General
1

I’m trying to build a small homelab for learning and testing things like virtualization, self-hosted services, and maybe a NAS, but I’m confused about the best way to design the network side of it. I’m not sure how to handle VLANs, subnetting, firewall rules, or separating my homelab from my main home devices. I’d really appreciate specific advice on what hardware, basic network layout, and configuration steps I should use so I don’t break my existing home internet setup.

2

Here is a solid, simple homelab network plan that works well for learning and avoids headaches.

  1. Start with the basics
    Router from ISP in bridge or passthrough mode if possible.
    Your own router or firewall behind it.
    Example: inexpensive box running OPNsense or pfSense, or something like a UniFi Dream Machine.

  2. Use VLANs from day one
    At least three networks. Use /24 for all for simplicity.

  • LAN: 192.168.10.0/24 for your normal devices.
  • LAB: 192.168.20.0/24 for homelab servers, hypervisors, containers.
  • GUEST / IOT: 192.168.30.0/24 for random stuff, TVs, smart plugs.

On the router:

  • Create interfaces for each VLAN.
  • Enable DHCP on each.
  • Set firewall rules:

LAN → anywhere: allow.
LAB → internet: allow.
LAB → LAN: block by default, add specific allow rules if needed (like SSH or RDP from your main PC).
GUEST/IOT → internet: allow.
GUEST/IOT → LAN or LAB: block.

  1. Get a managed switch
    You need at least one managed switch that speaks 802.1Q VLAN tagging.
    Example: TP-Link TL-SG2008, UniFi Switch Lite 8, Mikrotik CSS326, etc.

Configure ports:

  • Port to router: trunk, VLANs 10, 20, 30 tagged.
  • Port to access point: trunk, same VLANs tagged, then map SSIDs to VLANs.
  • Ports to servers: either
    • a trunk if you want multiple VLANs to a hypervisor, or
    • access port for a single VLAN like LAB.
  1. Wireless setup
    Get one access point or a router with AP mode.
    Create multiple SSIDs:
  • “Home” on VLAN 10.
  • “Lab” on VLAN 20 if you want lab-only wifi.
  • “Guest” on VLAN 30.
  1. Hypervisor layout
    On Proxmox, ESXi, or similar:
    Create virtual bridges for VLAN-tagged networks.
    Example Proxmox:
  • vmbr0 on physical NIC, tagged.
  • VLAN 20 bridge for most lab VMs.
  • VLAN 30 bridge for IOT experiments.
    Then assign VM NICs to the proper bridge or tag.
  1. Storage and NAS
    Put the NAS on LAB VLAN 20.
    Create NFS/iSCSI for hypervisor.
    Create SMB shares for your real devices.

Access rules example:

  • LAN → NAS: allow CIFS/SMB and web UI.
  • LAB → NAS: allow NFS, iSCSI, SMB.
  • GUEST/IOT → NAS: block.
  1. DNS and split-horizon
    Run local DNS on the router or on a small VM.
    Examples: AdGuard Home, Pi-hole, Unbound.
    Create local records such as
    nas.lab.local → 192.168.20.10
    proxmox.lab.local → 192.168.20.11

Point DHCP on each VLAN to that DNS.

  1. Remote access from outside
    Use WireGuard or OpenVPN on the edge router or a small VM on LAB.
    Do not port forward random web UIs to the internet.
    Expose only the VPN port.
    Clients connect to VPN, get an IP on a VPN subnet.
    Then access Proxmox, NAS, etc as if you were at home.

  2. Backups and snapshots
    For learning, you will break stuff.

  • Enable Proxmox or ESXi snapshots.
  • Back up config of your router / switch after you get things stable.
  • Back up the NAS to an external drive or cloud.
  1. Hardware sizing example
    For a small but solid lab:
  • Router/firewall: small x86 box, 4 cores, 8 GB RAM, 2+ NICs.
  • Switch: 8 port managed.
  • AP: 1 or 2 units depending on your house.
  • Server:
    • CPU: 6–8 cores.
    • RAM: 32–64 GB.
    • Storage: 1 SSD for OS, 2–4 HDDs for NAS / ZFS, plus 1 NVMe for VM storage.
  1. Simple IP plan example
    LAN: 192.168.10.0/24, GW .1, DHCP .50–.200
    LAB: 192.168.20.0/24, GW .1, DHCP .50–.200
    GUEST: 192.168.30.0/24, GW .1, DHCP .50–.200

Reserve static IPs below .50 for key devices.

  1. Typical “starter” ruleset
    On router firewall:

From LAN:

  • allow to LAB
  • allow to GUEST
  • allow internet

From LAB:

  • allow internet
  • allow NAS on ports 2049, 445, 111, 3260 and web UI
  • allow SSH to hypervisor hosts
  • deny rest to LAN

From GUEST:

  • allow internet
  • deny to LAN
  • deny to LAB

This keeps your daily devices safe from your experiments.

If you want HA or fancier stuff later, start with a single everything, then add:

  • Second hypervisor node for Proxmox cluster.
  • Shared storage on NAS.
  • Separate management VLAN for switches routers hypervisors.

Do the simple version first. Once it feels boring, scale it up.

3

If @kakeru’s layout is the “textbook” lab, here’s the slightly messier, more pragmatic version that might fit better if you’re just starting and don’t want to drown in VLAN configs on day 1.

I’ll actually disagree with them on one thing: you don’t need VLANs from day one to learn a ton. They’re great, but they add mental load. You can phase them in.

Phase 0: Keep it stupid simple

  1. Use your existing router for now.
  2. Get a single small managed switch (8‑port is fine).
  3. Plug in:
    • Router LAN port → Switch
    • Hypervisor / server → Switch
    • NAS → Switch
    • Desktop → Switch

All on a single subnet like 192.168.1.0/24. Use DHCP from your router.
Static IPs: reserve a few at the top/bottom (e.g. 192.168.1.10 = hypervisor, .11 = NAS).

This is “flat” and not “ideal,” but you’ll actually start doing stuff instead of re-reading VLAN docs forever.

Phase 1: Basic security / sanity

Before touching VLANs, fix these:

  • Turn off UPnP on the router.
  • Don’t forward random ports to Proxmox, NAS, etc.
  • Use strong passwords and 2FA where possible.
  • Change web UI ports off their defaults if you can.

For external access, I’m with @kakeru: use a VPN. If your router cannot do WireGuard or OpenVPN easily, spin up a small VM in the lab subnet and port forward only the VPN port. That’s it.

Phase 2: “Soft” separation without VLANs

You can simulate some isolation with just firewall rules:

  • Keep everything on 192.168.1.0 for now.
  • Put lab servers above .100, “normal” devices below .50.
  • On the router, if it supports it, create rules like:
    • Block NAS UI from everything except your main desktop IP.
    • Allow NAS data ports (SMB/NFS) from lab + desktop.
    • Optionally block certain lab IPs from talking to random IoT junk.

You won’t get full segmentation, but you will at least avoid “every stupid experiment can see everything.”

Phase 3: Introduce one VLAN

Here’s where I diverge a bit from the multi‑VLAN hype. Instead of three at once, start with one extra network just for the lab:

  • VLAN 20 → “LAB” network, say 192.168.20.0/24.
  • Make your router handle:
    • DHCP for 192.168.20.0.
    • Basic rules:
      • LAB → internet: allow.
      • LAB → main LAN: deny, except to NAS and maybe your desktop.

On the switch:

  • Router port: trunk (untagged VLAN for LAN, tagged 20).
  • Hypervisor port: trunk with VLAN 20 tagged.
  • Everything else stays in the default VLAN (LAN).

On the hypervisor (Proxmox/ESXi):

  • One bridge for LAN, one for VLAN 20.
  • New VMs for “experiments” go to VLAN 20.
  • Important infra (like your DNS, future AD, etc.) you can decide later where to live.

You can create more VLANs later (GUEST, IOT, MGMT) once the single extra VLAN concept feels boring.

Phase 4: Management & naming

A trap people fall into is overbuilding:

  • Don’t start with a separate “management VLAN” unless you already know why you need it.
  • Instead, just:
    • Give your infra static IPs and write them down.
    • Run a local resolver (AdGuard Home, Unbound, etc.) and add records like:
      • proxmox.home → 192.168.20.10
      • nas.home → 192.168.1.50
    • Point DHCP to that DNS.

That alone makes life way nicer and teaches you DNS basics.

Phase 5: Monitoring & “is it dying?”

Reliable ≠ fancy. Reliable = you notice when stuff breaks.

  • Put a tiny VM on the lab VLAN running:
    • Ping/HTTP checks to: router, NAS, hypervisor, DNS, etc.
    • Something like Uptime Kuma, Zabbix, or even a cron + email.
  • Set email / Telegram / whatever alerts if something is down.

You’ll learn more from debugging one real outage than from diagramming six hypothetical VLANs.

Hardware take:

  • Start with a single decent server + a NAS (or a single box doing both via ZFS).
  • Don’t overbuy routers just to run pfSense/OPNsense unless:
    • Your current router is trash, or
    • You specifically want to learn firewall stuff.

You can always move from ISP-router + managed switch → dedicated firewall later. No need to jump straight to “mini datacenter” on day 1.

TL;DR design sketch

  • Phase 0: One subnet, one switch, one router. Learn hypervisor, backups, Docker.
  • Phase 1: Lock down basics (no exposed web UIs, no UPnP).
  • Phase 2: Use IP ranges + firewall rules to fake some isolation.
  • Phase 3: Add one VLAN for the lab. Learn trunks and tagged ports.
  • Phase 4+: Add more VLANs and fancy stuff when this feels boring, not before.

Get something running, then iterate. The “perfect” design will change as soon as you actually use the lab for a few months.

4

You already got two solid blueprints from @sternenwanderer and @kakeru, so I’ll zoom in on a different angle: how to keep this “reliable” when you start breaking stuff on purpose.

1. Decide what must never go down
Before touching VLANs or firewalls, write a tiny list:

  • Internet for the house
  • NAS data (photos, docs)
  • VPN in from outside
    Treat those as “protected.” Everything else is sacrificial.

2. Physically separate “always on” from “experimental”
Instead of more VLANs, use more NICs and ports:

  • One NIC from your router or firewall to a small unmanaged switch for family / daily devices.
  • Another NIC to the managed switch where your homelab lives.
    Even if you nuke routing on the lab side, home internet still works. This is boring and extremely reliable.

3. Put your hypervisor behind a jump box
Rather than opening Proxmox/ESXi UI to your whole LAN, run:

  • One small VM as a “management” jump box with SSH / RDP.
  • Only your desktop can reach that VM.
  • Hypervisor UI and NAS UI are only reachable from that VM.
    You get a natural workflow: “log into jump box, then manage everything.” Great practice for real environments and safer than wide-open UIs.

4. Logging and rollback first, experiments second
Both replies already mentioned backups. I’d add:

  • Central syslog or a simple log collector VM.
  • Version control for configs (router exports, Ansible playbooks, Docker compose files).
    If you break routing in your OPNsense/pfSense box at 1 AM, a known good config file is worth more than fancy VLAN layouts.

5. About VLANs: use them, but do not tie reliability to them
I side slightly with @kakeru here: you can start without them. When you add them:

  • Assume VLANs are for cleanliness and security, not core reliability.
  • Test changes on a single lab port first, never on the trunk that feeds your AP and main switch at the same time.
    Otherwise one mis-tag and you are on a ladder debugging why Wi‑Fi is dead.

6. “High availability” in a homelab is mostly about spares
Everyone dreams of clusters. In practice:

  • One extra cheap switch on a shelf beats an early Proxmox cluster if your main switch dies.
  • A spare router or an old Wi‑Fi unit in AP mode restores the house quickly.
    You can still play with clustering, but don’t confuse “cool” with “reliable.”

7. On products like ’
If you consider something in the category of ', treat it as a convenience layer, not magic:

  • Pros: usually easier UI, quick setup, nice dashboards, sometimes app stores or container templates.
  • Cons: can hide complexity, harder to migrate away from, sometimes opinionated defaults that fight with custom firewalling.
    Use it if it helps you start faster, but keep understanding at the router, switch and hypervisor level so you are not locked in.

8. Comparing approaches briefly

  • @sternenwanderer gave you the “methodical, phase based” growth path that keeps mental overhead lower. Great if you want to ease into networking.
  • @kakeru outlined a more structured, VLAN heavy design that feels like a small enterprise network. Good for learning how proper segmentation works.

You do not have to pick one camp. Combine them:

  • Physically separate home vs lab for reliability.
  • Add a single LAB VLAN on the lab side for practice.
  • Use a jump box and logging so you can screw up safely.

That mix gets you a network you can learn on without your NAS, partner or roommates revolting every time you try something new.