What is OpenVPN?

OpenVPN is a mature, open-source VPN that builds encrypted tunnels using TLS and a userspace daemon. It has powered remote access and site links for well over a decade, and it remains a common choice when you need flexible transport (UDP or TCP), broad client compatibility, or certificate-based identity that maps cleanly onto existing PKI practices.

If you run your own infrastructure, you have almost certainly seen OpenVPN configs, .ovpn profiles, or questions about whether to prefer it over WireGuard. The useful answer is not tribal loyalty. It is understanding what OpenVPN actually does on the wire, how its trust model works, and which operational costs you inherit when you deploy it on a VPS.

This guide explains OpenVPN from an operator’s perspective: architecture, certificates, TCP versus UDP, a minimal Ubuntu example, and the habits that keep tunnels maintainable.

What You'll Learn

• What problem OpenVPN solves and how its tunnel model works
• How TLS, certificates, and optional shared secrets fit together
• When to choose UDP versus TCP transport
• How to bring up a basic server and client on Ubuntu
• Best practices and common failure modes
• When OpenVPN is still the right tool versus newer protocols

What OpenVPN Actually Is

OpenVPN creates a virtual network interface (typically tun0 in routed mode, or tap0 in bridged mode) and moves IP packets through an encrypted channel to a remote peer. The encryption and authentication are driven by OpenSSL (or compatible TLS libraries). Control-channel setup looks a lot like a TLS session; once keys are established, data packets flow over UDP or TCP according to your configuration.

That userspace design has trade-offs. Packet processing goes through the OpenVPN process rather than a minimal in-kernel path. On modern CPUs that is often fine for remote-access loads. At very high throughput, kernel-oriented designs can win on efficiency. For many teams, flexibility and client ecosystem matter more than squeezing the last few percent of packets-per-second.

Routed (tun) versus bridged (tap)

Most production OpenVPN deployments use routed mode (dev tun). Each side gets an IP on a dedicated VPN subnet. The OS routes selected prefixes into tun0. This matches how most cloud networks and firewalls already think.

Bridged mode (dev tap) extends a layer-2 segment across sites. It can carry non-IP protocols and make remote hosts look like they are on the same Ethernet broadcast domain. It is also heavier, noisier, and easier to misconfigure. Prefer tun unless you have a concrete layer-2 requirement.

Client/server topology (and mesh variants)

OpenVPN commonly runs in a client/server topology: one server process with a public endpoint, many clients connecting inbound. The server assigns tunnel IPs, pushes routes and DNS, and optionally NATs client traffic to the internet or private networks.

There is also a peer-to-peer mode, but most operators standardize on client/server for remote access because certificate issuance, IP pools, and logging are simpler to reason about.

Trust Model: Certificates First

OpenVPN’s strongest deployments use a public key infrastructure:

1. A Certificate Authority (CA) you control signs certificates.
2. The server presents a server certificate; clients verify it against the CA.
3. Each client has its own certificate and private key; the server verifies those too.
4. Optionally, a TLS-auth or TLS-crypt shared key adds an extra HMAC/encryption layer on control packets (useful against unauthenticated probe noise).

Shared-secret-only configs (secret static key mode) still exist for lab point-to-point links. Do not use static keys as your primary remote-access identity model. Certificates give you per-user issuance and revocation; a single shared secret does not.

What “revocation” means in practice

When a laptop is lost or a contractor leaves, you need a path to invalidate their client certificate. OpenVPN can consume a Certificate Revocation List (CRL). Generate and distribute CRLs as part of offboarding, reload the server, and verify the client can no longer connect. If you never automate CRL updates, “we have certificates” is incomplete security theater.

UDP Versus TCP

OpenVPN can run over UDP (typical default) or TCP.

Prefer UDP when the path allows it. VPN tunnels carry inner TCP already. Putting TCP inside TCP (OpenVPN-over-TCP carrying HTTPS, SSH, etc.) can amplify latency under loss: both layers retransmit. UDP avoids that meltdown pattern.

Use TCP when middleboxes block UDP, or when you must look like ordinary HTTPS-ish traffic on port 443 to traverse hostile networks. Accept the performance cost consciously. Some teams run UDP on a dedicated port for normal users and offer a TCP fallback profile for restrictive hotels and airports.

Port choice is operational, not magical. 1194/udp is the historical default. 443/tcp is a traversal tactic. Document which profile is primary.

Why Teams Still Run OpenVPN

Broad client support. Official and third-party clients exist across desktop and mobile platforms. Many corporate IT playbooks already know .ovpn files.

Flexible transport. UDP and TCP in one stack matters when you do not control every network users travel through.

Mature TLS tooling. If your org already runs an internal CA, OpenVPN plugs into that mental model.

Feature depth. Fine-grained push options, scripting hooks, plugins, and long operational history help in complex environments—at the cost of configuration surface area.

OpenVPN is not “obsolete.” It is heavier than WireGuard for greenfield simple tunnels. Choose it when its flexibility or client constraints outweigh that weight.

A Minimal Working Example (Ubuntu 24.04)

The following sketch builds a routed UDP server with easy-rsa-style certificates. Treat paths and names as a learning scaffold; production should use configuration management and a real CA workflow.

1. Install packages

sudo apt update
sudo apt install -y openvpn easy-rsa

2. Create a CA and certificates

make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full server nopass
./easyrsa build-client-full alice nopass
./easyrsa gen-dh
openvpn --genkey secret ta.key

Copy server materials into /etc/openvpn/server/ with mode 0600 for private keys. Never commit private keys to git.

3. Server configuration

Example /etc/openvpn/server/server.conf:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-crypt ta.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
keepalive 10 120
user-session-timeout 86400
persist-key
persist-tun
user nobody
group nogroup
verb 3

Enable IP forwarding if clients should reach networks beyond the tunnel IP:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-openvpn.conf
sudo sysctl --system

Open the firewall and cloud security group for 1194/udp. Bring the service up:

sudo systemctl enable --now openvpn-server@server
sudo systemctl status openvpn-server@server

4. Client profile

A portable .ovpn embeds certificates or references files. Minimal structure:

client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verb 3
<ca>
... CA certificate ...
</ca>
<cert>
... client certificate ...
</cert>
<key>
... client private key ...
</key>
<tls-crypt>
... ta.key ...
</tls-crypt>

Import into a desktop/mobile client or run:

sudo openvpn --config alice.ovpn

Verify with ping to 10.8.0.1 and confirm pushed routes with ip route.

5. NAT for full-tunnel internet egress

If clients should exit through the VPS public IP, add masquerade on the public interface (example with nftables/iptables depending on your Ubuntu image). Without NAT and forwarding, full-tunnel “internet via VPN” will fail even when the tunnel itself is healthy.

Operational Concerns That Matter

Cipher and TLS settings age. Defaults improve over time; pin modern algorithms and drop legacy options. Review OpenVPN and OpenSSL guidance when you upgrade major versions.

Logging and privacy. Verbosity helps debugging. Decide retention deliberately if tunnel logs can reveal who connected when.

Multi-client IP pools. The server directive manages a pool. Plan DNS and firewall rules around those addresses so you can attribute access.

Config sprawl. OpenVPN’s power is also its failure mode: dozens of options copied from forum posts. Keep a minimal known-good baseline and change one knob at a time.

OpenVPN and Modern Alternatives

Many teams default to WireGuard for new self-hosted remote access and keep OpenVPN where TCP traversal or existing .ovpn fleets dominate. That split is rational, not contradictory.

Best Practices

1. Run your own CA (or a controlled internal CA). Issue per-device or per-user certificates. Do not share one client cert across the whole company.

2. Use tls-crypt (or tls-auth) in addition to certificates. It reduces unauthenticated control-channel noise on the public port.

3. Prefer UDP; document a TCP fallback only if needed. Measure both if users report hotel Wi-Fi failures.

4. Lock down the VPS independently. OpenVPN does not replace SSH hardening, unattended upgrades, or cloud firewall defaults-deny.

5. Automate certificate lifecycle. Issuance, renewal, CRL distribution, and offboarding should be scripts or a control plane—not a wiki page.

6. Separate management plane from VPN data plane. Admin SSH on a jump path; VPN users on tunnel IPs with least privilege to internal services.

7. Test revoke paths. Schedule a drill: revoke a test cert, reload, confirm denial.

8. Watch MTU and fragmentation. Tunneled traffic adds overhead. If odd TCP stalls appear, lower tun-mtu / MSS clamping thoughtfully rather than randomly toggling ciphers.

Common Mistakes

Copy-pasting decade-old cipher lines. Ancient cipher/auth directives can leave you on weak suites or break clients after upgrades. Start from current distribution examples.

Forgetting to open UDP on both host firewall and cloud firewall. DigitalOcean cloud firewalls and ufw are independent layers. Both must allow the listen port.

Using redirect-gateway without NAT. Clients lose internet access and blame “OpenVPN is broken.”

One shared client certificate. You cannot revoke a single person without revoking everyone.

Running as root without dropping privileges. Configure user/group after startup where supported so the process does not stay root forever.

Bridged mode “because it feels simpler.” It usually is not. Routed mode matches cloud networking.

Ignoring time sync. TLS certificate validation fails in confusing ways when clocks drift. Install chrony/systemd-timesyncd and verify.

Treating a successful TLS handshake as a finished job. Confirm routes, DNS push, forwarding, and application reachability separately.

FAQ

Is OpenVPN free?

The OpenVPN community edition is open source. You can run servers on your own VPS without a protocol license fee. Commercial OpenVPN Inc. products and support contracts are optional and separate.

Is OpenVPN secure?

It can be, when you use modern TLS settings, proper certificates, patched OpenSSL/OpenVPN packages, and sound operational practices. Misconfiguration—not the protocol brand—is the usual failure.

Should I use OpenVPN or WireGuard?

For greenfield self-hosted remote access with UDP available, WireGuard is often simpler and faster to operate. Choose OpenVPN when you need TCP transport, specific enterprise client constraints, or an existing certificate-centric workflow you are not ready to replace.

Does OpenVPN work on mobile?

Yes. Maintainable mobile deployments still need good keepalive/settings and a clear cert distribution story.

Can OpenVPN do site-to-site?

Yes. Two servers can connect as peers or you can route site prefixes through a hub. For many site-to-site designs, IPsec or WireGuard are also common; pick based on routing and operational familiarity.

What port should I use?

1194/udp is conventional. Any free port works if firewalls and clients match. Use 443/tcp only as a deliberate traversal strategy.

How do I revoke a user?

Revoke their certificate, publish an updated CRL to the server, reload OpenVPN, and verify. Also remove any static IP maps or firewall exceptions tied to that identity.

Does OpenVPN hide my identity from the VPS provider?

No. Your provider sees encrypted traffic to your server’s IP. OpenVPN encrypts the tunnel contents relative to on-path observers between client and server; it does not make the server operator invisible.

Why is my connection slow over TCP 443?

TCP-over-TCP, restrictive middleboxes, and longer paths all contribute. Prefer UDP when possible; profile CPU and bandwidth before rewriting cipher settings randomly.

Do I need easy-rsa?

No. easy-rsa is convenient. Any competent internal PKI that issues appropriate server/client certificates can work.

Summary

OpenVPN is a TLS-oriented VPN that exposes a virtual interface and carries routed (or bridged) traffic over UDP or TCP. Its strengths are flexibility, client ubiquity, and a certificate model familiar to operators who already run PKI. Its costs are configuration complexity and a heavier data path than minimal modern designs.

If you remember only a few points:

• Prefer routed tun mode and per-user certificates
• Default to UDP; use TCP only when the path demands it
• Automate issuance, revocation, and firewall rules
• Verify forwarding and NAT separately from the TLS handshake
• Pick OpenVPN for constraints it uniquely satisfies—not out of habit alone

From here, compare protocol choices against WireGuard and IKEv2 for your latency, client, and compliance constraints, then standardize one remote-access pattern per audience.

If you want to automate VPN server deployment instead of configuring everything manually, TunnelFleet helps you provision and manage VPN infrastructure on your own cloud provider with minimal manual setup.