OpenVPN Comprehensive Guide¶

This is the index and conceptual overview for a set of OpenVPN docs, rebuilt from
years of accumulated notes. It replaces the old scattered wiki-style pages with
one linked set, updated for modern OpenVPN (2.5/2.6) and current best practice
(EasyRSA 3, tls-crypt, AEAD ciphers, no compression).

Guide map¶

Read this doc first for the concepts, then jump to whichever doc matches the
task in front of you.

What OpenVPN is¶

OpenVPN is an open-source VPN daemon that builds an encrypted tunnel over UDP
or TCP using a TLS handshake for key negotiation, then an SSL/TLS-derived
channel for data. It's not IPsec and not WireGuard — it runs in userspace,
talks to a virtual network interface via TUN/TAP, and is scriptable at nearly
every stage of the connection lifecycle (--up, --down, --route-up,
client-connect scripts, etc.). That scriptability is why it's stuck around:
it's flexible, but that flexibility is also where most of the footguns in the
old notes came from (hand-rolled systemd units, manual route scripts, etc.).

Core architecture decisions¶

These are the choices you make once, up front, that everything else depends
on.

TUN vs. TAP¶

• TUN (routed, layer 3) — the standard choice. Clients get an IP on a
  dedicated VPN subnet and traffic is routed. Simpler, more efficient, works
  everywhere. Use this unless you have a specific reason not to.
• TAP (bridged, layer 2) — clients join the same Ethernet broadcast
  domain as the server's LAN. Needed for things like Wake-on-LAN across the
  tunnel or legacy broadcast-dependent protocols. More overhead, more
  fragile, and mostly obsolete now — most things people used TAP for
  (browsing "as if local," NetBIOS discovery, etc.) either don't matter
  anymore or are better solved with routing plus mDNS/reflection.

Everything in this doc set assumes TUN, which is what the original notes
used.

PKI (certificate-based) vs. static key¶

• Static key (--secret) — one shared key for a single point-to-point
  tunnel, no CA, no per-client identity, no revocation. Fine for a quick
  site-to-site link between two boxes you control. Doesn't scale past two
  peers and can't be revoked without regenerating the key for everyone.
• TLS mode with a PKI (CA + per-client certs) — what you want for
  anything with more than one client. Each client has its own identity,
  which means you can revoke a single laptop without touching anyone else,
  and you get mutual authentication (server proves who it is, client proves
  who it is) instead of a single shared secret.

The rest of this guide set uses PKI/TLS mode, matching the original
setup.

Control-channel protection: tls-auth vs. tls-crypt¶

The old notes used tls-auth, which HMAC-signs control-channel packets so
OpenVPN can silently drop anything not signed with the shared key (mitigates
port scanning, DoS, and TLS stack attacks before a real handshake even
starts). tls-crypt does the same thing but also encrypts the control
channel, which additionally hides certificate metadata (CNs, cert
fingerprints) from anyone sniffing the handshake. There's no real downside to
tls-crypt on a normal client/server setup — use it instead of tls-auth.
Details and the migration are in
openvpn-security-hardening.md.

What changed since the original notes¶

The source notes were written against OpenVPN ~2.2–2.3 conventions. A few
things have moved on enough that carrying them forward as-is would be
actively bad advice:

• comp-lzo is gone. VPN compression combined with encryption enables
  the VORACLE attack (compression-oracle plaintext recovery, same family as
  CRIME/BREACH). Compression is disabled in the configs throughout this
  guide set. See openvpn-security-hardening.md.
• cipher AES-256-CBC + auth SHA256 (separate encrypt + HMAC) is
  replaced with data-ciphers AES-256-GCM, an AEAD cipher that does
  authenticated encryption in one pass — faster and removes a category of
  padding-oracle style bugs. The old cipher/auth directives still work
  for backward compatibility but are legacy syntax now.
• Manual openssl ca commands are replaced with EasyRSA 3. The original
  notes ran raw openssl req/openssl ca against a hand-maintained
  openssl.cnf. That's fragile (serial file collisions, index.txt drift,
  easy to get file permissions or extensions wrong) and EasyRSA has been the
  standard companion tool for exactly this since well before the original
  notes were written. All PKI steps in this guide set use it.
• tls-version-min 1.2 stays, but TLS 1.3 is preferred where both ends
  support it — set tls-version-min 1.2 as the floor and let negotiation
  pick 1.3 when available, rather than pinning to 1.2.
• Hand-rolled systemd units are replaced with the native
  [email protected] template that ships with the OpenVPN package,
  which sidesteps the boot-time routing race the old notes flagged as an
  unsolved TODO. See
  openvpn-systemd-service.md.

Terminology quick reference¶