Self-Hosted VPN on VPS: Complete Protocol Comparison and Setup Guide

Commercial VPN providers ask you to trust their no-log claims without verification. Even providers with external audits only audit a snapshot in time, and audit firms can only verify what they are shown. You have no visibility into the actual logging configuration of the servers you connect through, no way to verify that the provider is not receiving law enforcement requests, and no control over what happens to your data if the company is acquired or goes bankrupt.

A self-hosted VPN on your own VPS has none of these trust problems. You configure the logging behavior yourself - which means you can set it to log nothing. You control the server's access: no one else connects through your VPS's exit IP, so there is no shared pool of users whose activities could create legal problems for the infrastructure. You pay directly for the infrastructure and own the account, so there is no commercial VPN provider as an intermediary who could be compelled to provide account records.

The tradeoffs are real: you are responsible for keeping the server updated and the VPN software patched. If you are the only user of your VPS's IP address, traffic correlation becomes slightly easier (an adversary who can see both your connection to the VPS and the VPS's outbound connections can correlate them, whereas with a commercial VPN hundreds of users share the same exit IP). For threat models involving sophisticated state-level adversaries conducting traffic analysis, Tor is more appropriate than a self-hosted VPN.

For the majority of use cases - bypassing geographic restrictions, securing traffic on untrusted networks, preventing ISP-level traffic inspection - a self-hosted VPN on an offshore VPS is superior to commercial VPN services in terms of privacy, reliability (no shared infrastructure overloading), and cost (one VPS at $17.90/mo vs $5-15/mo for a commercial VPN plan that runs on someone else's server).

WireGuard is the recommended choice for most self-hosted VPN deployments in 2025. Setup takes under 10 minutes, throughput is the highest of any protocol, and the configuration is simple enough to understand in full without reference material. The only scenario where WireGuard is not the best choice is when you need to traverse firewalls that block UDP or specifically fingerprint and block WireGuard's handshake pattern.

OpenVPN is the fallback for censored environments. Its TCP-over-443 mode makes it indistinguishable from HTTPS traffic at the DPI level, giving it the best firewall traversal characteristics of any mainstream VPN protocol. It is slower than WireGuard (by 30-50% on typical hardware) and more complex to configure, but for users in Russia, Iran, or China where WireGuard is blocked, OpenVPN TCP-443 with TLS obfuscation is significantly more reliable.

IPSec/IKEv2 is natively supported by iOS, Android, Windows, and macOS without installing any additional software. This makes it valuable in enterprise deployments where device management prevents software installation. IKEv2 reconnects faster after network changes (switching from WiFi to cellular) than WireGuard or OpenVPN, which benefits mobile users. The configuration complexity is higher than WireGuard, particularly for certificate management, but tools like StrongSwan on Linux simplify the server side substantially.

For most personal use: deploy WireGuard. For censored regions: deploy OpenVPN with TCP/443 and obfuscation. For corporate mobile deployments: consider IKEv2. For maximum censorship resistance at the cost of performance: V2Ray with WebSocket+TLS transport on port 443. All four protocols run simultaneously on a single AnubizHost VPS, so you can deploy all of them and let each client use the appropriate protocol for their network environment.

Road warrior scripts automate the full server and client configuration process, reducing deployment time from hours to minutes. The most widely used are: angristan/wireguard-install (WireGuard), angristan/openvpn-install (OpenVPN), and angristan/ikev2-vpn-server (IKEv2). All three are open source, actively maintained, and designed for a single root-access VPS server with multiple road warrior clients connecting from variable IP addresses.

These scripts handle: package installation, certificate authority setup (for OpenVPN/IKEv2), firewall configuration, IP forwarding enablement, and client configuration file generation. Running any of them on a fresh VPS requires only root SSH access and takes under five minutes of interactive prompts. The output is a client configuration file (for WireGuard: .conf file; for OpenVPN: .ovpn file; for IKEv2: .mobileconfig or .p12) that you import directly into the client software.

For multi-protocol deployments, run each script sequentially on the same VPS. Assign each protocol a different port to avoid conflicts. Use a simple routing table to ensure all protocols use the same default gateway. Monitor all three services with a single systemd status check or a lightweight monitoring tool like uptime-kuma running locally on the VPS.

Keep the server updated to maintain security: enable automatic security updates with unattended-upgrades on Debian/Ubuntu. Subscribe to security announcements for the specific VPN software you run. For WireGuard, kernel updates cover the module; for OpenVPN, OpenVPN project releases cover the daemon. Critical vulnerabilities in VPN software are rare but when they occur they typically allow authentication bypass or remote code execution, making prompt patching essential.

DNS configuration is critical for a self-hosted VPN. If your VPN routes all traffic through the tunnel but the device continues using the local network's DNS resolver, DNS queries leak the sites you visit even though the traffic itself is tunneled. For WireGuard, set DNS in the client's [Interface] section to a trusted resolver (1.1.1.1 for Cloudflare, 9.9.9.9 for Quad9, or your own Unbound/Pi-hole running on the VPS). For OpenVPN, add push "dhcp-option DNS 1.1.1.1" to server.conf to push the DNS setting to all clients automatically.

Running an unbound resolver on the VPS itself is the most private DNS option: queries do not go to a third-party resolver but are resolved directly using the DNS root hierarchy. Install unbound (apt install -y unbound), configure it to listen on the VPN interface address (10.8.0.1 for an OpenVPN typical subnet, 10.0.0.1 for WireGuard), and use that address as the DNS server pushed to clients. Queries from your VPN clients resolve locally on your VPS without any third-party DNS provider seeing them.

Split tunneling allows routing some traffic through the VPN and some traffic directly to the internet. This is useful when you want to secure traffic to specific services while keeping low-latency direct connections to others (online gaming, streaming, video calls). In WireGuard, control this with AllowedIPs in the client configuration: 0.0.0.0/0 routes all traffic through the tunnel; specific CIDR ranges route only those addresses through the tunnel with everything else going direct. In OpenVPN, use push "route 192.168.0.0 255.255.0.0" style directives for split routing.

A kill switch prevents traffic from leaking to the internet if the VPN connection drops. For WireGuard on Linux, implement the kill switch using iptables rules that block all traffic not going through the wg0 interface, with exceptions only for the WireGuard UDP port to the server. For macOS and Windows WireGuard clients, the official app includes a built-in kill switch option. For OpenVPN, block-outside-dns on Windows and similar directives on other platforms prevent DNS leaks specifically; full kill switch requires firewall rules at the OS level.