🔒 Your Own VPN with WireGuard

Let's be honest about what this does and doesn't do, because commercial VPN marketing has muddied the waters badly.

It does not make you anonymous. Your traffic still exits from a single VPS, and that VPS is tied to your account, your payment method, and whatever ID your provider required. Anyone who can legally compel your VPS provider can connect that IP back to you. Running your own VPN swaps "trust a VPN company's no-logs claim" for "trust your VPS provider's jurisdiction" — it does not remove the need for trust, it just relocates it to someone you chose.

What it is genuinely good for:

• Untrusted Wi-Fi — coffee shops, hotels, airports, conference networks. Everything you send is encrypted to your own server instead of being readable by whoever runs that access point.
• Reaching your home lab — once connected, your phone or laptop can talk to your home server, NAS, or Raspberry Pi as if you were sitting on the same LAN, from anywhere in the world.
• A stable exit IP — useful when a service treats your dynamic residential IP with suspicion, or when you just want one consistent address for your traffic.

What it is not: a way to hide from your VPS provider, a way to reliably unblock geo-restricted streaming (commercial VPNs fight an arms race against that detection that a single personal IP will lose fast), or a substitute for HTTPS and good password hygiene.

This barely needs any horsepower — WireGuard is famously lightweight. A 1 vCPU / 1 GB instance at Hetzner, Vultr or Infomaniak is plenty, and if you already have a VPS from the self-hosting tutorial, you can run WireGuard on it directly instead of renting a second box.

For provider options and pricing, see the Trusted VPS Providers section on the homepage. A few concrete links if you need one:

• Hetzner Cloud — cheapest way to get a solid European VPS
• Vultr — simple hourly billing, many locations worldwide (affiliate link — costs you nothing)
• Infomaniak — Swiss, renewable-powered, the host this site runs on (affiliate link — costs you nothing)

WireGuard has been part of the mainline Linux kernel since 5.6, and both Debian 12 and Ubuntu 24.04 ship kernels well past that, so there's no external repository or DKMS module to fight with — just install the userspace tools.

WireGuard uses public-key cryptography instead of usernames and passwords — every peer (server and each client) gets a keypair, and the config just lists which public keys are allowed to talk to whom.

Now create the interface config. WireGuard config files are plain text — no daemons to babysit, no database.

By default, a client on the VPN subnet (10.8.0.x) can reach the server itself, but not the wider internet through it. To turn your VPS into an actual gateway, you need three things: forwarding enabled in the kernel, a NAT rule so outbound packets look like they came from the server, and a firewall rule opening the VPN's UDP port.

First, find your server's real internet-facing interface — you'll need its name for the NAT rule:

Add PostUp/PostDown lines to the [Interface] block in /etc/wireguard/wg0.conf, replacing eth0 with the interface you just found:

nftables equivalent, if your system uses a pure nftables ruleset instead of iptables:

Next, enable IP forwarding permanently in the kernel:

Finally, open the WireGuard port in your firewall:

WireGuard ships with a systemd unit template that reads /etc/wireguard/<name>.conf — since our file is wg0.conf, the service is wg-quick@wg0.

No peers listed yet — that's expected, you haven't added a client. That's next.

Each device gets its own keypair and its own small slice of the VPN subnet. You can generate the client keypair on the server for convenience (shown below), or directly on the device using the official app — either way, the private key should never be needed anywhere else once it exists.

Add a [Peer] block to the server's /etc/wireguard/wg0.conf, using the client's public key and a unique VPN IP:

Apply the change without a full restart, or just restart the service:

Now write the client's config — this file goes on the laptop or phone, never on the server:

DNS: 9.9.9.9 is Quad9's public resolver — no logging, malware-domain filtering, a reasonable default. Point it at your own resolver instead if you run one (e.g. a Pi-hole reachable over the tunnel).

AllowedIPs — split tunnel vs. full tunnel:

• AllowedIPs = 0.0.0.0/0 (shown above) is a full tunnel — every packet from the device routes through the VPS. Best for untrusted Wi-Fi, since it protects all your traffic, not just some of it.
• AllowedIPs = 10.8.0.0/24 is a split tunnel — only traffic destined for the VPN subnet (i.e. your home lab) goes through the tunnel; everything else uses your normal internet connection directly. Faster, but doesn't protect general browsing.

PersistentKeepalive = 25: Almost every client sits behind some form of NAT (a home router, a mobile carrier's network). Without a keepalive, that NAT's mapping for the tunnel expires after a period of silence, and the server loses the ability to reach the client first. Sending a tiny packet every 25 seconds keeps that mapping alive. Leave this out only if the client itself has a public IP with no NAT in front of it.

Install the official WireGuard app for your platform from wireguard.com/install — Windows, macOS, Linux, Android and iOS are all covered, all open source, all from the WireGuard project itself.

Connect from your client, then check from both ends. A tunnel that "looks connected" but isn't actually carrying traffic is a classic false sense of security.

A recent "latest handshake" and non-zero transfer means the tunnel is genuinely up. latest handshake: (none) means it never negotiated at all — see Troubleshooting below.

On the client, once connected (with a full tunnel), confirm your traffic is really exiting through the VPS:

DNS leak check: Visit dnsleaktest.com and run the extended test. You should see only the resolver you configured (Quad9 or your own), never your ISP's or the local Wi-Fi network's DNS servers.

• Automatic security patches: sudo apt install unattended-upgrades -y keeps the OS patched without you having to remember.
• SSH keys only: Disable password authentication on the VPS (PasswordAuthentication no in /etc/ssh/sshd_config) — covered in the self-host tutorial's hardening step. A VPN is worthless if the box hosting it is trivially brute-forced.
• Key rotation: There's no built-in expiry, so rotate periodically yourself — generate a fresh keypair for a device, swap the PublicKey in its server [Peer] block and its own [Interface] section, then reload with wg syncconf.
• Removing a lost or stolen device: Delete that device's [Peer] block from /etc/wireguard/wg0.conf, then apply it immediately:

Once removed, that device's key is no longer accepted by the server — it can never reconnect, no matter how it tries.

Handshake never happens (wg show stays at latest handshake: (none)):

• UDP 51820 is blocked somewhere — check sudo ufw status on the server, and separately check any cloud-level firewall your provider offers (these sit in front of the OS and are easy to forget).
• Wrong Endpoint in the client config — a typo'd IP, the wrong port, or (if the client is on the same LAN during testing) a private IP instead of the server's real public one.
• Mismatched keys — the single most common mistake. The client's [Peer] PublicKey must be the server's public key, and the server's [Peer] PublicKey must be that client's public key. It's easy to paste the wrong one in the wrong place.

Handshake succeeds but no internet access:

• Confirm forwarding is actually on: sysctl net.ipv4.ip_forward should print 1.
• Re-check the egress interface name with ip route show default and make sure it matches exactly what's in your PostUp/PostDown MASQUERADE rule — a provider migration or a renamed NIC is a common silent breakage.
• Test incrementally: from the client, ping 10.8.0.1 (the server, inside the tunnel) should always work once the handshake succeeds. If ping 8.8.8.8 then fails, the tunnel itself is fine and the problem is specifically forwarding/NAT on the server, not WireGuard.

DNS isn't resolving (IP addresses work, domain names don't):

• Double-check the DNS = line in the client config points at a resolver that's actually reachable (e.g. 9.9.9.9).
• On Linux clients, wg-quick needs resolvconf or openresolv installed to actually apply that DNS setting system-wide (sudo apt install openresolv). The official mobile and desktop apps handle this automatically — this mostly bites manual wg-quick setups.
• Confirm it's really DNS and not general connectivity: if curl https://9.9.9.9 works but curl https://example.com doesn't, it's DNS.