How to Secure Your Home Homelab with a WireGuard VPN and Zero‑Trust Firewall

Disclosure: We are reader supported, and earn affiliate commissions when you buy through us.

You’ve spent months building a tidy rack, installing Pi‑hole, a DIY NAS for centralized storage, and a little Jitsi server for family calls. It works great—until you realize anyone on the same Wi‑Fi can sniff traffic or, worse, a stray device could stumble into your admin panel. That’s why a VPN and a zero‑trust firewall are now more than nice‑to‑have; they’re the lock and key for a safe homelab.

Why WireGuard and Zero‑Trust?

WireGuard is the new kid on the block, but it’s already beating older VPNs in speed and simplicity. Think of it as a thin, encrypted tunnel that only lets in devices you explicitly trust. Pair that with a zero‑trust firewall—an approach that assumes every connection could be hostile unless proven otherwise—and you get a system that stops attackers at the door instead of letting them wander around your network.

In short: WireGuard hides your lab from the outside world, and the zero‑trust firewall makes sure nothing inside can do anything it isn’t allowed to do.

Step 1 – Pick Your Hardware

I run my lab on a modest Intel NUC, but any device that can run Linux will do. The key is to have a dedicated NIC (network interface card) for the VPN. If you have a spare USB‑to‑Ethernet adapter, plug it in and label it “wg‑nic”. This separation makes routing rules easier to read and keeps your main LAN untouched.

Step 2 – Install WireGuard

On the Server

Update your system
```
sudo apt update && sudo apt upgrade -y
```
Install the package
```
sudo apt install wireguard -y
```

Generate keys

wg genkey | tee server_private.key | wg pubkey > server_public.key

Keep server_private.key safe; it never leaves the box.

Create the config (/etc/wireguard/wg0.conf)

[Interface]
Address = 10.200.200.1/24
ListenPort = 51820
PrivateKey = <contents of server_private.key>

# Example peer – your laptop
[Peer]
PublicKey = <laptop_public_key>
AllowedIPs = 10.200.200.2/32

Enable IP forwarding

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.d/99-sysctl.conf
sudo sysctl -p

Start the service

sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0

On the Client (Laptop, Phone, etc.)

Repeat the key generation on each device, then add a peer block for the server in the client’s config. I keep my phone config in the “WireGuard” app; it’s as easy as scanning a QR code.

Step 3 – Test the Tunnel

From the client, ping the server’s VPN address:

ping 10.200.200.1

If you get replies, the tunnel is up. Next, try reaching a service inside your lab, like Nextcloud on port 443, using the VPN IP of the host. If it works, you’ve got a working encrypted path.

Step 4 – Set Up a Zero‑Trust Firewall

I like using nftables because it’s modern and less cryptic than iptables. The idea is simple: deny everything by default, then open only the ports you need for each device.

Install nftables

sudo apt install nftables -y

Basic Policy

Create /etc/nftables.conf with the following skeleton:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif lo accept
        ct state established,related accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

policy drop means “block everything unless we say otherwise”.
iif lo accept lets the loopback interface talk to itself.
ct state established,related accept allows replies to outbound traffic.

Allow WireGuard Traffic

Add a rule that lets the VPN interface talk to the lab network:

    chain wg-input {
        type filter hook input priority 10; policy drop;
        iif wg0 accept
    }

Then attach it to the main input chain:

    chain input {
        ...
        jump wg-input
    }

Open Specific Services

Suppose you only want the VPN client to reach Nextcloud (port 443) and your Pi‑hole (port 53). Add these lines inside wg-input:

        ip saddr 10.200.200.2 tcp dport 443 accept
        ip saddr 10.200.200.2 udp dport 53 accept

Repeat for each device you trust, using its VPN IP. If a device tries to reach anything else, the default drop rule will block it.

Load the Rules

sudo nft -f /etc/nftables.conf
sudo systemctl enable nftables
sudo systemctl start nftables

Step 5 – Harden the Server

A VPN is only as strong as the host it runs on.

Keep the OS patched – set up unattended upgrades or a cron job.
Use strong passwords – consider using a self‑hosted password manager like Bitwarden to generate and store them securely, or better, disable password login entirely and rely on SSH keys.
Limit SSH – add a rule that only allows SSH from the VPN subnet.
```
ip saddr 10.200.200.0/24 tcp dport 22 accept
```
Monitor logs – journalctl -u wg-quick@wg0 and nft list ruleset give quick insight into what’s happening.

Step 6 – Bring It Home

Now that the tunnel and firewall are live, configure your home router to forward UDP 51820 to the lab server’s WAN IP. If you have a dynamic IP from your ISP, set up a free DDNS service (like DuckDNS) and point your WireGuard client to that name. I keep the DDNS update script on the same NUC; a tiny cron entry does the work.

A Little Story

When I first tried WireGuard, I accidentally set the client’s AllowedIPs to 0.0.0.0/0. That told the VPN to route all traffic—including my own internet browsing—through the lab box. My laptop suddenly slowed to a crawl, and I realized I was trying to stream Netflix through a 100 Mbps home link that was already busy with backups. The fix? Change AllowedIPs to just the VPN subnet and the specific services you need. Lesson learned: a VPN is a tunnel, not a highway.

Wrap‑Up

With WireGuard handling encryption and a zero‑trust firewall enforcing strict per‑device rules, your homelab becomes a fortress you can reach from anywhere without exposing a single port to the wild internet. The setup is lightweight, uses modern tools, and can be expanded as you add more services.

Give it a try, tweak the rules to match your own lab, and enjoy the peace of mind that comes from knowing your DIY server stack is locked down the right way.