LFCE 90 🐧 OpenVPN — Concepts - KandZ

⏱️ Estimated read: 12 min | |

OpenVPN is a userspace VPN implementation that runs on Linux, Windows, macOS, and mobile platforms. Unlike WireGuard, which is a kernel module with a fixed cryptographic suite, OpenVPN is a userspace daemon that uses the OpenSSL library and the TLS protocol to authenticate peers and negotiate the keys that protect the tunnel . The previous chapter covered WireGuard, which is minimal and modern; this chapter covers OpenVPN, which is older, more configurable, and still widely deployed because of its flexibility and its support for certificate-based authentication, bridging, and a wide range of ciphers and platforms.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The core architectural concept is the separation of the control channel and the data channel. The control channel is a TLS session that the two peers establish first, and it is used to authenticate the peers with certificates and to negotiate the keys for the data channel. The data channel is the actual tunnel that carries the IP packets, and it is protected by the keys that the control channel negotiated . The two channels are multiplexed over a single UDP or TCP port, and the reliability layer is applied only to the control channel, not to the data channel . This separation is the reason OpenVPN can provide TLS-grade authentication without imposing the reliability overhead on the tunneled traffic.

Key point: OpenVPN has two authentication modes. The static key mode uses a pre-shared key that is shared between the peers before the tunnel starts, and it does not use TLS. The TLS mode uses certificates and the TLS protocol to authenticate the peers and to negotiate the data channel keys. The TLS mode is the recommended mode for production because it provides forward secrecy and certificate-based identity, and it is the mode that the rest of this chapter assumes.

Why OpenVPN requires understanding the control and data channels

The control-channel problem.

The control channel is a TLS session. In TLS mode, each peer presents a certificate to the other, and each peer verifies that the certificate was signed by the trusted CA . The TLS handshake authenticates the peers and derives the session keys. The control channel runs over a reliability layer that OpenVPN implements on top of UDP, because TLS is designed for a reliable transport and OpenVPN wants to use UDP for the data channel . The reliability layer retransmits the control packets and orders them, but it does not affect the data channel.

The data-channel problem.

The data channel is the tunnel that carries the IP packets. It uses the keys that the control channel negotiated, and it does not use a reliability layer. The packets are encrypted and authenticated with HMAC, and the sequence number is embedded in the HMAC-signed envelope . The data channel is stateless from OpenVPN’s perspective: it forwards the packets without retransmitting or reordering them, and the TCP protocol inside the tunnel provides its own reliability if the application needs it.

The multiplexing problem.

The control channel and the data channel share a single UDP or TCP port. OpenVPN distinguishes the packets by their opcode, which is the first byte of the packet. The control packets use one opcode, and the data packets use another . The multiplexing allows the tunnel to use a single port, which simplifies the firewall configuration, and it allows the control channel to be renegotiated without interrupting the data channel.

a. The TLS mode and the certificate authentication

The TLS mode is the recommended mode for production. Each peer has a certificate and a private key, and the CA certificate is used to verify the peer’s certificate. The server presents its certificate to the client, and the client presents its certificate to the server. The mutual authentication is the default in TLS mode, and the remote-cert-tls server option on the client enforces that the peer is a server, not another client.

# Server configuration: TLS mode
tls-server
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem

The tls-server directive tells OpenVPN to act as the TLS server. The ca is the CA certificate that is used to verify the client’s certificate. The cert and key are the server’s own certificate and private key. The dh is the Diffie-Hellman parameters file, which is used for the key exchange . In modern OpenVPN versions, the dh none option can be used with the elliptic curve ciphers, which eliminates the need for the DH parameters file.

# Client configuration: TLS mode
client
remote vpn.example.com 1194
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
remote-cert-tls server

The client directive is a macro that sets the client mode and the TLS client behavior. The remote is the server’s address and port. The ca, cert, and key are the client’s credentials. The remote-cert-tls server directive enforces that the server’s certificate has the server authentication extended key usage, which prevents a client from impersonating a server .

b. The tun and tap devices

OpenVPN uses a virtual network device to interact with the kernel’s networking stack. The tun device is a Layer 3 device that carries IP packets, and the tap device is a Layer 2 device that carries Ethernet frames. The choice determines what the tunnel can carry and how it integrates with the network.

# Layer 3 tunnel
dev tun

# Layer 2 tunnel
dev tap

The tun device is the common choice for a routed VPN. It carries only the IP packets that are destined for the VPN, and it has a lower overhead because it does not carry the Ethernet headers . The tap device is used when the tunnel needs to carry non-IP traffic, when the VPN clients need to be in the same broadcast domain as the LAN, or when the LAN’s DHCP server should provide addresses to the VPN clients . The tap device has a higher overhead because it carries the Ethernet frames, and it scales poorly for large numbers of clients .

The server directive in the server configuration automatically sets up the tun device and the IP address pool for the clients.

# Server mode with a /24 pool
server 10.8.0.0 255.255.255.0

The server 10.8.0.0 255.255.255.0 directive configures the server mode, the tun device, the TLS server, the IP address pool, and the routes that are pushed to the clients . The server’s tunnel address is 10.8.0.1, and the clients receive addresses from the pool.

c. The routing and the push options

OpenVPN does not automatically route the traffic through the tunnel. The server pushes the routes to the clients with the push directive, and the client applies them when it connects.

# Push a route to the client
push "route 192.168.1.0 255.255.255.0"

# Push the default route through the tunnel
push "redirect-gateway def1 bypass-dhcp"

# Push a DNS server
push "dhcp-option DNS 8.8.8.8"

The push "route 192.168.1.0 255.255.255.0" directive tells the client to add a route for the 192.168.1.0/24 network through the tunnel . The push "redirect-gateway def1 bypass-dhcp" directive is the full-tunnel configuration: it replaces the client’s default route with the tunnel, so all the traffic goes through the VPN . The push "dhcp-option DNS 8.8.8.8" directive tells the client to use the specified DNS server.

The server also needs the route directive for the networks that are behind it, and the client-to-client directive if the clients should be able to reach each other through the tunnel.

# Route a network behind the server
route 10.0.4.0 255.255.255.0

# Allow client-to-client traffic
client-to-client

The route 10.0.4.0 255.255.255.0 directive adds the route to the server’s routing table, so the server knows how to reach the network . The client-to-client directive tells OpenVPN to forward the client traffic to the other clients internally, rather than sending it out to the kernel’s routing stack and back.

Complete Example Session

# ============================================
# PART 1: GENERATE THE CERTIFICATES
# ============================================
# Use easy-rsa to create the CA, the server cert, and the client cert
# (The easy-rsa commands are omitted for brevity; see the next chapter)

# ============================================
# PART 2: CREATE THE SERVER CONFIGURATION
# ============================================
sudo tee /etc/openvpn/server.conf > /dev/null <<'EOF'
port 1194
proto udp
dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem

server 10.8.0.0 255.255.255.0

push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"

client-to-client

keepalive 10 120
persist-key
persist-tun

verb 3
EOF

# ============================================
# PART 3: ENABLE IP FORWARDING
# ============================================
sudo sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-openvpn.conf

# ============================================
# PART 4: START THE SERVER
# ============================================
sudo systemctl start openvpn@server
sudo systemctl status openvpn@server

# ============================================
# PART 5: CREATE THE CLIENT CONFIGURATION
# ============================================
sudo tee /etc/openvpn/client.conf > /dev/null <<'EOF'
client
remote vpn.example.com 1194
proto udp
dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
remote-cert-tls server

resolv-retry infinite
nobind
persist-key
persist-tun

verb 3
EOF

# ============================================
# PART 6: CONNECT THE CLIENT
# ============================================
sudo openvpn --config /etc/openvpn/client.conf

# ============================================
# PART 7: VERIFY THE TUNNEL
# ============================================
ip addr show tun0
ping -c 2 10.8.0.1

The seven parts demonstrate the complete OpenVPN setup: the certificates, the server configuration, the forwarding, the server start, the client configuration, the client connection, and the tunnel verification. The critical configuration is the server directive, which sets up the tunnel subnet and the client pool, and the push directives, which route the client traffic through the tunnel.

Quick Reference

Authentication Modes

Mode	Mechanism	Use Case
Static key	Pre-shared key	Simple point-to-point
TLS	Certificates + TLS	Production, multi-client

Device Types

Device	Layer	Use Case
`tun`	Layer 3	Routed VPN, lower overhead
`tap`	Layer 2	Bridging, non-IP traffic

Key Server Directives

Directive	Purpose
`tls-server`	Act as TLS server
`ca`	CA certificate
`cert` / `key`	Server certificate and key
`dh`	DH parameters
`server`	Tunnel subnet and client pool
`push`	Route/DNS to clients
`client-to-client`	Allow client-to-client traffic

Key Client Directives

Directive	Purpose
`client`	Client mode macro
`remote`	Server address and port
`remote-cert-tls server`	Enforce server certificate
`resolv-retry infinite`	Retry DNS resolution
`nobind`	Do not bind a local port

Best Practices

✅ Do This:

# Use TLS mode for production
tls-server
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key                                   # ✅

# Use tun for routed VPN
dev tun                                                       # ✅

# Use remote-cert-tls server on the client
remote-cert-tls server                                        # ✅

# Push the routes to the clients
push "route 192.168.1.0 255.255.255.0"                        # ✅

# Enable IP forwarding on the server
sysctl -w net.ipv4.ip_forward=1                               # ✅

❌ Don’t Do This:

# Use static key mode for multi-client production
# No forward secrecy, no per-client identity                   # ❌

# Use tap for a routed VPN
# Higher overhead, no benefit for IP-only traffic              # ❌

# Forget the remote-cert-tls server on the client
# A client could impersonate a server                          # ❌

# Forget to enable IP forwarding
# The tunnel is up but the traffic is not forwarded             # ❌

# Use the same certificate for multiple clients
# The client identity is not unique                             # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Client cannot connect	Certificate or CA mismatch	Verify the CA and the certs
Tunnel is up but no traffic	`ip_forward` disabled	`sysctl -w net.ipv4.ip_forward=1`
Client cannot reach LAN	No `push "route"`	Add the route push
Client cannot reach internet	No `redirect-gateway`	Add the push
Handshake fails	`remote-cert-tls` mismatch	Check the server certificate’s EKU

Real-World Examples

1. Server mode

server 10.8.0.0 255.255.255.0

2. Push a route

push "route 192.168.1.0 255.255.255.0"

3. Push the default gateway

push "redirect-gateway def1 bypass-dhcp"

4. Push DNS

push "dhcp-option DNS 8.8.8.8"

5. Client-to-client

client-to-client

6. Client configuration

client
remote vpn.example.com 1194
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
remote-cert-tls server

7. TUN device

dev tun

8. TAP device

dev tap

9. Keepalive

keepalive 10 120

10. Persist the tunnel

persist-key
persist-tun

Visual

The Control and Data Channels

┌──────────────────────────────────────────────────────────────┐
│  OPENVPN MULTIPLEXES TWO CHANNELS OVER ONE PORT              │
│                                                              │
│  Control channel (TLS):                                      │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Certificate authentication                             │  │
│  │ Key negotiation                                        │  │
│  │ Reliable transport (retransmits, ordering)             │  │
│  └────────────────────────────────────────────────────────┘  │
│                           │                                  │
│                           │ negotiates the keys              │
│                           ▼                                  │
│  Data channel (tunnel):                                      │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ IP packets encrypted with the negotiated keys          │  │
│  │ No reliability layer                                   │  │
│  │ Forwarded over UDP                                     │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  Both channels share the same UDP port (1194).               │
└──────────────────────────────────────────────────────────────┘

TUN vs TAP

┌──────────────────────────────────────────────────────────────┐
│  TUN IS LAYER 3; TAP IS LAYER 2                              │
│                                                              │
│  TUN:                                                        │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Carries IP packets                                     │  │
│  │ Lower overhead                                         │  │
│  │ Routed VPN                                             │  │
│  │ No broadcast traffic                                   │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  TAP:                                                        │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Carries Ethernet frames                                │  │
│  │ Higher overhead                                        │  │
│  │ Bridged VPN                                            │  │
│  │ Broadcast traffic is carried                           │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

The Certificate Chain

┌──────────────────────────────────────────────────────────────┐
│  THE CA SIGNS THE SERVER AND CLIENT CERTIFICATES             │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ CA certificate (ca.crt)                                │  │
│  └──────────────────────────┬─────────────────────────────┘  │
│                             │ signs                          │
│              ┌──────────────┴──────────────┐                 │
│              ▼                             ▼                 │
│  ┌──────────────────────┐      ┌──────────────────────┐      │
│  │ Server certificate   │      │ Client certificate   │      │
│  │ server.crt           │      │ client.crt           │      │
│  └──────────────────────┘      └──────────────────────┘      │
│                                                              │
│  The peers verify each other's certificate against the CA.   │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Type	Userspace VPN
Control channel	TLS, certificate-based
Data channel	Encrypted IP packets
Default port	1194
Default protocol	UDP
Authentication modes	Static key, TLS
Device types	`tun` (Layer 3), `tap` (Layer 2)
Server directive	`server <subnet> <mask>`
Client directive	`client` + `remote`
Route push	`push "route ..."`
Full tunnel	`push "redirect-gateway def1"`

Key takeaways:

OpenVPN separates the control channel and the data channel. The control channel is a TLS session that authenticates the peers and negotiates the keys. The data channel carries the encrypted IP packets without a reliability layer. The two channels are multiplexed over a single port .
The TLS mode uses certificates for authentication. Each peer has a certificate and a private key, and the CA certificate is used to verify the peer’s certificate. The remote-cert-tls server option on the client enforces that the peer is a server, which prevents a client from impersonating a server .
The tun device is Layer 3, and the tap device is Layer 2. The tun device carries IP packets with lower overhead and is the common choice for a routed VPN. The tap device carries Ethernet frames and is used for bridging and non-IP traffic .
The server directive sets up the tunnel and the client pool. The server 10.8.0.0 255.255.255.0 directive configures the server mode, the tun device, the TLS server, and the IP address pool. The server’s tunnel address is the first address in the pool.
The push directives route the client traffic. The push "route ..." directive adds a route to the client’s routing table, and the push "redirect-gateway def1" directive replaces the client’s default route with the tunnel. The push "dhcp-option DNS ..." directive sets the client’s DNS server .
The server needs IP forwarding. The sysctl -w net.ipv4.ip_forward=1 command enables the kernel’s forwarding, and the client-to-client directive allows the clients to reach each other through the tunnel.

Remember: OpenVPN is a userspace VPN that uses TLS for authentication and key negotiation. The control channel and the data channel are separate, and they are multiplexed over a single port. The TLS mode uses certificates, and the remote-cert-tls server option on the client enforces the server identity. The tun device is for routed VPNs, and the tap device is for bridged VPNs. The server directive sets up the tunnel, and the push directives route the client traffic. The result is a VPN that is more configurable than WireGuard, at the cost of more complexity and a userspace data path.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!