VPN Guide · 1 min read

How to set up WireGuard on a VPS in 10 minutes

WireGuard is the fastest, simplest modern VPN protocol, and standing up your own on a cheap VPS takes minutes. Here is the full server and client config, the one NAT rule that makes it route, and how to verify it.

Why WireGuard, and what you are building

WireGuard is a modern VPN protocol built into the Linux kernel: a few hundred lines of code, state-of-the-art cryptography (ChaCha20, Curve25519), and configuration so small it fits on a screen. Compared with OpenVPN it connects faster, runs faster, and is far easier to reason about — see WireGuard vs OpenVPN. Standing up your own on a VPS gives you a private full-tunnel exit whose IP is yours alone.

The build has four parts: install WireGuard, generate a key pair for each peer, write a server config that NATs client traffic out to the internet, and write a client config that points at the server. The whole thing genuinely takes about ten minutes.

Server and client config

Run on a fresh VPS. Generate keys, write the server interface, add the masquerade rule, then create a matching client config. Replace VPS_PUBLIC_IP and the keys.

bash
# --- 1. install & generate keys (server) ---
apt update && apt install -y wireguard
cd /etc/wireguard && umask 077
wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee client.key | wg pubkey > client.pub

# --- 2. /etc/wireguard/wg0.conf (server) ---
cat > /etc/wireguard/wg0.conf <<CFG
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = $(cat server.key)
# NAT client traffic out to the internet (eth0 = your WAN iface):
PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = $(cat client.pub)
AllowedIPs = 10.8.0.2/32
CFG

# --- 3. enable IP forwarding & start ---
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf && sysctl -p
systemctl enable --now wg-quick@wg0

# --- 4. client config (put on your laptop/phone) ---
# [Interface]
# Address = 10.8.0.2/24
# PrivateKey = <contents of client.key>
# DNS = 1.1.1.1
# [Peer]
# PublicKey = <contents of server.pub>
# Endpoint = VPS_PUBLIC_IP:51820
# AllowedIPs = 0.0.0.0/0        # full tunnel; ::/0 too for IPv6
# PersistentKeepalive = 25

Verify it, and the honest trade-off

Use the configured UDP port, commonly 51820, and compare the observed exit IP. AllowedIPs = 0.0.0.0/0 covers IPv4 destinations when the interface and routes are active. Handling IPv6 also requires working IPv6 routing or a deliberate blocking policy; DNS needs separate configuration. Narrower routes make a split tunnel. Poor performance may involve routing, loss, CPU or MTU, so measure before changing settings.

A self-hosted exit and the s4m VPN involve different operational responsibilities; neither guarantees anonymity. A dedicated IP is an assignment option, not proof of unlinkability. Check supported protocols and issued profiles rather than inferring them from a product label. See the client setup guide and WireGuard quick start.

Share this page
FAQ

Questions, answered

Why does my WireGuard tunnel connect but have no internet?

Almost always a missing NAT rule or IP forwarding. The server needs net.ipv4.ip_forward=1 and a POSTROUTING MASQUERADE rule on its WAN interface so client traffic is translated out to the internet. Without both, packets reach the server and stop.

Is a self-hosted VPN more anonymous than a commercial one?

Usually less. A private VPS exit is used only by you, so it is directly linkable to you. A shared-IP commercial VPN blends your traffic with many users. Self-hosting gives control; a shared no-logs VPN gives anonymity through the crowd.

Your tunnel, or ours

Self-host WireGuard for full control of one exit, or use the managed s4m WireGuard/OpenVPN VPN — no-logs, RAM-first, shared exit for anonymity — with a dedicated IP when you want a private one.

People found this page by searching for

Real search phrases this page answers — the linked ones open the page that covers them in depth.