hwdsl2/openvpn-install: A Shell Script That Turns a Fresh VPS Into an OpenVPN Server

What the script replaces, and who it is written for

Installing OpenVPN by hand means installing the package, initialising a PKI with EasyRSA, building a certificate authority, issuing a server certificate, writing a server.conf, enabling IP forwarding, adjusting firewall rules, generating a client profile, and repeating the last step for every device. Each of those steps has its own failure mode, and the failure usually surfaces as a TLS handshake error rather than a clear message. This project collapses the sequence into one Bash script. The README frames the audience directly: it lets you set up your own VPN server in a few minutes, even if you have not used OpenVPN before. The practical target is a single administrator with one cloud server or VPS who wants a private tunnel for a handful of devices, not a platform team managing hundreds of peers. Support is claimed for Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS, Fedora, openSUSE, Amazon Linux and Raspberry Pi OS, which covers most of the cheap VPS market and the common single-board computer case.

The mechanism: a one-shot installer plus a management mode

The script is not a daemon and does not watch for configuration drift. It has two modes. On first run it performs installation: package installation, PKI generation, server configuration, and creation of the first client. On later runs it switches to management, exposing subcommands for adding, listing, exporting and revoking clients, plus a full uninstall. The README describes the install as fully automated with no user input needed, and separately offers an interactive path for custom options. The interactive path collects the server DNS name, protocol, port, client DNS servers and the name of the first client. For repeatable deployments, the script accepts command line flags such as --auto, --proto, --port, --clientname, --dns1 and --dns2, and it can also read answers from a Bash here document. That here-document route is worth noting because it is the closest thing to an unattended, reproducible install the project offers, and the README warns that the install options may change in future versions, so the answer sequence is not a stable interface. Client profiles are generated for Windows, macOS, iOS and Android, and the README states that sysctl settings are adjusted for VPN performance and that clients get dual-stack IPv4 and IPv6.

Getting it running: download, install, then manage clients

The documented download step is a single wget against a short URL. The script is then run with sudo. For a default install the README gives sudo bash openvpn.sh --auto. For the interactive path it gives sudo bash openvpn.sh with no arguments. If wget is unavailable, curl -fL -o openvpn.sh https://get.vpnsetup.net/ovpn is offered as an alternative, along with raw GitHub and GitLab URLs. After installation, the same script becomes the management tool: --addclient, --exportclient, --listclients and --revokeclient each take a client name, and --uninstall removes OpenVPN and deletes all configuration. The -y flag assumes yes when revoking a client or uninstalling, which matters in scripts because those operations are otherwise interactive. One operational detail the README repeats for both install paths: on servers behind an external firewall, such as EC2 security groups or GCE firewall rules, you must open the VPN port yourself. The default is UDP 1194. The script cannot open a cloud provider's firewall for you, and a closed port produces a connection that simply times out with no server-side error.

Where it stops being the right tool

The uninstall path is the sharpest limitation. Running the script and choosing removal, or passing --uninstall, deletes all configuration, and certificates live in that configuration. There is no documented export-and-restore workflow for the PKI, so a mistaken uninstall or a rebuilt server means reissuing every client certificate and redistributing every profile. Treat the PKI directory as data you back up separately, and treat the script as something you run once rather than something you can safely re-run to converge a drifted server. The second limitation is state management. Because the script is imperative, there is no manifest describing the intended set of clients. If a colleague adds a client manually on the box, nothing records it. Teams that expect a configuration file checked into Git and applied by a tool will find this model backwards. Third, the here-document install is explicitly version-sensitive; the README states the install options may change, so any automation built on a fixed sequence of answers can break on a script update with no deprecation warning. Finally, the README does not document kernel or OpenVPN version requirements, so on an older distribution you are relying on the package manager to resolve a compatible OpenVPN build.

How it differs from WireGuard-based installers

The most informative comparison is with the same author's WireGuard installer, which the README lists under Docker VPN and as an optional co-install. The difference is not quality but protocol model. OpenVPN is a userspace TLS VPN: it uses certificates, a PKI, and a client profile per device, which is exactly why this script has --addclient, --revokeclient and --exportclient as first-class operations. Revocation is a certificate operation, and access control is per-certificate. WireGuard uses static keypairs per peer and a much smaller codebase in the kernel, with no certificate authority to run. That makes WireGuard cheaper to reason about for a fixed set of peers, and it removes the PKI backup problem described above. It also means WireGuard has no equivalent of a certificate revocation list: removing a peer means editing the peer list on the server. OpenVPN's certificate model is the reason to pick this project instead, because revocation and per-client identity are built into the protocol. If your reason for choosing OpenVPN is only that you have heard of it, the WireGuard installer from the same author is the smaller system to operate. If you need certificate-based revocation, TCP transport on port 443 for restrictive networks, or compatibility with clients that already speak OpenVPN, this script is the one to use.

Maintenance cost and the MIT licence in practice

The maintenance surface is small but real. The script is a single Shell file distributed from a short URL, so there is no package to pin and no version number in the download path. That means an install performed today and an install performed in six months may run different code, and the README's warning about changing install options applies to that gap. The repository shows an active CI workflow via the build status badge, and the last push date is recent, but the material provided contains no release tags, so there is no changelog to read before updating. Practically, you should pin the script by saving a copy alongside your server notes rather than re-downloading it blindly, and you should record which OpenVPN and EasyRSA versions the distribution installed. The licence is MIT, which is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are included. It comes with no warranty, so operational failures are yours. This is not legal advice; if you redistribute the script inside a product, have counsel review the notice requirements.

What to verify before you commit a server to it

Four checks are worth doing before the install rather than after. First, confirm the server has a stable public IPv4 address or a fully qualified domain name, because the install options require one or the other and a changing address invalidates client profiles. Second, confirm the port you intend to use is open in any external firewall, since the README is explicit that cloud security groups and GCE firewall rules are outside the script's control. Third, decide where the PKI will be backed up, because --uninstall deletes it and the README documents no restore path. Fourth, if you plan to automate the install, test your here-document sequence against the current script and re-test it whenever you re-download, since the answer order is not a stable interface. After that, the decision is straightforward. Run sudo bash openvpn.sh --auto on a single VPS and you have a working server in minutes. Run it as the configuration source of truth for a fleet and you will spend more time reconciling state than the script saved you.

Editorial conclusion

Adopt it if you administer a single Linux VPS and want an OpenVPN server with client certificates without hand-editing EasyRSA and server.conf. Do not adopt it if you need a declarative, version-controlled configuration or a daemon that reconciles state on a schedule; this script runs once and then gets out of the way. Before running it, confirm the server has a public IPv4 address or a fully qualified domain name, that UDP port 1194 (or your chosen port) is open in any external firewall, and that you have a plan for backing up the PKI directory, because the documented uninstall path deletes all configuration.

Official sources

1. hwdsl2/openvpn-install on GitHub
2. Issues
3. License: MIT
4. README