Why run your own WireGuard tunnel
A commercial VPN is a product someone else operates: you trust their client, their servers, and their no-logs claim. Running WireGuard on a VPS you rent flips that around. You hold the keys, you choose the location, and the tunnel carries only your traffic. It’s the difference between renting a seat on a bus and driving your own car.
The practical wins are concrete. You can reach a home NAS, a self-hosted Nextcloud, or a private database as if you were on the LAN, from any network you happen to be on. You sidestep the shared blocklists that get commercial VPN exit ranges banned from sites and APIs. And because the underlying server is no-KYC and payable in Monero, renting it doesn’t attach another identity record to your name.
Be honest about what this is
A single-user WireGuard tunnel gives you privacy from your local network and full control of the exit — it does not give you anonymity. All of your traffic leaves from one IP address dedicated to you, so anyone watching that exit sees a stable, consistent address tied to everything you do. Part of a commercial VPN’s value is the crowd: hundreds of users behind one exit. Your own server has no crowd. If your goal is to blend in or resist traffic correlation, that’s a job for Tor — see our Tor relay page — not a personal VPN. We’d rather you know that up front than sell you a false promise.
Stand up WireGuard in about ten minutes
The steps below build a working tunnel on a fresh Ubuntu 24.04 server. Replace the placeholder keys and the endpoint IP with your own, and read WireGuard’s docs before you rely on this for anything important.
1. Install
sudo apt update && sudo apt install -y wireguard qrencode2. Generate server and client keys
cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key
wg genkey | tee client_private.key | wg pubkey > client_public.keyumask 077 keeps the private keys readable only by root. Never share a
*_private.key; only the public keys are exchanged between peers.
3. Write the server config
Create /etc/wireguard/wg0.conf. The PostUp/PostDown lines turn on NAT so
traffic from the tunnel can leave through the server’s main interface — change
eth0 if yours is named differently (check with ip route).
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of server_private.key>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = <contents of client_public.key>
AllowedIPs = 10.8.0.2/324. Enable IP forwarding
The kernel won’t route between interfaces until you allow it:
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system5. Bring the interface up
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0 # start on boot
sudo wg show # verify the interface is listeningOpen UDP 51820 in your firewall (and any provider-side firewall) so clients can
reach the ListenPort.
6. Add a client, and a QR for mobile
Create a client.conf on your laptop or on the server. AllowedIPs = 0.0.0.0/0
routes all traffic through the tunnel; narrow it to a subnet if you only want to
reach specific hosts.
[Interface]
Address = 10.8.0.2/24
PrivateKey = <contents of client_private.key>
DNS = 1.1.1.1
[Peer]
PublicKey = <contents of server_public.key>
Endpoint = <your-server-ip>:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25On desktop, drop that file in and run wg-quick up client. For a phone, render the
same config as a QR code and scan it in the WireGuard app:
qrencode -t ansiutf8 < client.confAdding more devices
Each laptop and phone needs its own keypair and its own address inside the tunnel.
Generate a new key with wg genkey, add a matching [Peer] block to wg0.conf
with a unique AllowedIPs (10.8.0.3/32, 10.8.0.4/32, …), then reload with
sudo wg syncconf wg0 <(wg-quick strip wg0). Giving every device its own key means
you can revoke one without touching the others — pull the peer, reload, done.
Which plan fits
A personal VPN is light work. WireGuard’s kernel implementation is efficient, and a single-user tunnel rarely stresses the CPU — the bandwidth allowance usually matters more than core count. The Nano plan (1 vCPU / 2 GB) is sized for exactly this. Step up only if you’ll route several heavy users at once or plan to saturate the link continuously.
This page is about running the software; the strategy and the policy are yours. Whatever exits the tunnel is your responsibility under our AUP — a private tunnel is not an excuse desk, and we operate an abuse contact like any serious host.