---
title: How to Secure Your Home Homelab with a WireGuard VPN and Zero‑Trust Firewall
siteUrl: https://logzly.com/selfhostlab
author: selfhostlab (Self‑Host Lab)
date: 2026-06-16T15:22:33.144567
tags: [homelab, wireguard, zerotrust]
url: https://logzly.com/selfhostlab/how-to-secure-your-home-homelab-with-a-wireguard-vpn-and-zerotrust-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](/selfhostlab/step-by-step-guide-to-building-a-low-cost-diy-nas-with-raspberry-pi-5), 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](https://www.amazon.com/s?k=lock+and+key&tag=organizationtip101-20) for a safe homelab.

## Why WireGuard and Zero‑Trust?

WireGuard is the new kid on [the block](https://www.amazon.com/s?k=The+Block&tag=organizationtip101-20), 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

1. **Update your system**  
   ```bash
   sudo apt update && sudo apt upgrade -y
   ```

2. **Install the package**  
   ```bash
   sudo apt install wireguard -y
   ```

3. **Generate keys**  
   ```bash
   wg genkey | tee server_private.key | wg pubkey > server_public.key
   ```

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

4. **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
   ```

5. **Enable IP forwarding**  
   ```bash
   echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.d/99-sysctl.conf
   sudo sysctl -p
   ```

6. **Start the service**  
   ```bash
   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](https://www.amazon.com/s?k=QR+code&tag=organizationtip101-20).

## Step 3 – Test the Tunnel

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

```bash
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

```bash
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

```bash
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](https://www.amazon.com/s?k=Strong+Passwords&tag=organizationtip101-20)** – consider using a [self‑hosted password manager like Bitwarden](/selfhostlab/install-bitwarden-on-a-raspberry-pi-a-complete-diy-guide-for-a-selfhosted-password-manager) 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](https://www.amazon.com/s?k=Peace+of+Mind&tag=organizationtip101-20) that comes from knowing your DIY server stack is locked down the right way.