Networking Basics
How your router, DHCP, and local DNS fit together, and why port forwarding is the first real risk this guide asks you to think carefully about.
You don't need to become a network engineer for this tier, but a few concepts make everything from here on click into place.
Your router's three jobs, for homelab purposes
- DHCP - hands out IP addresses to devices as they join the network. This is where you'll set the DHCP reservation mentioned in Initial Server Setup, so your server always gets the same address.
- DNS - translates hostnames to IP addresses. By default this is forwarded to your ISP; pointing it at Pi-hole/AdGuard instead (see First Services) is what makes ad blocking apply to every device on the network without per-device configuration.
- NAT / port forwarding - by default, nothing on the internet can initiate a connection to a device on your home network; NAT only allows replies to connections your devices started. Port forwarding is an explicit rule that punches a hole through that, letting inbound connections reach a specific device and port.
DHCP reservations vs. static IPs
Two ways to give your server a consistent address:
- Static IP on the device - configured on the server itself. Works, but the router doesn't know about it, so nothing stops a lease collision, and you have to remember it's configured that way if you ever reimage the machine.
- DHCP reservation on the router - the router always hands the same IP to that device's MAC address, but the device itself still just uses ordinary DHCP. This is the better default: one place (the router) to see and manage every reserved address on your network.
Local DNS names instead of remembering IPs
Once you have a handful of services, http://192.168.1.50:8096 gets
old. Pi-hole and AdGuard Home both let you add local DNS records -
e.g. jellyfin.home pointing at your server's IP - so you can use a
name instead. This becomes more powerful with a reverse proxy in
Intermediate, where each
service gets its own clean hostname without a port number at all.
Port forwarding: understand the risk before using it
Forwarding a port exposes whatever's listening on it directly to the entire internet, not just to you. That server will be found and probed by automated scanners within hours of the port opening, regardless of how obscure you think your setup is.
⚠️ Risk: do not port-forward a service you haven't deliberately hardened, and do not forward SSH (port 22) directly. If you need remote access to your homelab, use a VPN approach instead - covered properly in Remote Access once you're in Intermediate. It's a safer default than port forwarding for nearly every homelab use case, and it's not meaningfully harder to set up.
If you do decide a specific service genuinely needs to be public (a personal blog, for instance), that's a deliberate, narrow decision about one service - never a router-wide posture, and it should sit behind a reverse proxy with TLS rather than being forwarded raw. See Reverse Proxy and TLS.
Checking what's actually listening
From the server itself, confirm what's bound to which port before you assume anything about exposure:
sudo ss -tulpn
Anything listening on 0.0.0.0 is reachable from other devices on
your LAN; 127.0.0.1 means local-machine-only. Neither of those is
internet-facing on its own - that only happens if you explicitly
forward the port on the router.
Next: Backups 101.