WireGuard Home VPN: Secure Remote Access for Your Homelab

A home VPN is one of those homelab projects that feels small until it changes how you operate everything else. Suddenly you can reach the NAS without exposing it, check a Proxmox host from a hotel, pull a config backup, or help a family member without punching random holes through the firewall. Done right, WireGuard becomes the quiet management path for the whole lab.

WireGuard is a lean VPN protocol with a simple peer model, modern cryptography, and a configuration style that is much easier to reason about than older VPN stacks. The official WireGuard quick start is intentionally minimal, and Ubiquiti also documents WireGuard VPN server setup on UniFi gateways for people running a UniFi edge. The trick is that a VPN tunnel is only transport. Security comes from how you route, name, firewall, log, and test it.

Design principle: Do not make VPN users honorary LAN users. Give the VPN its own subnet, give every peer its own identity, and allow only the services that remote users actually need.

What We Are Building

The clean pattern is a dedicated WireGuard subnet, such as 10.44.0.0/24, routed by your gateway or a small Linux VM. Each remote device gets one address inside that subnet. The firewall then decides whether that peer can reach DNS, management, servers, cameras, or nothing at all.

Component	Recommended Baseline	Why It Matters
VPN subnet	A dedicated RFC1918 range such as 10.44.0.0/24	Keeps remote access visible in logs and easy to target with firewall policy.
Peers	One peer per device, never shared configs	You can revoke a lost phone without breaking every other user.
DNS	Internal resolver pushed to VPN clients	Private names work offsite and you avoid hardcoding IP addresses.
Routing	Split tunnel for normal admin use, full tunnel only when needed	Reduces unnecessary traffic and makes failures easier to diagnose.
Firewall	Default deny from VPN to LAN, then explicit allows	The VPN is a door, not permission to wander.

UniFi Gateway Setup Path

1. Create a WireGuard VPN server on the UniFi gateway and choose a dedicated VPN subnet that does not overlap with LAN, guest, IoT, or remote-site networks.
2. Create one client/peer per device. Name peers clearly, such as dan-laptop, dan-phone, travel-router, or emergency-admin.
3. Set allowed IPs intentionally. For split tunnel, only route your homelab subnets through the VPN. For full tunnel, include 0.0.0.0/0 only when you mean to backhaul all traffic.
4. Push internal DNS servers to the peer profile so names like nas.home.arpa resolve over the tunnel.
5. Add firewall rules that permit the VPN subnet to specific destinations and ports, then deny everything else to internal networks.
6. Export or scan each client configuration directly on the device that owns it. Do not store a pile of reusable VPN configs in a shared folder.
7. Test from cellular or a different internet connection, not from inside the same LAN.

Firewall Rules I Would Start With

Rule	Source	Destination	Ports	Action
Allow VPN to DNS	VPN subnet	Internal DNS servers	53 TCP/UDP, optionally 853	Allow
Allow VPN to management jump host	Admin peer or VPN subnet	Jump host	22 or 3389 only if required	Allow
Allow VPN to server web UIs	Admin peer group	NAS/Proxmox/app admin IPs	Specific HTTPS ports	Allow
Deny VPN to IoT and guest	VPN subnet	IoT/guest VLANs	Any	Deny and log
Deny VPN to management except explicit rules	VPN subnet	Network management VLAN	Any	Deny and log

Client Example

The exact profile will vary by platform, but the mental model stays the same: one private key, one address, one DNS view, and allowed IPs that describe what should cross the tunnel.

[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.44.0.10/32
DNS = 10.10.20.10

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 10.10.0.0/16
PersistentKeepalive = 25

Full tunnel caution: AllowedIPs = 0.0.0.0/0 is useful on untrusted Wi-Fi, but it changes the traffic path, DNS behavior, bandwidth use, and privacy expectations. Use it intentionally.

Validation Checklist

• From cellular, connect the VPN and confirm the peer handshake updates.
• Confirm the client receives the intended VPN address and DNS server.
• Resolve an internal name, then ping or browse only an allowed internal service.
• Attempt a blocked path, such as IoT or guest, and confirm the firewall denies it.
• Revoke one test peer and confirm only that device loses access.
• Export a fresh gateway backup after the design is stable.

Useful Gear And Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

Need	Good Choice	Why It Fits	Affiliate Link
UniFi edge gateway	UCG Ultra or UCG Max	Good fit when you want WireGuard built into a UniFi-managed home network.	Amazon: UCG Ultra Amazon: UCG Max No Storage
Travel VPN router	GL.iNet Beryl AX	Useful for hotel or family support scenarios where several devices ride one WireGuard client.	Amazon: GL.iNet Beryl AX GL-MT3000
Power protection	APC or CyberPower sine-wave UPS	Keeps the gateway and DNS online long enough for graceful recovery.	Amazon: CyberPower CP1500PFCLCD Amazon: APC BR1500MS2
Patch cabling	Known-good Cat6 patch leads	A VPN troubleshooting session should not be hiding a bad cable at the edge.	Amazon: Cable Matters Cat6 10-pack

Common Mistakes

• Reusing one peer config for multiple phones or laptops.
• Letting the VPN subnet reach every VLAN because it was convenient on day one.
• Forgetting that DNS is part of the remote-access experience.
• Using a subnet that overlaps with hotels, offices, or family networks.
• Not documenting the revoke process before a device is lost.

References

• WireGuard Quick Start
• WireGuard Known Limitations
• UniFi Gateway WireGuard VPN Server
• RFC 1918 Address Allocation for Private Internets

Final Thought

The best home VPN is boring in exactly the right way. It connects quickly, gives each device a clear identity, resolves private names, reaches only the intended services, and disappears from your attention until you need it. That is the target: not a flat LAN over the internet, but a controlled remote management path for the homelab you actually trust.

This article is part of the TechGeeks homelab foundation series. The series is designed to build practical home infrastructure in the right order: remote access, segmentation, exposure control, DNS, IoT isolation, and recoverable backups.