Homelab Network School
Everything you need to understand your network — IPs, DNS, ports, VLANs, HTTPS, and Wireguard.
Built around your actual stack. Pick a topic below.
IP Addresses
Octets, private vs public ranges, subnet masks, CIDR notation. Why your server is 192.168.x.x and what every number means.
6 concepts covered
DNS
How name resolution works, record types (A, CNAME, TXT, PTR), Pi-hole as your network resolver, and local DNS for your services.
8 concepts covered
Ports
Well-known ports, every port your homelab services use, port forwarding in pfSense, TCP vs UDP. The apartment-number analogy.
20+ ports mapped
VLANs & DHCP
Network segmentation, DHCP leases, static IPs, your four VLANs (Private / Guest / IoT / CCTV) and firewall rules between them.
4 VLANs designed
HTTPS & Nginx
HTTP vs HTTPS, TLS handshake, how Nginx Proxy Manager reverse-proxies all your services, and free Let's Encrypt certs via DuckDNS.
5 concepts covered
Wireguard VPN
How Wireguard works, tunnels vs port forwarding, OPNsense integration, client setup, and reaching your homelab from anywhere securely.
6 concepts covered
IP Addresses
An IP address is a 32-bit number that identifies every device on a network.
Written as four numbers (octets) separated by dots. Every number is 0–255.
Anatomy of an IP Address
192.168.1.42
Four octets — each 0–255 (8 binary bits). Total: 32 bits = IPv4.
Each octet is 8 binary bits. 2⁸ = 256 possible values (0–255). Four octets = 2³² = ~4.3 billion possible IPv4 addresses.
Breaking it down
192.168 # fixed prefix — marks this as a private Class C address
1 # subnet — your network number inside 192.168.x.x
42 # host — this specific device. .1 is almost always your router
1 # subnet — your network number inside 192.168.x.x
42 # host — this specific device. .1 is almost always your router
In binary
192 = 11000000
168 = 10101000
1 = 00000001
42 = 00101010
168 = 10101000
1 = 00000001
42 = 00101010
Network part vs Host part
The subnet mask tells you which octets identify the network and which identify the device.
In a /24 network (255.255.255.0), the first three octets = network, the last = host. Every device on 192.168.1.x is on the same network. Devices on 192.168.2.x are on a different network and need a router to talk to each other.
192.168.1.100 # your server
192.168.1.50 # your gaming PC
192.168.1.1 # your router (always .1 by convention)
192.168.1.255 # broadcast — sent to every device on this subnet
192.168.1.0 # network address — "name" of this subnet, not assignable
192.168.1.50 # your gaming PC
192.168.1.1 # your router (always .1 by convention)
192.168.1.255 # broadcast — sent to every device on this subnet
192.168.1.0 # network address — "name" of this subnet, not assignable
Private vs Public Ranges
192.168.0.0 – 192.168.255.255
Class C private range — your home network lives here
This is the range reserved for home and small office networks. Your router assigns addresses from here via DHCP. These are NOT reachable from the internet without port forwarding.
192.168.1.0/24 # 254 usable addresses (.1 to .254)
192.168.10.0/24 # your planned Private LAN VLAN
192.168.20.0/24 # your planned Guest VLAN
192.168.30.0/24 # your planned IoT VLAN
192.168.40.0/24 # your planned CCTV VLAN
192.168.10.0/24 # your planned Private LAN VLAN
192.168.20.0/24 # your planned Guest VLAN
192.168.30.0/24 # your planned IoT VLAN
192.168.40.0/24 # your planned CCTV VLAN
10.0.0.0 – 10.255.255.255
Class A private range — 16 million addresses, used in enterprise and VPNs
Docker uses 172.16.0.0/12 (Class B private) for its default bridge network. Wireguard tunnels often use 10.x.x.x for tunnel IPs. Your containers talk to each other through Docker's internal 172.x.x.x addresses.
10.0.0.0/8 # entire Class A space — 16,777,214 hosts
172.16.0.0/12 # Class B — Docker bridge network lives here
127.0.0.1 # loopback — "myself." A service listening here is local-only
172.16.0.0/12 # Class B — Docker bridge network lives here
127.0.0.1 # loopback — "myself." A service listening here is local-only
Public IP — your WAN address
The address your ISP assigns your router. The world-facing identity of your house.
Everything coming FROM your network to the internet looks like this one IP. NAT (Network Address Translation) maps your private 192.168.x.x devices to this single public IP. Port forwarding works in reverse — traffic arriving at your public IP on specific ports gets routed to specific internal machines.
⚠️ Most ISPs give you a dynamic public IP — it changes periodically. DuckDNS solves this by updating dahamsterserver.duckdns.org to your current IP automatically.
curl ifconfig.me # check your current public IP from terminal
Subnet Masks & CIDR Notation
192.168.1.0/24
CIDR — "slash notation" for subnet masks. You'll type this constantly in pfSense and Docker.
The number after the slash = how many bits are the network part. The rest = host bits. More host bits = more addresses.
The ones you'll actually use
/32 = 255.255.255.255 # one single host — used in firewall rules
/24 = 255.255.255.0 # 254 hosts — your VLANs (192.168.10.0/24)
/16 = 255.255.0.0 # 65,534 hosts — Docker internal networks
/8 = 255.0.0.0 # 16 million — entire 10.x.x.x private space
/30 = 255.255.255.252 # 2 hosts — point-to-point links
/24 = 255.255.255.0 # 254 hosts — your VLANs (192.168.10.0/24)
/16 = 255.255.0.0 # 65,534 hosts — Docker internal networks
/8 = 255.0.0.0 # 16 million — entire 10.x.x.x private space
/30 = 255.255.255.252 # 2 hosts — point-to-point links
How to calculate hosts
hosts = 2^(32 - prefix) - 2
/24 → 2^8 - 2 = 254 hosts
/25 → 2^7 - 2 = 126 hosts
/16 → 2^16 - 2 = 65,534 hosts
/24 → 2^8 - 2 = 254 hosts
/25 → 2^7 - 2 = 126 hosts
/16 → 2^16 - 2 = 65,534 hosts
In pfSense you'll type 192.168.10.0/24 to define a VLAN. In Docker Compose you'll see subnet: 172.20.0.0/16. Same concept, different context.
ip addr show
See your server's IP addresses and subnet masks from the shell
ip addr show # all interfaces
ip addr show eth0 # just eth0
ip route show # routing table — shows your gateway
ip route | grep default # just the default gateway line
ping -c 4 192.168.1.1 # test if gateway is reachable
ping -c 4 8.8.8.8 # test internet (skips DNS)
ping -c 4 google.com # test internet + DNS
ip addr show eth0 # just eth0
ip route show # routing table — shows your gateway
ip route | grep default # just the default gateway line
ping -c 4 192.168.1.1 # test if gateway is reachable
ping -c 4 8.8.8.8 # test internet (skips DNS)
ping -c 4 google.com # test internet + DNS
DNS — Domain Name System
DNS translates hostnames into IP addresses. Every time you type a URL,
DNS runs before a single byte of content loads. Your Pi-hole controls this for your whole network.
How a DNS Lookup Works
Step 1 — Browser checks its local cache
Did we look this up recently? If yes, use the saved IP with no network request.
Every DNS answer comes with a TTL (Time To Live) — a number of seconds before the cache expires. This is why DNS changes take time to "propagate." Even if you update your DuckDNS record, old clients hold the old IP until their TTL runs out.
ipconfig /flushdns # Windows: clear DNS cache
sudo resolvectl flush-caches # Linux: clear DNS cache
sudo dscacheutil -flushcache # macOS: clear DNS cache
sudo resolvectl flush-caches # Linux: clear DNS cache
sudo dscacheutil -flushcache # macOS: clear DNS cache
Step 2 — Ask the configured DNS resolver
Your OS asks the DNS server handed out by pfSense via DHCP — that's Pi-hole.
pfSense's DHCP server tells every device on your network to use Pi-hole's IP as their DNS server. Every device auto-configures. Zero config needed on individual machines.
cat /etc/resolv.conf # Linux: see configured DNS server
nslookup jellyfin.home # test resolving a local name
dig jellyfin.home @192.168.10.5 # query Pi-hole directly
nslookup jellyfin.home # test resolving a local name
dig jellyfin.home @192.168.10.5 # query Pi-hole directly
Step 3 — Pi-hole checks blocklist + local records
Ad domains → blocked. Local names like jellyfin.home → returns your server's LAN IP directly.
Pi-hole's local DNS records let you create A records like jellyfin.home → 192.168.10.100. Every device on your network resolves it without knowing or caring about the port. Combine with Nginx Proxy Manager and everything gets a clean domain name over HTTPS.
✓ Add local DNS records in Pi-hole: Admin → Local DNS → DNS Records. Add a CNAME record pointing to your server's A record to cover all subdomains.
Step 4 — Forward to upstream: 1.1.1.1 or 8.8.8.8
Real internet domains go to Cloudflare or Google. Pi-hole forwards, caches the reply.
Configure Pi-hole to use Cloudflare 1.1.1.1 over DoH (DNS over HTTPS) for the upstream. This encrypts your DNS queries to Cloudflare so your ISP can't see what domains you're resolving — only that you're talking to 1.1.1.1.
Upstream DNS options
1.1.1.1 # Cloudflare — fast, privacy-respecting
1.0.0.1 # Cloudflare secondary
8.8.8.8 # Google — fast, but Google logs queries
9.9.9.9 # Quad9 — blocks malware domains too
1.0.0.1 # Cloudflare secondary
8.8.8.8 # Google — fast, but Google logs queries
9.9.9.9 # Quad9 — blocks malware domains too
DNS Record Types
A record — hostname → IPv4 address
The most common record. Maps a name to an IP. This is what you create in Pi-hole for local services.
jellyfin.home → 192.168.10.100 # A record in Pi-hole
r720.home → 192.168.10.100 # another name for the same IP
pihole.home → 192.168.10.5 # Pi-hole's own dashboard
r720.home → 192.168.10.100 # another name for the same IP
pihole.home → 192.168.10.5 # Pi-hole's own dashboard
CNAME record — alias → other hostname
Points one name to another name (not an IP). Chain CNAMEs to avoid maintaining many A records.
If your server's IP ever changes, you only update one A record. All CNAMEs pointing to it auto-update. Create one A record for your server, then CNAME all your services to that record.
server.home → 192.168.10.100 # one A record
jellyfin.home → server.home # CNAME
nextcloud.home → server.home # CNAME
navidrome.home → server.home # CNAME
jellyfin.home → server.home # CNAME
nextcloud.home → server.home # CNAME
navidrome.home → server.home # CNAME
This is the cleanest setup — one A record, all services as CNAMEs. Change the server IP once, everything follows.
TXT record — arbitrary text data
Used for domain verification, SPF/DKIM email security, and Let's Encrypt DNS challenges.
When you request a wildcard Let's Encrypt cert (*.yourname.duckdns.org), it proves domain ownership by asking you to add a specific TXT record. Nginx Proxy Manager does this automatically via the DuckDNS API.
_acme-challenge.yourname.duckdns.org → "randomstring123..." # Let's Encrypt proof
PTR record — IP → hostname (reverse DNS)
The reverse of an A record. Used in logs so you see hostnames instead of IPs.
When Frigate logs "motion detected from 192.168.40.12" it's nicer to see "frontdoor-cam". Pi-hole's local DNS can serve PTR records too. Mostly optional for homelab purposes.
dig -x 192.168.10.100 # reverse lookup — what hostname is this IP?
DNS Diagnostic Commands
dig jellyfin.home @192.168.10.5
Query a specific DNS server directly — essential for debugging Pi-hole
dig jellyfin.home @192.168.10.5 # ask Pi-hole specifically
dig google.com @1.1.1.1 # ask Cloudflare directly
nslookup jellyfin.home 192.168.10.5 # older but works everywhere
dig +short google.com # just the IP, no extra output
dig jellyfin.home +trace # full resolution chain
dig google.com @1.1.1.1 # ask Cloudflare directly
nslookup jellyfin.home 192.168.10.5 # older but works everywhere
dig +short google.com # just the IP, no extra output
dig jellyfin.home +trace # full resolution chain
Ports
An IP address gets you to the right building. A port number gets you to the right apartment.
Your server has one IP — ports tell traffic which of the dozens of services to talk to.
The Concept
192.168.10.100:8096
IP + port = full address. The colon separates them. This is how you reach Jellyfin.
Ports range 0–65535. Three ranges: 0–1023 are well-known (reserved for standard services), 1024–49151 are registered (apps claim by convention), 49152–65535 are dynamic (used for temporary outbound connections).
TCP vs UDP
TCP # connection-oriented. Reliable delivery. Web, SSH, Jellyfin, Nextcloud.
UDP # connectionless. Faster, no guarantees. Game servers, DNS (port 53), Wireguard.
UDP # connectionless. Faster, no guarantees. Game servers, DNS (port 53), Wireguard.
When you browse the web your browser opens a random high port (e.g. 54231) to talk to the server on port 443. The server responds to that random port. You never configured it — it's automatic.
Well-Known System Ports
:22 — SSH
Secure Shell — how you remotely control Linux servers via terminal
You will use this constantly. SSH into your R720xd, into VMs, into Docker hosts. Key-based auth is far safer than passwords — set it up early.
ssh user@192.168.10.100 # basic SSH
ssh -p 2222 user@192.168.10.100 # custom port
ssh-keygen -t ed25519 # generate key pair
ssh-copy-id user@192.168.10.100 # push public key (passwordless login)
ssh -p 2222 user@192.168.10.100 # custom port
ssh-keygen -t ed25519 # generate key pair
ssh-copy-id user@192.168.10.100 # push public key (passwordless login)
⚠️ Never expose port 22 directly to the internet. Use Wireguard to reach your LAN, then SSH from inside the tunnel.
:53 — DNS
All DNS queries go here. Pi-hole listens on port 53 for your entire network.
DNS uses both TCP and UDP on port 53. Most queries are UDP (small, fast). Large responses fall back to TCP. Your Pi-hole container must have port 53 exposed on both protocols.
ports:
- "53:53/tcp"
- "53:53/udp" # both required in docker-compose
- "53:53/tcp"
- "53:53/udp" # both required in docker-compose
:80 HTTP · :443 HTTPS
Web traffic. 80 = unencrypted. 443 = encrypted (TLS). Always redirect 80 → 443.
Nginx Proxy Manager listens on both. Port 80 should redirect to 443 automatically. Your ISP may block inbound 80/443 — check before setting up external access. Some ISPs require a business account for open inbound ports.
:67/68 — DHCP
Your pfSense DHCP server listens here to hand out IP addresses to all devices.
When a device joins the network it broadcasts on port 68 asking for an IP. pfSense (the DHCP server) listens on port 67 and responds with an IP, subnet, gateway, and DNS server. You never interact with these ports directly — it's automatic.
:51820 — Wireguard
Wireguard VPN default port (UDP). This is the one port you forward to reach your whole homelab securely.
Forward this single UDP port in pfSense to your pfSense WAN interface. Once you're connected via Wireguard, you have full LAN access and can SSH, browse services, reach Proxmox — everything. No other ports need to be forwarded for private access.
Your Homelab Service Ports
Proxmox web UI — :8006
The hypervisor control panel. Only accessible on your LAN (or via Wireguard).
https://192.168.10.100:8006 # Proxmox UI (HTTPS, self-signed cert)
⚠️ Never expose port 8006 to the internet. It has no rate limiting on logins. Only access via Wireguard.
Jellyfin — :8096 (HTTP) / :8920 (HTTPS)
Your media server. Internally on 8096 — Nginx Proxy Manager handles HTTPS externally.
http://192.168.10.100:8096 # LAN access direct
https://jellyfin.yourdomain.com # external via NPM (preferred)
https://jellyfin.yourdomain.com # external via NPM (preferred)
Navidrome — :4533
Music server web UI and Subsonic API for apps.
http://192.168.10.100:4533 # web UI
# apps like Symfonium use the Subsonic API on the same port
# apps like Symfonium use the Subsonic API on the same port
Nextcloud — :443 (via NPM)
Cloud storage. Always run behind Nginx Proxy Manager with HTTPS.
https://nextcloud.yourdomain.com # external via NPM
http://192.168.10.100:8080 # internal (NPM admin panel)
http://192.168.10.100:8080 # internal (NPM admin panel)
Nginx Proxy Manager — :81 (admin) / :80 / :443
NPM admin panel on 81. It listens on 80 and 443 for all proxied services.
http://192.168.10.100:81 # NPM admin panel (LAN only)
Frigate NVR — :5000 / :8554 (RTSP)
Camera dashboard on 5000. RTSP streams on 8554. Never expose externally.
http://192.168.10.100:5000 # Frigate dashboard
rtsp://192.168.10.100:8554/camera_name # RTSP stream
rtsp://192.168.10.100:8554/camera_name # RTSP stream
⚠️ Keep Frigate off the public internet. Camera feeds + person detection data should never leave your LAN.
Open WebUI — :3000
Your local AI interface. Reaches Ollama on port 11434 internally.
http://192.168.10.100:3000 # Open WebUI
http://192.168.10.100:11434 # Ollama API (internal only)
http://192.168.10.100:11434 # Ollama API (internal only)
Calibre Web — :8083
Ebook library web UI.
http://192.168.10.100:8083 # Calibre Web UI
Pi-hole — :80 (admin) / :53 (DNS)
Pi-hole admin dashboard on 80. DNS resolver on 53. Keep separate from NPM's port 80.
If Pi-hole and Nginx Proxy Manager are on the same host, Pi-hole's web UI needs a different port (e.g. 8082) or run them on different IPs. They both want port 80.
http://192.168.10.5/admin # Pi-hole dashboard
http://192.168.10.5:8082/admin # if NPM owns port 80
http://192.168.10.5:8082/admin # if NPM owns port 80
Game Server Ports
Minecraft — :25565 TCP
Java Edition default. Forward this in pfSense so friends can connect.
pfSense: WAN:25565 TCP → 192.168.10.100:25565
Friends connect to: yourpublicip:25565
# or dahamsterserver.duckdns.org:25565
Friends connect to: yourpublicip:25565
# or dahamsterserver.duckdns.org:25565
DayZ — :2302–2305 UDP · Zomboid — :16261/16262 UDP
Game servers use UDP. Forward all required ports in pfSense.
DayZ: 2302 UDP (game), 2303 UDP (RCON), 2305 UDP (BEC)
Zomboid: 16261 UDP (game), 16262 UDP (direct)
Pavlov: 7777 UDP
# all forwarded WAN → 192.168.10.100:port
Zomboid: 16261 UDP (game), 16262 UDP (direct)
Pavlov: 7777 UDP
# all forwarded WAN → 192.168.10.100:port
Checking Open Ports
ss -tulpn
Show every open port on the current machine and which process owns it
ss -tulpn # all listening ports
ss -tulpn | grep :8096 # is Jellyfin listening?
netstat -tulpn # older alternative
nmap -p 1-65535 192.168.10.100 # scan all ports on server from another machine
curl -I http://localhost:8096 # test if service responds
ss -tulpn | grep :8096 # is Jellyfin listening?
netstat -tulpn # older alternative
nmap -p 1-65535 192.168.10.100 # scan all ports on server from another machine
curl -I http://localhost:8096 # test if service responds
VLANs & DHCP
VLANs are virtual separate networks on the same physical switch. Your managed switch tags traffic
by VLAN ID so different device groups are completely isolated from each other.
Your Four VLANs
VLAN 10 — Private LAN 192.168.10.0/24
Full trust. Your gaming PC, daily devices. Complete access to all homelab services.
Firewall rules
✓ Access to internet
✓ Access to server rack — all services
✓ Access to Proxmox UI (8006)
✓ Can reach all other VLANs via explicit rules
✓ Access to server rack — all services
✓ Access to Proxmox UI (8006)
✓ Can reach all other VLANs via explicit rules
Fixed IPs in this VLAN
192.168.10.1 # pfSense (gateway)
192.168.10.5 # Pi-hole (DNS)
192.168.10.10 # managed switch (management IP)
192.168.10.100 # R720xd server (Proxmox)
192.168.10.50 # gaming PC (DHCP reservation)
192.168.10.50+ # everything else dynamic DHCP
192.168.10.5 # Pi-hole (DNS)
192.168.10.10 # managed switch (management IP)
192.168.10.100 # R720xd server (Proxmox)
192.168.10.50 # gaming PC (DHCP reservation)
192.168.10.50+ # everything else dynamic DHCP
VLAN 20 — Guest WiFi 192.168.20.0/24
Internet-only. Visitors and friends. Completely blind to your LAN and server.
Firewall rules
✓ Internet access only
✗ No access to VLAN 10 (your devices)
✗ No access to server rack
✗ No access to any other VLAN
✗ No access to server rack
✗ No access to any other VLAN
DNS for guests: use Cloudflare 1.1.1.1 directly instead of Pi-hole. No reason to give guests your local resolver.
VLAN 30 — IoT 192.168.30.0/24
Smart TVs, Rokus, smart bulbs. These are notoriously chatty — isolate them.
Firewall rules
✓ Internet access (cloud features still work)
✓ Can reach Frigate only (optional, explicit rule)
✓ Can reach Frigate only (optional, explicit rule)
✗ No access to Private LAN
✗ No access to Proxmox, server management
✗ No access to Guest or CCTV VLANs
✗ No access to Proxmox, server management
✗ No access to Guest or CCTV VLANs
IoT devices are often insecure and phone home constantly. Pi-hole on IoT VLAN will block a shocking amount of their telemetry.
VLAN 40 — CCTV 192.168.40.0/24
IP cameras only. Completely air-gapped from internet. Streams to Frigate only.
Firewall rules
✓ Can reach Frigate on 192.168.10.100:5000 only
✗ No internet access — cameras should NEVER call home
✗ No access to any other VLAN
✗ No DNS needed
✗ No access to any other VLAN
✗ No DNS needed
⚠️ Cheap IP cameras regularly attempt to call home to Chinese cloud servers. Hard-blocking their internet access at the VLAN level is the right move.
DHCP — How Devices Get IPs
DORA — Discover → Offer → Request → Acknowledge
The four-step handshake that runs every time a device joins your network.
Discover # device broadcasts "anyone have an IP for me?" (255.255.255.255:67)
Offer # pfSense replies "here's 192.168.10.45, available for 24h"
Request # device says "yes I'll take 192.168.10.45"
Acknowledge # pfSense confirms + sends: subnet mask, gateway, DNS server
Offer # pfSense replies "here's 192.168.10.45, available for 24h"
Request # device says "yes I'll take 192.168.10.45"
Acknowledge # pfSense confirms + sends: subnet mask, gateway, DNS server
pfSense runs one DHCP server per VLAN, each with its own range, gateway, and DNS settings.
DHCP Reservation — static IP via MAC address
In pfSense: "whenever you see this MAC address, always give it this IP." Best of both worlds.
Server, Pi-hole, switch — anything that other services depend on needs a fixed IP. DHCP reservations are better than static IPs configured on the device because you manage everything from pfSense.
pfSense → Services → DHCP Server → [your VLAN]
→ DHCP Static Mappings → Add
→ enter MAC address + desired IP + hostname
ip link show # Linux: find your MAC address
ip addr show eth0 # MAC is the "link/ether" line
→ DHCP Static Mappings → Add
→ enter MAC address + desired IP + hostname
ip link show # Linux: find your MAC address
ip addr show eth0 # MAC is the "link/ether" line
DHCP ranges to set in pfSense
VLAN 10: 192.168.10.50 – 192.168.10.200 # .1-.49 reserved for static
VLAN 20: 192.168.20.50 – 192.168.20.200
VLAN 30: 192.168.30.50 – 192.168.30.200
VLAN 40: 192.168.40.50 – 192.168.40.100 # fewer cameras needed
VLAN 20: 192.168.20.50 – 192.168.20.200
VLAN 30: 192.168.30.50 – 192.168.30.200
VLAN 40: 192.168.40.50 – 192.168.40.100 # fewer cameras needed
End-to-End Traffic Traces
You open Jellyfin on your phone
Phone (VLAN 10) → Pi-hole → server → Jellyfin container → video streams
1. Phone asks Pi-hole: "what is jellyfin.home?"
2. Pi-hole returns 192.168.10.100 (local A record)
3. Phone connects TCP to 192.168.10.100:8096
4. Jellyfin responds, streams media
# total: under 20ms inside your LAN
2. Pi-hole returns 192.168.10.100 (local A record)
3. Phone connects TCP to 192.168.10.100:8096
4. Jellyfin responds, streams media
# total: under 20ms inside your LAN
A friend joins your Minecraft server
Internet → your public IP:25565 → pfSense NAT → server → Minecraft container
1. Friend's PC connects to dahamsterserver.duckdns.org:25565
2. DuckDNS resolves to your current public IP
3. TCP hits pfSense on WAN port 25565
4. pfSense NAT forwards to 192.168.10.100:25565
5. Minecraft container accepts connection
6. Friend is in your world
2. DuckDNS resolves to your current public IP
3. TCP hits pfSense on WAN port 25565
4. pfSense NAT forwards to 192.168.10.100:25565
5. Minecraft container accepts connection
6. Friend is in your world
A guest connects to WiFi
Guest device → VLAN 20 → internet only → your server is completely invisible
1. Guest connects to guest SSID
2. Gets IP 192.168.20.x via DHCP, DNS = 1.1.1.1
3. pfSense firewall blocks all traffic to VLAN 10
4. Guest can browse internet
5. 192.168.10.x doesn't exist from their perspective
6. Your R720xd is completely invisible to them
2. Gets IP 192.168.20.x via DHCP, DNS = 1.1.1.1
3. pfSense firewall blocks all traffic to VLAN 10
4. Guest can browse internet
5. 192.168.10.x doesn't exist from their perspective
6. Your R720xd is completely invisible to them
Camera detects motion
IP cam (VLAN 40) → Frigate → AI detection → clip saved → notification sent
1. IP camera on VLAN 40 streams RTSP to Frigate
2. pfSense allows VLAN 40 → 192.168.10.100:5000 only
3. Frigate AI detects a person in the frame
4. Clip is saved to R720xd storage (TrueNAS dataset)
5. Notification sent (Home Assistant webhook)
6. Camera never touches the internet — not once
2. pfSense allows VLAN 40 → 192.168.10.100:5000 only
3. Frigate AI detects a person in the frame
4. Clip is saved to R720xd storage (TrueNAS dataset)
5. Notification sent (Home Assistant webhook)
6. Camera never touches the internet — not once
HTTPS & Nginx Proxy Manager
Every service you expose externally needs HTTPS. Nginx Proxy Manager sits at the edge of your server,
handles TLS, and routes traffic to the right container by subdomain.
HTTP vs HTTPS
HTTP — port 80 — plaintext
Traffic is unencrypted. Passwords, cookies, file data — all visible to anyone between you and the server.
🔴 On your local LAN it's low risk. The moment anything is accessible externally, HTTP is unacceptable. Your login credentials to Nextcloud or Jellyfin would travel the internet in plaintext.
Nginx Proxy Manager automatically redirects HTTP → HTTPS. Port 80 exists only to issue the redirect.
HTTPS — port 443 — TLS encrypted
Traffic is encrypted end-to-end. The padlock icon. Mandatory for external access.
✓ Login credentials encrypted
✓ Session cookies protected from hijacking
✓ File uploads/downloads encrypted
✓ API keys and tokens protected
✓ ISP cannot see what you're doing (only that you're talking to your server)
✓ Session cookies protected from hijacking
✓ File uploads/downloads encrypted
✓ API keys and tokens protected
✓ ISP cannot see what you're doing (only that you're talking to your server)
TLS Handshake
How HTTPS connections are established
A 5-step cryptographic handshake that happens before any data flows. Under 100ms total.
1. Client hello # browser: "I support these algorithms"
2. Server hello # server: picks algorithm, sends TLS certificate
3. Cert verify # browser: is cert signed by a trusted CA? domain match? expired?
4. Key exchange # both sides derive a shared session key (private to this session)
5. Encrypted data # all subsequent traffic encrypted. Handshake done.
2. Server hello # server: picks algorithm, sends TLS certificate
3. Cert verify # browser: is cert signed by a trusted CA? domain match? expired?
4. Key exchange # both sides derive a shared session key (private to this session)
5. Encrypted data # all subsequent traffic encrypted. Handshake done.
Nginx Proxy Manager holds your TLS cert and does step 2. It then forwards plain HTTP to your internal containers. Your containers (Jellyfin, Nextcloud, etc.) don't handle TLS at all — NPM does it for them.
Nginx Proxy Manager — Reverse Proxy
How a reverse proxy works
One public IP, one port 443, one cert — routes to dozens of services by reading the subdomain in the HTTP header.
When a request arrives on port 443, the Host header says "jellyfin.yourdomain.com". NPM reads that header and forwards the request to the right container. You never type a port number again — everything is on a clean subdomain.
NPM routing table
jellyfin.yourdomain.com → localhost:8096 # SSL on
nextcloud.yourdomain.com → localhost:5000 # SSL on
music.yourdomain.com → localhost:4533 # SSL on
ai.yourdomain.com → localhost:3000 # SSL on
books.yourdomain.com → localhost:8083 # SSL on
frigate.yourdomain.com → localhost:5000 # LAN-only (no external access)
nextcloud.yourdomain.com → localhost:5000 # SSL on
music.yourdomain.com → localhost:4533 # SSL on
ai.yourdomain.com → localhost:3000 # SSL on
books.yourdomain.com → localhost:8083 # SSL on
frigate.yourdomain.com → localhost:5000 # LAN-only (no external access)
docker-compose.yml — NPM setup
Basic NPM container config. Ports 80, 443 (traffic) and 81 (admin panel).
services:
npm:
image: jc21/nginx-proxy-manager:latest
ports:
- "80:80" # HTTP (redirects to 443)
- "443:443" # HTTPS (all proxied services)
- "81:81" # admin panel
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
npm:
image: jc21/nginx-proxy-manager:latest
ports:
- "80:80" # HTTP (redirects to 443)
- "443:443" # HTTPS (all proxied services)
- "81:81" # admin panel
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
Let's Encrypt Certificates
Let's Encrypt — free, auto-renewing TLS certs
A Certificate Authority that issues browser-trusted HTTPS certs at no cost. NPM handles everything.
Let's Encrypt proves you own the domain via a "challenge." For DuckDNS subdomains, NPM uses the DNS-01 challenge — it adds a TXT record to your DuckDNS domain via the API, Let's Encrypt verifies it, cert is issued. All automatic.
Getting a wildcard cert
NPM → SSL Certificates → Add Certificate
Domain: *.yourname.duckdns.org
Challenge: DNS / DuckDNS
API Token: [your DuckDNS token]
# one cert covers all subdomains — jellyfin, nextcloud, music, etc.
Domain: *.yourname.duckdns.org
Challenge: DNS / DuckDNS
API Token: [your DuckDNS token]
# one cert covers all subdomains — jellyfin, nextcloud, music, etc.
✓ Wildcard cert: *.yourname.duckdns.org covers ALL subdomains
✓ Auto-renews every 90 days — zero maintenance
✓ DuckDNS API token handles the DNS-01 challenge automatically
✓ Auto-renews every 90 days — zero maintenance
✓ DuckDNS API token handles the DNS-01 challenge automatically
DuckDNS — dynamic DNS for your changing public IP
dahamsterserver.duckdns.org always resolves to your current public IP, even when it changes.
Your ISP probably gives you a dynamic public IP. DuckDNS is a free service that auto-updates your subdomain every 5 minutes. Run it as a Docker container or a cron job on your server.
# Docker container — run on your server
services:
duckdns:
image: lscr.io/linuxserver/duckdns:latest
environment:
- SUBDOMAINS=dahamsterserver
- TOKEN=your-duckdns-token
- TZ=America/New_York
restart: unless-stopped
services:
duckdns:
image: lscr.io/linuxserver/duckdns:latest
environment:
- SUBDOMAINS=dahamsterserver
- TOKEN=your-duckdns-token
- TZ=America/New_York
restart: unless-stopped
Wireguard VPN
Wireguard is the VPN built into OPNsense. Connect from anywhere and your phone/laptop behaves
as if it's sitting on your home LAN — reaching Proxmox, Jellyfin, Pi-hole, everything.
How Wireguard Works
Wireguard — kernel-level VPN, 51820 UDP
~4,000 lines of code vs OpenVPN's 100,000. Faster, simpler, built into Linux kernel.
Wireguard creates an encrypted tunnel between your device and OPNsense. All traffic from your device routes through that tunnel and emerges on your home LAN. Your phone's IP becomes 10.0.0.2 (or whatever tunnel IP you assign) and it can reach 192.168.10.x as if it's home.
Your phone (10.0.0.2) → encrypted UDP → dahamsterserver.duckdns.org:51820
→ OPNsense (Wireguard server, 10.0.0.1)
→ routes to 192.168.10.x (your LAN)
→ 192.168.10.100 (R720xd) responds
→ back through tunnel → your phone
→ OPNsense (Wireguard server, 10.0.0.1)
→ routes to 192.168.10.x (your LAN)
→ 192.168.10.100 (R720xd) responds
→ back through tunnel → your phone
Because you're on your VPN, you can reach Proxmox (8006), SSH to anything, open Jellyfin, check Frigate — all without any additional port forwarding. One port (51820) = full access.
VPN vs Port Forwarding — which for what
Use Wireguard for private access, port forwarding only for things friends need to reach.
Use Wireguard for
✓ SSH to your server
✓ Proxmox web UI
✓ Frigate camera feeds
✓ Pi-hole admin
✓ Portainer
✓ Anything admin or sensitive
✓ Proxmox web UI
✓ Frigate camera feeds
✓ Pi-hole admin
✓ Portainer
✓ Anything admin or sensitive
Use port forwarding for
Minecraft/DayZ/Zomboid — friends need to connect without Wireguard
Your website (Nginx) — public-facing
Jellyfin/Nextcloud (via NPM) — family access without VPN setup
Your website (Nginx) — public-facing
Jellyfin/Nextcloud (via NPM) — family access without VPN setup
⚠️ Every forwarded port is an attack surface. Keep the list short.
Public / private key pairs — how Wireguard authenticates
No passwords. Each peer has a keypair. The server holds client public keys. Clients hold server public key.
Wireguard uses Curve25519 key pairs. You generate a keypair per client device. Give the server your public key. The server gives you its public key. Each side uses the other's public key to encrypt; only the matching private key can decrypt. Compromise one client key = that one device is affected, nothing else.
wg genkey | tee privatekey | wg pubkey > publickey # generate keypair
cat privatekey # your private key — never share this
cat publickey # give this to OPNsense
cat privatekey # your private key — never share this
cat publickey # give this to OPNsense
OPNsense Setup
OPNsense → VPN → WireGuard → Local
Configure the server (OPNsense) side. One-time setup.
Name: homelab-wg
Listen Port: 51820
Tunnel Address: 10.0.0.1/24 # VPN subnet, not your LAN
DNS Server: 192.168.10.5 # Pi-hole — VPN clients get ad blocking too
Disable Routes: unchecked
Listen Port: 51820
Tunnel Address: 10.0.0.1/24 # VPN subnet, not your LAN
DNS Server: 192.168.10.5 # Pi-hole — VPN clients get ad blocking too
Disable Routes: unchecked
Then add a peer (one per device)
OPNsense → VPN → WireGuard → Peers → Add
Name: my-phone
Public Key: [your phone's public key]
Allowed IPs: 10.0.0.2/32 # VPN IP assigned to this client
Name: my-phone
Public Key: [your phone's public key]
Allowed IPs: 10.0.0.2/32 # VPN IP assigned to this client
Port forward in pfSense/OPNsense WAN rules
WAN UDP port 51820 → 127.0.0.1:51820 # to OPNsense itself
Firewall rules — allow Wireguard clients onto your LAN
OPNsense needs explicit rules to let VPN clients reach your local network.
OPNsense → Firewall → Rules → WireGuard
→ Add rule:
Action: Pass
Interface: WireGuard
Source: WireGuard net (10.0.0.0/24)
Destination: LAN net (192.168.10.0/24)
Protocol: any
# this lets VPN clients reach your entire VLAN 10
→ Add rule:
Action: Pass
Interface: WireGuard
Source: WireGuard net (10.0.0.0/24)
Destination: LAN net (192.168.10.0/24)
Protocol: any
# this lets VPN clients reach your entire VLAN 10
Client Configuration
Client config file — wg0.conf
Drop this on any device (or scan as QR code on mobile) to connect.
[Interface]
PrivateKey = [your device private key]
Address = 10.0.0.2/24 # VPN IP for this device
DNS = 192.168.10.5 # Pi-hole — use it even while remote
[Peer]
PublicKey = [OPNsense server public key]
Endpoint = dahamsterserver.duckdns.org:51820
AllowedIPs = 192.168.10.0/24, 192.168.20.0/24, 10.0.0.0/24
# routes only your home subnets through tunnel
# (split tunnel — other internet goes direct)
PersistentKeepalive = 25 # keep NAT hole punched open
PrivateKey = [your device private key]
Address = 10.0.0.2/24 # VPN IP for this device
DNS = 192.168.10.5 # Pi-hole — use it even while remote
[Peer]
PublicKey = [OPNsense server public key]
Endpoint = dahamsterserver.duckdns.org:51820
AllowedIPs = 192.168.10.0/24, 192.168.20.0/24, 10.0.0.0/24
# routes only your home subnets through tunnel
# (split tunnel — other internet goes direct)
PersistentKeepalive = 25 # keep NAT hole punched open
AllowedIPs — tunnel all traffic vs split tunnel
AllowedIPs = 0.0.0.0/0 # full tunnel — ALL traffic through VPN (more private)
AllowedIPs = 192.168.10.0/24 # split tunnel — only home LAN through VPN (faster)
AllowedIPs = 192.168.10.0/24 # split tunnel — only home LAN through VPN (faster)
wg show
Check Wireguard status — see connected peers and last handshake time
wg show # all tunnel info + peer handshake times
wg show wg0 # specific interface
wg-quick up wg0 # bring tunnel up (Linux client)
wg-quick down wg0 # bring tunnel down
systemctl enable wg-quick@wg0 # auto-connect on boot
wg show wg0 # specific interface
wg-quick up wg0 # bring tunnel up (Linux client)
wg-quick down wg0 # bring tunnel down
systemctl enable wg-quick@wg0 # auto-connect on boot
If "latest handshake" shows recent time → tunnel is active. If peers show no handshake, check: is port 51820 forwarded in pfSense? Is OPNsense Wireguard service enabled?
Mobile — Wireguard app (iOS/Android)
Import via QR code. OPNsense can generate the QR code for you.
In OPNsense: after creating a peer, click the QR code icon next to it. Open the Wireguard app on your phone → Add tunnel → Scan QR code. Done. Your phone now has full LAN access when connected.
✓ On-demand tunnels in the app — only active when you want it
✓ iOS shortcut: "when not on home WiFi, enable Wireguard"
✓ Works on LTE, 5G, hotel WiFi — anything with internet
✓ iOS shortcut: "when not on home WiFi, enable Wireguard"
✓ Works on LTE, 5G, hotel WiFi — anything with internet
Troubleshooting VPN connection
Common issues and how to debug them.
# Can't connect at all
→ Check port 51820 UDP is forwarded in OPNsense WAN rules
→ Check OPNsense Wireguard service is running
→ Check DuckDNS resolved to your current public IP (curl ifconfig.me)
# Connected but can't reach LAN
→ Check AllowedIPs in client config includes 192.168.10.0/24
→ Check OPNsense firewall rule: WireGuard → LAN is Pass
→ Check your server's subnet routes
# DNS not working over VPN
→ Check DNS = 192.168.10.5 in [Interface] section of config
→ Check Pi-hole is allowing queries from 10.0.0.0/24
→ Check port 51820 UDP is forwarded in OPNsense WAN rules
→ Check OPNsense Wireguard service is running
→ Check DuckDNS resolved to your current public IP (curl ifconfig.me)
# Connected but can't reach LAN
→ Check AllowedIPs in client config includes 192.168.10.0/24
→ Check OPNsense firewall rule: WireGuard → LAN is Pass
→ Check your server's subnet routes
# DNS not working over VPN
→ Check DNS = 192.168.10.5 in [Interface] section of config
→ Check Pi-hole is allowing queries from 10.0.0.0/24