What you need before you start
Running your own wireguard vpn vps is simpler than most tutorials make it look: install WireGuard on an Ubuntu VPS, generate two key pairs, write a short server config with a private subnet and NAT rules, enable IP forwarding, open UDP port 51820, and connect your first client with wg-quick. Twenty to thirty minutes if your VPS is already provisioned. This guide uses a Hostinger VPS with full root access, and every command was verified (checked 13 Oct 2026).
You need an Ubuntu VPS with root (any KVM plan works; WireGuard uses almost no resources), your server’s public IP, and basic SSH comfort. One gotcha to know up front: your public network interface is probably not called eth0 on a cloud VPS. Run ip -br link first and note the real name, often eth0, ens3, or enp1s0; the NAT rules below depend on it.
Installing WireGuard and generating your keys
WireGuard lives in Ubuntu’s standard repositories, so installation is one line:
- sudo apt update && sudo apt install -y wireguard
- Set a safe umask so keys are created private: umask 077
- Generate the server key pair: wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
- Lock the private key down: sudo chmod 600 /etc/wireguard/server.key
The private key never leaves the server; the public key is what you paste into client configs. Generate client keys the same way when you get to the client step, either on the client device or on the server and transferred securely.
Writing the server configuration
Create /etc/wireguard/wg0.conf with the following, replacing the placeholders:
- [Interface]
- Address = 10.8.0.1/24 (the server’s VPN-internal IP; pick a range you do not use anywhere else)
- ListenPort = 51820 (WireGuard’s default UDP port)
- PrivateKey = paste-the-contents-of-server.key
- PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
- PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
The PostUp and PostDown lines add and remove the NAT rule that lets VPN clients reach the internet through the server. Replace eth0 with the real interface name you found with ip -br link; getting this wrong is the most common reason clients connect but cannot load anything. Client [Peer] blocks get appended to this file in a later step.
Enabling IP forwarding and opening the firewall
Without IP forwarding, the server will not route packets between the VPN tunnel and the internet:
- echo ‘net.ipv4.ip_forward = 1’ | sudo tee /etc/sysctl.d/99-wireguard.conf
- sudo sysctl –system
- sudo ufw allow 51820/udp (make sure 22/tcp is allowed before enabling UFW, or you lock yourself out of SSH)
- sudo wg-quick up wg0, then sudo systemctl enable wg-quick@wg0 so the tunnel survives reboots
- Verify with sudo wg show; you should see the interface listening on 51820 with no peers yet.
Pick a data centre close to you from the real VPS list (France, Germany, Lithuania, UK, India, Indonesia, Malaysia, USA Phoenix/Boston, Brazil) to keep latency low on every hop.
Creating your client profile and connecting
Generate a key pair for the client the same way you did for the server. Then create the client config file (on Linux, /etc/wireguard/wg0.conf; on phones, import it into the WireGuard app):
- [Interface]
- PrivateKey = the-client-private-key
- Address = 10.8.0.2/24
- DNS = 1.1.1.1 (set this explicitly, or your device keeps using your ISP's resolver, which defeats much of the point)
- [Peer]
- PublicKey = the-server-public-key
- Endpoint = YOUR_VPS_IP:51820
- AllowedIPs = 0.0.0.0/0::/0 (routes all traffic through the VPN)
- PersistentKeepalive = 25 (keeps the connection alive behind home NAT)
Back on the server, append a [Peer] block to wg0.conf with the client's public key and AllowedIPs = 10.8.0.2/32, then sudo systemctl restart wg-quick@wg0. Connect with sudo wg-quick up wg0 on the client and confirm with sudo wg show: a latest handshake entry means you are in. For phones, qrencode -t ansiutf8 < client.conf prints a scannable QR code (install qrencode first).
Adding a second device the right way
Generate a fresh key pair for every device; never reuse one profile across a laptop and a phone. If a phone is lost, you want to revoke only that device:
- Create the second client config with Address = 10.8.0.3/24.
- Add another [Peer] block on the server: PublicKey = second-client-public-key, AllowedIPs = 10.8.0.3/32.
- Restart with sudo systemctl restart wg-quick@wg0.
To remove a device later without editing the file, run sudo wg set wg0 peer CLIENT_PUBLIC_KEY remove on the server.
Troubleshooting your wireguard vpn vps setup
Almost every failure falls into one of these buckets:
- No handshake ever appears: UDP 51820 is blocked. Check ufw, and check whether your provider has a separate cloud firewall in front of the VPS that also needs the port opened.
- Tunnel connects but no internet: the MASQUERADE rule points at the wrong interface, or IP forwarding is off. Re-check ip -br link and sysctl net.ipv4.ip_forward.
- DNS leaks: you skipped the DNS line in the client config. Set it explicitly and re-test with a leak test site.
- IPv6 bypass: if your device has IPv6 and the tunnel only carries IPv4, IPv6 traffic skips the VPN. Either carry IPv6 in the tunnel or disable IPv6 on the client.
- Connection drops on mobile networks: PersistentKeepalive = 25 suits most NAT setups; adjust if your carrier is aggressive.
When in doubt, sudo wg show and the system journal (journalctl -u wg-quick@wg0) tell you exactly which side is unhappy.
Honest limits: when a commercial VPN is the better choice
A self-hosted VPN is a single server in a single location, administered by you. There is no kill-switch app, no multi-hop, no fifty-country server list, and no support team when something breaks at 2am. Your traffic exits from one IP registered to your VPS account, so this buys you encryption on untrusted networks and access to your own services, not anonymity.
Be honest about acceptable use too: your VPS provider's terms still apply, and abuse complaints about traffic from your IP land on you. Do not torrent copyrighted material or run an exit node for other people on a personal VPS.
If you want many exit locations, audited no-logs policies, and apps with kill switches, Mullvad or Proton VPN are the honest better picks; they remove you from the admin seat entirely. And the renewal reality: VPS intro prices renew higher, so check Hostinger's renewal prices before choosing a term, and see current coupon options to cut the first invoice.
| Factor | WireGuard on a Hostinger VPS | Mullvad | Proton VPN |
|---|---|---|---|
| Exit locations | One: wherever your VPS sits | Around 50 countries | Dozens of countries |
| Price model | VPS plan; renewals rise after the intro term | Flat monthly rate, no price jumps | Free tier plus paid plans |
| Admin work | You patch, monitor, and fix it | None; install the app | None; install the app |
| Apps and kill switch | Manual configs; no built-in kill switch | Apps with kill switch on all platforms | Apps with kill switch on all platforms |
| Trust model | You trust your VPS provider with metadata | Audited no-logs policy | Audited no-logs policy |
| Best for | Encrypting cafe Wi-Fi; reaching your own services | Privacy-first browsing, many locations | Privacy with a free tier |
VPS KVM 2
24-month plan, paid upfront
Renews at $14.99/mo
- 2 vCPU + 8 GB RAM
- 100 GB NVMe storage
- 8 TB bandwidth
- Full root access
- n8n one-click template available
FAQ
It varies by country, and this is not legal advice. Most places allow personal VPN use, but some restrict or ban it, so check your local law before you build. Separately, your VPS provider's terms still apply: abuse complaints about traffic from your IP land on you.
No. Encryption protects your traffic from the local network and your ISP, but your VPS provider can still see connection metadata and timing, and the exit IP is registered to your account. A self-hosted VPN buys security on untrusted networks, not anonymity. For anonymity, audited commercial VPNs or Tor are the honest tools.
As many as you configure: each device gets its own key pair, its own VPN IP, and its own [Peer] block on the server. A handful of phones and laptops is trivial for even the smallest VPS; WireGuard's overhead per connection is tiny. If a device is lost, revoke just that peer with wg set wg0 peer PUBLIC_KEY remove.
Almost always a blocked UDP port 51820: check ufw on the server, and check whether your provider has a separate cloud firewall in front of the VPS that also needs an inbound rule. Next suspects are a wrong Endpoint IP or port in the client config, and mismatched keys. Confirm the server is listening with ss -tulpn | grep 51820.
AllowedIPs = 0.0.0.0/0 routes everything through the VPN, which is what you want on untrusted public Wi-Fi. A narrower value like 10.8.0.0/24 sends only VPN-subnet traffic through the tunnel and leaves the rest on your normal connection. Full tunnel is simpler and safer; split tunneling saves bandwidth and keeps local services fast.
No. Clients connect directly to your VPS IP on UDP 51820, so a domain is purely optional convenience. Skip DNS entirely unless you want a memorable hostname for your configs. That is one less moving part to maintain, which is part of the appeal of this setup.