A homelab is where systems knowledge stops being theoretical, because you own every layer and every misconfiguration is yours to debug. Running one properly — a NAS, a few containers, some IoT junk, remote access — forces you to build, in miniature, the same networking architecture a small company runs: reverse proxying, name resolution, segmentation, and a real answer to “how do I reach this from outside without exposing it to everyone.” Here’s the plumbing, in the order the problems arrive.

Problem 1: One IP, Many Services → Reverse Proxy

You have one LAN IP (or one public one) and ten services that all want port 443. The reverse proxy (Caddy, Traefik, nginx) is the switchboard: one process owns 80/443 and routes by hostname (SNI/Host header) to the right backend:

flowchart LR
    C[client: nas.home] --> P[reverse proxy :443]
    C2[client: grafana.home] --> P
    P -- Host: nas.home --> B1[NAS :5000]
    P -- Host: grafana.home --> B2[Grafana :3000]

This is the same name-based virtual hosting the whole web runs on, and it earns its place immediately: one place to terminate TLS (Caddy/Traefik auto-provision Let’s Encrypt certs, including via DNS-01 challenges so you can get valid certs for internal names that aren’t internet-reachable — the trick that ends self-signed-cert warnings forever), one place for auth middleware and access logging, and backends that can stay plain HTTP on a trusted segment. The moment you have more than two services, not having a reverse proxy is the mistake.

Problem 2: Names → Internal DNS

https://192.168.1.47:5000 doesn’t scale in your head or your certs. Internal DNS (Pi-hole, AdGuard, or your router) maps nas.home to the proxy, so every service gets a real hostname, certs match, and bookmarks survive IP changes. Split-horizon DNS (internal names resolve to internal IPs, the same names optionally resolvable externally through the VPN) is the clean setup — and running your own resolver doubles as network-wide ad/tracker blocking, which is how most people get talked into it.

Problem 3: Trust → Segmentation

Here’s the uncomfortable audit: by default, your smart bulb, your guest’s phone, your NAS full of backups, and that IoT camera with firmware from 2019 and a hardcoded password are all on one flat network, able to talk to each other freely. A single compromised cheap device has lateral reach to everything. The professional answer, scaled to home, is VLAN segmentation — separate layer-2 domains with firewall rules governing what may cross:

  • Trusted — your workstations, NAS.
  • IoT — smart-home junk, no internet-outbound except what it needs, and critically no route to Trusted. Bulbs don’t need to reach your backups.
  • Guest — internet only, isolated from everything internal.
  • DMZ/services — anything internet-exposed, firewalled off from the internal segments so a compromised public service can’t pivot inward.

This is defense in depth made concrete: you assume the IoT segment will be compromised and ensure the blast radius stops at a firewall rule. It requires a VLAN-aware switch and a router that does inter-VLAN firewalling (OPNsense/pfSense, VyOS, or a capable prosumer box), and it is the single biggest security upgrade a homelab can make — far more than any amount of hardening on individual boxes.

Problem 4: Remote Access → VPN, Not Port-Forwarding

The instinct is to port-forward each service to the internet. Don’t: every forwarded port is attack surface exposed to the entire internet’s background scan traffic (which finds a new service within minutes — watch your logs). The right model is a single encrypted door: a WireGuard (or Tailscale/Netbird mesh) tunnel. Remote clients join the network over one authenticated, encrypted UDP port and reach internal services as if local — nothing else is exposed, auth happens at the tunnel, and WireGuard’s tiny attack surface and PersistentKeepalive (there’s that NAT-timeout number again) make it robust through carrier-grade NAT. Reserve actual public exposure (proxy + WAF + strong auth) for the handful of things that genuinely must be reachable without a client.

The meta-lesson of the whole stack: place trust boundaries deliberately and put a controlled chokepoint at each one — the proxy for HTTP, the firewall between VLANs, the VPN for remote entry. That’s not homelab-specific advice; it’s the same architecture as any corporate network, which is exactly why building one is the best networking-and-security education available for the price of a managed switch.

Takeaways

  • A reverse proxy is the first upgrade: hostname routing, one TLS termination point (DNS-01 gets valid certs for internal names), one place for auth and logs.
  • Internal DNS gives services real names so certs and bookmarks work; a local resolver blocks ads network-wide as a bonus.
  • Flat networks give a compromised IoT device lateral reach to everything — VLAN segmentation (Trusted/IoT/Guest/DMZ with inter-VLAN firewalling) is the biggest security win available.
  • Don’t port-forward services; expose one WireGuard/mesh-VPN door and reach everything internally through it.
  • The pattern is universal: identify trust boundaries, put a controlled chokepoint at each — a homelab teaches enterprise architecture hands-on.