WireGuard is the modern VPN protocol of choice — faster than OpenVPN, simpler than IPsec, and audited by security researchers. Running your own WireGuard server on a Russia VPS gives you complete control over your VPN infrastructure, avoids the trust model of commercial VPN services, and lets you select your exit jurisdiction. This tutorial walks through a complete production setup on Ubuntu 22.04, including split tunneling, kill switch, DNS leak prevention, and multi-client configuration.
1. Prerequisites
Before starting, you need: a Russia VPS running Ubuntu 22.04 LTS or 24.04 LTS, at least 1 vCPU and 1GB RAM (2GB recommended for multiple clients), root or sudo access, and a static public IP address. Most providers in our 2026 lineup meet these requirements out of the box. For this tutorial, we will use a PrivateAlps VPS in Moscow, but the steps are identical for any Ubuntu-based Russia VPS. Verify your server is up to date: SSH in as root, then run `apt update && apt upgrade -y` to install the latest security patches.
2. Installing WireGuard
WireGuard is included in the Ubuntu 22.04 kernel by default, so you only need to install the user-space tools. Run: `apt install wireguard wireguard-tools qrencode -y`. The `wireguard` package provides the kernel module (already loaded), `wireguard-tools` provides the `wg` and `wg-quick` commands, and `qrencode` is for generating client QR codes for mobile devices. Verify the installation with `wg --version` — you should see wireguard-tools 1.0.x or newer.
3. Generating Server Keys
WireGuard uses Curve25519 public-key cryptography. Each peer (server and client) has a private key and a public key. Generate the server private key with: `wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key`. Set strict permissions: `chmod 600 /etc/wireguard/server_private.key`. Note both keys — you will need the server private key in the server config and the server public key in each client config. Never share the private key with anyone.
4. Configuring the Server
Create the server configuration file at `/etc/wireguard/wg0.conf`. Use the following template, replacing the placeholders:
[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <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
The Address is the server's WireGuard IP (10.66.66.1 in the 10.66.66.0/24 subnet). The ListenPort is the UDP port WireGuard will listen on (51820 is the standard). The PostUp and PostDown commands set up NAT forwarding so client traffic can exit through the server's public interface (eth0 — adjust if your interface has a different name, check with `ip link`).
5. Enabling IP Forwarding
For the server to forward client traffic, IP forwarding must be enabled in the kernel. Edit `/etc/sysctl.conf` and uncomment or add: `net.ipv4.ip_forward = 1`. Apply the change with: `sysctl -p`. Verify with: `cat /proc/sys/net/ipv4/ip_forward` — it should output `1`. Without this step, clients will connect but cannot reach the internet through the VPN.
6. Starting and Enabling WireGuard
Start the WireGuard interface with: `wg-quick up wg0`. Verify it is running: `wg show` should display the interface, listening port, and server public key. Enable WireGuard to start on boot: `systemctl enable wg-quick@wg0`. Test the persistence by rebooting the server and verifying WireGuard starts automatically. The `wg-quick@.service` is a systemd template that takes the interface name as an argument — `wg0` in our case.
7. Generating Client Keys and Configurations
For each client (laptop, phone, tablet), generate a separate keypair: `wg genkey | tee client_private.key | wg pubkey > client_public.key`. Create a client configuration file:
[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.66.66.2/32
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
The Address must be unique per client (10.66.66.2 for the first client, 10.66.66.3 for the second, etc.). DNS is set to Cloudflare's resolver for privacy — you can also use your own DNS server or a Pi-hole. AllowedIPs = 0.0.0.0/0 means all client traffic goes through the VPN (full tunnel). For split tunneling, set AllowedIPs to specific subnets (e.g., 10.66.66.0/24 for VPN-only traffic).
8. Adding the Client to the Server
Each client must be added to the server's configuration as a Peer. Edit `/etc/wireguard/wg0.conf` and append:
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.66.66.2/32
The AllowedIPs here is the client's WireGuard IP — this routes traffic destined for that IP through the WireGuard tunnel. Restart WireGuard to apply: `wg-quick down wg0 && wg-quick up wg0`. Alternatively, use the live configuration command: `wg set wg0 peer <CLIENT_PUBLIC_KEY> allowed-ips 10.66.66.2/32` (no restart needed).
9. Configuring the Client
Install the WireGuard client on your device. On Linux: `apt install wireguard`. On macOS: install from the App Store or via Homebrew. On Windows: download from wireguard.com. On iOS/Android: install from the App Store / Google Play. Import the client configuration file (or scan a QR code on mobile — generate with `qrencode -t ansiutf8 < client.conf`). Connect and verify your IP has changed by visiting ipinfo.io. Run a DNS leak test at dnsleaktest.com to ensure your DNS queries are not leaking outside the tunnel.
10. Implementing a Kill Switch
A kill switch prevents traffic from leaking outside the VPN if the connection drops. On the client side, add these lines to the [Interface] section of the client config:
PostUp = iptables -A OUTPUT -o wg0 -j ACCEPT; iptables -A OUTPUT -o lo -j ACCEPT; iptables -A OUTPUT -j DROP
PostDown = iptables -D OUTPUT -o wg0 -j ACCEPT; iptables -D OUTPUT -o lo -j ACCEPT; iptables -D OUTPUT -j DROP
This drops all outbound traffic except through WireGuard and the loopback interface. When WireGuard is up, traffic flows normally. When WireGuard drops, all outbound traffic is blocked. Caution: this is aggressive — if WireGuard is down, you have no internet. Test by manually bringing WireGuard down and verifying you cannot reach the internet.
11. DNS Leak Prevention
DNS leaks are the most common VPN privacy failure. Even with all traffic routed through the VPN, your system may continue using the local DNS resolver, leaking your browsing history to your ISP. To prevent this, set the DNS in the client config (we used 1.1.1.1 above) and ensure your system respects it. On Linux, install `systemd-resolved` and configure it to use the VPN DNS. On macOS and Windows, the WireGuard app handles DNS automatically. Verify by running `nslookup example.com` while connected — it should resolve through 1.1.1.1, not your local DNS.
12. Multi-Client Management
For managing more than a few clients, consider using a WireGuard management UI like WireGuard UI, Firezone, or Hebigo. These web interfaces simplify client onboarding, key rotation, and revocation. For larger deployments, consider Headscale (an open-source Tailscale control server) which provides identity-based access, ACLs, and a polished client experience. For personal use with 5-10 clients, manual configuration is sufficient — keep a spreadsheet of client IPs and keypairs.
13. Hardening and Security
Several hardening steps improve security. Change the default port from 51820 to a random high port (e.g., 38792) to reduce log noise from scanners. Restrict SSH access to a different port with key-only authentication. Enable `ufw` firewall allowing only the WireGuard port and SSH. Set up fail2ban to block brute-force attempts. Regularly update WireGuard: `apt update && apt upgrade wireguard`. Rotate client keys every 6-12 months. Monitor the WireGuard log (`journalctl -u wg-quick@wg0 -f`) for unusual activity.
14. Monitoring and Logging
WireGuard is stateless and does not log connection metadata by default — this is a privacy feature. For basic monitoring, use `wg show` to see connected peers and traffic counters. For persistent monitoring, install `vnstat` to track bandwidth usage per interface. For alerting, set up a Prometheus + Grafana stack with the wireguard_exporter. Avoid logging client destination IPs or DNS queries — this defeats the privacy purpose of running your own VPN. If you must log for abuse response, log only connection timestamps and bandwidth, never destinations.
Conclusion
Setting up WireGuard on a Russia VPS gives you a fast, secure, self-hosted VPN with full control over your exit jurisdiction. The setup takes 30-60 minutes for the first server and 5-10 minutes per additional client. Pair WireGuard with a kill switch, DNS leak prevention, and basic server hardening for a production-grade privacy setup. For most users, a single Russia VPS running WireGuard is sufficient. For multi-region failover, deploy WireGuard on VPS in 2-3 jurisdictions and use a client-side script to switch between them based on latency.