Learn OpenVPN - Production-Ready Deployment & Maintenance

#Introduction

All previous episodes built functionality and resilience. Episode 21 answers the most often forgotten question: how is this VPN maintained over the years? Certificates will expire, hardware will fail, and OpenVPN will release new versions.

Episode 21 covers production-ready deployment and maintenance. You'll build a checklist covering PKI rotation, certificate renewal with ACME, backup and disaster recovery, safe upgrade strategies, and deployment patterns from bare-metal to Kubernetes and IaC.

The key concept: a VPN that isn't maintained is an accident waiting to happen. A healthy production deployment is one that can be restored, upgraded, and have its keys rotated without panic.

#PKI Rotation and Renewal

#Building a Rotation Cycle

A PKI is not a static object — CAs, keys, and certificates all must be rotated on schedule. Root CA rotation is rare and requires a formal process, while leaf and server certificates rotate more often.

A healthy rotation checklist:

• Audit the list of certificates still in use every month.
• Rotate server keys at most once a year.
• Rotate sensitive client keys more often.
• Keep a trace of who holds which certificate for quick revocation.

#Certificate Renewal with ACME

OpenVPN server certificates can be renewed automatically with the ACME protocol, just like web certificates. With plugins like acme.sh or certbot, renewal happens without human intervention:

acme.sh --issue --dns dns_cf -d vpn.example.com
acme.sh --install-cert -d vpn.example.com \
  --key-file /etc/openvpn/server/server.key \
  --fullchain-file /etc/openvpn/server/server.crt

acme.sh --install-cert places the new certificate in the paths used by OpenVPN. Add a hook to restart the service after renewal:

systemctl reload openvpn-server@server

systemctl reload openvpn-server@server makes the daemon load the new certificate. Some versions require a full restart, so test this behavior before relying on full automation.

#Backup and Disaster Recovery

#What Must Be Backed Up

What makes OpenVPN unique: without the key material, the whole VPN cannot be restored. The backup must include the PKI directory, server and client configurations, CCD files, and firewall configuration:

tar czf /backup/openvpn-$(date +%F).tar.gz \
  /etc/openvpn /etc/easy-rsa /etc/iptables

tar czf /backup/openvpn-$(date +%F).tar.gz /etc/openvpn /etc/easy-rsa /etc/iptables packs all important state into one dated file. This archive is your ticket out when disaster strikes.

#Testing Restore

A backup that's never tested isn't a backup. Periodically, restore the archive to an empty machine and confirm the server runs. A useful test scenario: spin up a new machine, restore the archive, start the service, and verify a client can connect.

#Upgrade Strategy

#Reading Releases and Planning

Before upgrading, read the changelog and release notes — especially the breaking changes section. Also check which versions are in maintenance status and which are end-of-life. OpenVPN 2.6 and 2.7 have different release schedules, so you need to know which upgrade path you're on.

#Rollback as Part of the Plan

Upgrades can always fail. Keep the old version packages and a configuration snapshot before upgrading, so rollback is just a matter of reinstalling the previous version:

cp /etc/openvpn /etc/openvpn.bak-$(date +%F)
dpkg -l | grep openvpn > /var/log/openvpn-version.log

dpkg -l | grep openvpn > /var/log/openvpn-version.log records the installed versions. With these records and backups, rollback becomes a documented routine, not a panic action.

#Deployment Patterns

#Bare-Metal and VM

On bare-metal or VMs, OpenVPN is installed as a package and managed by systemd. This is the simplest and most documented pattern. It suits small VPN servers that don't change often.

#Docker and Kubernetes

For container-based deployments, the kylemanna/openvpn image from episode 0 offers a practical setup. In Kubernetes, OpenVPN is often run as a DaemonSet or Deployment with network configuration:

docker run -v /etc/openvpn:/etc/openvpn --cap-add=NET_ADMIN \
  -p 1194:1194/udp kylemanna/openvpn

docker run ... kylemanna/openvpn runs the server with a configuration volume and the NET_ADMIN capability needed to create the tun interface. Important note: container mode requires /dev/net/tun and the right privileges — exactly the warning from episode 0.

#Infrastructure as Code

For large scale, define the infrastructure as code. Terraform creates the base infrastructure, Ansible provisions and configures OpenVPN. This pattern produces environments that are reproducible and auditable:

- name: Configure OpenVPN
  hosts: vpn_servers
  become: true
  vars:
    vpn_port: 1194
    vpn_network: "10.8.0.0"
  roles:
    - openvpn-server

The playbook above makes the entire configuration — including the values from episode 12 — documented in the repository. When team members change, the knowledge doesn't leave with them.

#Conclusion

Key takeaways:

• PKI is rotated on schedule, not after expiry.
• ACME automates server certificate renewal.
• Backups cover PKI, configuration, CCD, and firewall.
• Backups must be tested with real restores.
• Upgrades are planned with version records and a rollback path.
• Deployments are managed via IaC to stay reproducible.

In episode 22 — the closing episode — we will reflect on the entire journey: comparing OpenVPN with WireGuard, IPsec, and mesh services like Tailscale, compiling a production-grade checklist from everything learned, and looking at OpenVPN's future with DCO and post-quantum cryptography.