OpenVPN VPS Hosting: Deploy a Private VPN Server Offshore

OpenVPN has been the gold standard for self-hosted VPNs for over two decades. It supports both UDP and TCP transport, which matters when you need to traverse restrictive firewalls: TCP mode over port 443 is indistinguishable from HTTPS traffic at the packet level, making it difficult for DPI systems to block without breaking web browsing. WireGuard only runs over UDP and uses a fixed port, making it easier for censorship systems to fingerprint and block.

OpenVPN's client ecosystem is more mature. Nearly every consumer router running DD-WRT, Tomato, or OpenWrt has OpenVPN client support built in, allowing you to VPN your entire home network without installing software on individual devices. Enterprise MDM solutions typically support OpenVPN configuration profiles natively. WireGuard's router support is improving but is not yet as universal.

The tradeoff is performance and complexity. OpenVPN runs in user space and is CPU-intensive at high throughput. For a personal VPN with a handful of simultaneous users, a 2 vCPU plan handles full-speed connections easily. For dozens of simultaneous users, plan for at least 4 vCPUs and consider the anubizhost.com dedicated VPS options. Configuration is also more involved: certificates, CA management, and a tls-auth or tls-crypt pre-shared key require more initial setup time than WireGuard's key exchange model.

If your primary concern is bypassing censorship infrastructure, OpenVPN TCP on port 443 is significantly more effective than WireGuard. If your primary concern is throughput and simplicity, WireGuard wins. Many operators run both on the same VPS to serve different use cases.

The fastest path to a working OpenVPN server is the angristan/openvpn-install script, which automates certificate authority setup, server configuration, and firewall rules. After SSHing into your root-access VPS, run: curl -O https://raw.githubusercontent.com/angristan/openvpn-install/master/openvpn-install.sh && chmod +x openvpn-install.sh && ./openvpn-install.sh. The script prompts for your server's public IP (pre-populated automatically), preferred port, protocol (UDP recommended for performance, TCP for firewall bypass), DNS resolver, and the first client name. It generates all certificates using Easy-RSA and produces a .ovpn configuration file for your first client.

The script enables the OpenVPN service on startup automatically. After the script completes, verify the server is running: systemctl status openvpn@server. Transfer the generated .ovpn file to your client using scp or a secure file transfer method. Import it into the OpenVPN client on your device and connect. Your traffic now exits through your offshore VPS.

Adding subsequent clients is done by re-running the script and selecting the option to add a new client. Each client gets a unique certificate so revocation of one client does not affect others. The script handles all Easy-RSA CRL operations automatically. For organizations deploying to many users, consider running the script non-interactively with environment variables for unattended bulk client generation.

For TCP-over-443 bypass mode, re-run the script and select TCP port 443. You will need to disable any other service listening on port 443 on the VPS (typically nginx or Apache if installed). An alternative is to use stunnel to wrap OpenVPN UDP traffic in TLS and forward it through port 443 while keeping a web server running on a different port, creating a service that looks identical to HTTPS to DPI systems.

OpenVPN uses a PKI (Public Key Infrastructure) model where your VPS acts as a certificate authority. Every client receives a certificate signed by your CA. The server validates client certificates at connect time, meaning only clients with valid signed certificates can connect. This is fundamentally more secure than WireGuard's pre-shared-key model for multi-user deployments: revoking a specific user's access requires only revoking their certificate, not rotating a shared secret.

Easy-RSA, the certificate management tool bundled with the openvpn-install script, stores the CA private key on your server at /etc/openvpn/easy-rsa/pki/private/ca.key. Protect this file aggressively: back it up to an encrypted offline location and restrict file permissions. If the CA key is compromised, an attacker can generate certificates that your server will accept as valid. A compromised CA key requires rotating the CA and re-issuing all client certificates.

For organizations with many users, consider moving to a proper PKI tool like HashiCorp Vault (with its PKI secrets engine) to manage certificate issuance and revocation. Vault can issue short-lived certificates (valid for 24-72 hours) that automatically expire, reducing the window of compromise if a certificate is stolen. This approach pairs well with an LDAP or SAML identity provider for centralized user management.

Enable client-to-client isolation in your OpenVPN server configuration if users should not be able to communicate with each other through the VPN. Add client-to-client in server.conf to allow peer communication, or omit it (the default) to route all traffic only to and from the internet. This is an important setting for multi-tenant deployments where users share the same VPS but should have no visibility into each other's VPN activity.

Default OpenVPN configurations are not optimized for throughput. Three tuning parameters make the largest difference: increasing the tun-mtu to 1500, enabling fragment 1300, and adding mssfix 1300 to reduce TCP-over-VPN retransmission. These settings align the tunnel's effective MTU with the underlying network path, preventing fragmentation that degrades throughput significantly on high-latency connections.

Enable compression only if your workload involves compressible data and you have ruled out VORACLE attack vectors. The VORACLE vulnerability (CVE-2018-4994) demonstrated that TLS compression combined with VPN traffic can leak plaintext data in some configurations. For general internet traffic where payload content is already compressed (TLS, video, compressed archives), disabling compression is both safer and has negligible performance impact.

For CPU-bound scenarios at high throughput, enable AES hardware acceleration. On modern Intel/AMD processors, OpenVPN can use AES-NI instructions via OpenSSL. Verify with openssl speed aes-128-cbc - if the output shows hardware acceleration is active, AES-128-GCM in your cipher directive will utilize AES-NI and deliver significantly higher throughput than software AES. AnubizHost KVM instances expose the host CPU's AES-NI instructions to guest VMs.

Monitor per-client throughput and connection counts using the OpenVPN management interface. Enable it in server.conf with management localhost 7505 and connect via nc localhost 7505 to query real-time status. Prometheus exporters for OpenVPN are available if you want to integrate VPN metrics into a broader observability stack. Track connected clients, bytes in/out per client, and connection duration to identify heavy users and plan for capacity.