# The Homelab Networking Stack: Reverse Proxies, VLANs, and Trust

> Exposing one service teaches you TLS. Exposing ten teaches you reverse proxies, DNS, network segmentation, and the uncomfortable truth that your smart bulbs are on the same wire as your NAS. A field guide to the plumbing.

URL: https://harshith.in/blog/self-hosting-networking-stack/
Author: Harshith Sunku (Staff Engineer) — https://harshith.in/about/
Tags: networking, security, systems

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:

```mermaid
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.