hwdsl2/openvpn-install: a shell installer that turns a fresh Linux VPS into an OpenVPN server

What hwdsl2/openvpn-install actually removes from the job

Standing up OpenVPN by hand means installing the package, generating a certificate authority with EasyRSA, signing a server certificate, writing a server config, deciding on a tunnel subnet, pushing DNS to clients, enabling IP forwarding, and then repeating part of that for every device you want to connect. The script collapses that into one run. The README describes it as an installer for Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS, Fedora, openSUSE, Amazon Linux and Raspberry Pi OS, and the pitch is that you can set up your own VPN server in a few minutes even without prior OpenVPN experience.

The intended user is someone who already has a Linux server and wants a private tunnel without reading the OpenVPN manual first. The repository is a single shell script plus docs, not a service or a daemon, so there is nothing to keep running after install. The topics list (easyrsa, pki, ipv6, self-hosted) matches what the script does: it is a PKI bootstrapper wrapped around a package install.

One thing worth saying plainly: this is a server-side tool. It generates profiles for Windows, macOS, iOS and Android, but the README sends you to a separate document, docs/clients.md, to get those devices connected. The installer does not configure your phone.

How the script builds the server: packages, EasyRSA and the client profile

The mechanism is a linear Bash flow. It detects the distribution, installs OpenVPN and EasyRSA from the system package manager, initialises a PKI, and builds a server certificate and key. It then writes a server configuration that binds to the address, protocol and port you selected, and generates the first client certificate and key.

The client profile is the part most people care about. The script produces a .ovpn file that bundles the client certificate, key and CA material so a device can import one file instead of four. That is what makes the Windows, macOS, iOS and Android path workable without a second tool.

Two smaller decisions sit inside the flow. The README lists sysctl optimisation for VPN performance, which means the script writes kernel network tunables rather than leaving defaults, and dual-stack IPv4 and IPv6 support for VPN clients. The latter is a real constraint on your server: if the host has no IPv6, that part of the configuration has nothing to attach to.

After install, the same script becomes the management interface. It can add a client, export an existing client's configuration, list clients, revoke a client, or uninstall OpenVPN and delete all configuration. Revocation is where the PKI design matters, since it depends on the certificate revocation list being regenerated and served.

Installing it on Ubuntu or Debian and connecting a first client

The README's first step is downloading the script to the server. It offers a short URL and a curl fallback if wget is unavailable.

wget -O openvpn.sh https://get.vpnsetup.net/ovpn

With the file on disk, the fastest path is the non-interactive mode, which the README labels Option 1 and describes as auto install using default options.

sudo bash openvpn.sh --auto

Defaults are UDP, port 1194, Google Public DNS for clients, and a first client named client. If you need to choose the server's DNS name, the protocol, the port, the client DNS servers or the first client's name, run the script with no arguments instead and answer the prompts.

sudo bash openvpn.sh

When it finishes, the README says to run the script again to manage users or uninstall, and points to docs/clients.md for getting your computer or device onto the VPN. To add a second device without touching the interactive menu, the usage block documents a flag.

sudo bash openvpn.sh --addclient [client name]

The usage output also documents --exportclient, --listclients, --revokeclient and --uninstall. If your server sits behind a cloud firewall such as EC2 security groups or GCE firewall rules, the README is explicit that you must open UDP port 1194 yourself, or your chosen TCP or UDP port if you changed it. The script cannot do that for you.

Where the installer stops helping

The README does not document rollback. Uninstall exists as a flag, and the interactive path says to run the script again and select the appropriate option if you need to remove OpenVPN, but there is no described way to undo a partial install, and no mention of what happens to client profiles already distributed when you revoke a certificate.

Platform coverage is narrower than the feature list suggests. The server side is Linux only, across the listed distributions. The Windows, macOS, iOS and Android support is client-side, delivered by the generated profile and documented in docs/clients.md, not by an installer for those systems. If you are searching for how to install OpenVPN on Windows, this repository is not that tool.

The custom-options automation carries its own warning. The README shows feeding answers to the script through a here document, and then notes that the install options may change in future versions of the script. Any scripted deployment built on that input order is coupled to the current prompt sequence.

Finally, there are no retrieved releases. The project is distributed as a script fetched from a URL, so versioning is whatever is on master when you download it. Pinning a specific revision means fetching openvpn-install.sh from the repository directly rather than through get.vpnsetup.net.

How it compares with nyr/openvpn-install and with WireGuard

The obvious comparison is nyr/openvpn-install, which is what many people mean when they search for an openvpn install script. Both are Bash installers that wrap OpenVPN and EasyRSA. The difference visible in this repository is breadth and management surface: hwdsl2 covers a longer distribution list including AlmaLinux, Rocky Linux, openSUSE and Amazon Linux, and exposes a documented flag set (--addclient, --exportclient, --listclients, --revokeclient, --uninstall) plus a here-document path for unattended installs. If you are on a distribution the older script does not target, that is the deciding factor.

The second comparison is protocol, not installer. The same author publishes docker-wireguard and a wireguard-install script, and the README suggests optionally installing WireGuard, IPsec VPN or Headscale on the same server. WireGuard is a kernel-side protocol with a much smaller configuration surface; OpenVPN is a userspace process with certificates, a revocation list and a larger set of knobs. Choosing this project means choosing the certificate-based model, and the reason to do that is compatibility with networks and clients that expect OpenVPN profiles.

Maintenance, licence and what a fork inherits

The repository is not archived, and the last push was on 2026-09-08, which is recent. That matters more here than for a library, because the script installs packages from your distribution's repositories. If a distribution changes a package name or an EasyRSA path, the script needs an update; a fork that stops tracking upstream will break on newer releases before it breaks on older ones.

The licence is MIT, and LICENSE.txt sits at the top level. MIT is permissive, so redistributing a modified copy inside your own tooling is allowed provided you keep the notice. This is a description of the licence text, not legal advice; if you plan to ship a modified version commercially, read LICENSE.txt and the OpenVPN project's own licensing separately, since the installer and the software it installs are different works.

Upgrade cost is mostly human. There is no package manager entry for the script itself, so upgrading means re-downloading it. Re-running the installer over a live server is not described in the README as an upgrade path, and the uninstall flag deletes all configuration, so the safe assumption is that a re-run is a fresh install unless you have read the script's own logic.

Advanced installs and the here-document path

For repeatable provisioning, the README documents two mechanisms. The first is command-line options on the install, including --auto, --listenaddr, --serveraddr, --proto, --port, --clientname, --dns1 and --dns2. The second is a Bash here document that feeds answers to the interactive prompts, which the README says can also be used to provide input when managing users after install.

The README's own example shows the shape of that input.

sudo bash openvpn.sh <<ANSWERS
n
1
1194
2
client
y
ANSWERS

Read that block as a warning as much as an example. The answers map to prompts in order, and the README states the install options may change in future versions. A here document that works today can silently answer the wrong prompt after an upstream change, which in a provisioning pipeline means a misconfigured server rather than a failed run. The flag-based install options are the more stable surface; prefer them where they cover what you need.

Editorial conclusion

Adopt it if you already run a supported Linux server and want OpenVPN configured without hand-building a PKI; skip it if you need a Windows server, a GUI, or a WireGuard-style kernel data path. Before trusting it in production, read openvpn-install.sh end to end, check the LICENSE.txt terms, and confirm that your external firewall allows the UDP or TCP port you chose, since the script cannot open cloud security groups for you.

Frequently asked questions

Official sources

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