I noticed a few minor issues with the server and client configuration files:

You might want to set up a CRL (certificate revocation list) and use the crl-verify directive in the server config file to revoke client certificates in case of a compromise.

OpenVPN 2.4.0 ships with with the new compress option lz4-v2, which is undocumented. It seems to use less CPU, drain less power on mobile devices, and it possibly has a higher throughput according to this ticket.

There’s no need to specify push "compress lz4" in the server config file if the client config file has its own compress directive.

There’s no need to specify a key-direction (0 or 1) after tls-crypt’s keyfile path according to the manpage: “In contrast to –tls-auth, –tls-crypt does not require the user to set –key-direction.”

I usually bundle all the certificates and keys along with the client configuration in a .ovpn file, which I find easier to transfer around and use.

Thank you very much for your feedback! I will update the article when I will have some time.

About the compression part, I learnt it is now considered as unsecured thanks to voracle vulnerability, I will probably explain it briefly and disable in the configuration offered because security is the first criteria.

I’ve used OpenVPN for years, but the whole setup and maintenance process looks outdated. Recently started using Wireguard[1] in production which is quick to set up and hardly requires any maintenance. It also works well in containerized world.

Unfortunately there’s not yet kernel support for Wireguard, so maintenance is higher than it would be otherwise (e.g. dependence upon wireguard maintainer keeping out of tree module up to date for latest kernels, and you (or your distro) having to build it out of tree).

It seems like he’s close to getting it merged though, so I’m holding out for that!

Maybe in this one specific case, but I’ve been burned in the past by relying on an out of tree module (or set of patches), only to have the developer lose interest, sell out, whatever. (e.g. grsec). It’s rare I suppose, but the burden on users and admins is high when it does happen.

(the same fate could happen to patches/modules in the tree, but it’s much more rare)

I do not think you can compare now Wireguard and OpenVPN in term of reliability. Wireguard is still something new, does not be audited by security team yet and does not have a strong maintainability process. A little quote from the authors:

As of June 2018 the developers of WireGuard advise treating the code and protocol as experimental, and caution that they have not yet achieved a stable release compatible with CVE tracking of any security vulnerabilities that may be discovered.[7][8]

WireGuard has received formal verification from the developers [1], audited by [2], and reviewed by kernel developers and distributions that ship the kernel module.
I don’t have numbers on the number of reviewers versus SLOC count but I suspect it could be much higher than OpenVPN given the size of WireGuard

They’re saying that because they’re trustworthy, security folks. We always advise to say don’t trust it until proven otherwise with strong review and/or verification. There’s been some impressive results in verifying Wireguard on top of the fact that it’s so much smaller than competing implementations.

For now, I’ll just give you this article for some nice comparisons. Also, that article says OpenVPN is about 600,000 lines of code. The most-secure systems were thousands to tens of thousands of lines of code because smaller systems are easier to bulletproof. I don’t need to look at OpenVPN’s security advisories to know it will have more errors with more complexity.

The CRL procedure should be documented also. I came across a team who assumed that deleting the certification from “key” directory was enough to lock out users. Additionally an explanation of the meaning of flags found in the “index.txt” would be nice :-)

Addendum: another part that I find missing and misunderstood by admin teams is the”proper” way of certification creation. Users should issue a CSR and have it signed. Most real world uses I came across, the admin just issues everything and sends the OVPN file. Very common anti-pattern.

I wanted to write an article about the entire lifecycle of openvpn and user management. Yours is close though.

It would be quite useful if the article explained why they are doing things a certain way, why you should copy and paste this particular config. It’s not that I don’t trust them, but I’d prefer to have the illusion of understanding the configurations I piece together.