LFCE 91 🐧 OpenVPN — Server and Client Setup
OpenVPN setup is a sequence of dependent steps: the PKI must exist before the certificates can be generated, the certificates must exist before the server can start, and the server must be reachable before the client can connect. The previous chapter covered the control and data channels that make the protocol work; this chapter covers the configuration files that make it run. The server configuration defines the tunnel subnet, the certificate paths, and the routing rules, and the client configuration defines the remote endpoint and the credentials that authenticate it to the server.
The setup uses Easy-RSA to generate the certificate authority and the certificates, and it uses the server.conf and client.conf files to configure the two ends. The server configuration must include the tls-auth key for HMAC authentication, the dh parameters for the key exchange, and the push directives for the routing. The client configuration must include the remote directive with the server’s address, the ca, cert, and key files, and the remote-cert-tls server directive to verify the server’s identity.
Key point: The server’s server 10.8.0.0 255.255.255.0 directive is a helper that configures the tun device, the TLS server mode, the IP address pool, and the routes in a single line. The tls-auth ta.key 0 directive on the server and the tls-auth ta.key 1 directive on the client are the HMAC authentication that protects against the denial-of-service and the port scanning attacks. The remote-cert-tls server directive on the client is mandatory for the MITM protection, because it verifies that the peer’s certificate has the server authentication extended key usage.
Why the server and client setup require the PKI
The certificate-authority problem.
OpenVPN does not use the pre-shared keys by default. The TLS mode requires a certificate authority that signs the server and client certificates, and each peer verifies the other’s certificate against the CA . The Easy-RSA tool is the standard way to create the CA and the certificates, and the build-ca, gen-req, and sign-req commands are the sequence that produces the files. The CA private key must be protected, because its compromise invalidates the entire PKI.
The server-config problem.
The server.conf file contains the certificate paths, the dh parameters, and the tls-auth key. The dh parameters are used for the Diffie-Hellman key exchange, and they must be generated with the easyrsa gen-dh command. The tls-auth key is the HMAC secret that authenticates the control channel packets, and it must be generated with the openvpn --genkey secret ta.key command . The server config that omits the dh or the tls-auth fails to start, or it starts without the HMAC protection.
The client-config problem.
The client.conf file contains the remote directive with the server’s address and port, and the ca, cert, and key files that authenticate the client. The client directive is a helper that enables the pull and tls-client options . The remote-cert-tls server directive is the MITM protection that verifies the server’s certificate, and the resolv-retry infinite directive keeps the client trying to resolve the server’s hostname . The client config that omits the remote-cert-tls is vulnerable to the MITM attack.
a. The server configuration
The server configuration defines the tunnel, the certificates, and the routing. The server directive is the helper that configures the tun device and the IP pool.
# /etc/openvpn/server.conf
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
tls-auth /etc/openvpn/ta.key 0
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
cipher AES-256-GCM
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3The server 10.8.0.0 255.255.255.0 directive configures the server to use the 10.8.0.0/24 subnet, with the server at 10.8.0.1 and the clients receiving the addresses from 10.8.0.2 to 10.8.0.254 . The ifconfig-pool-persist directive saves the client IP assignments to a file, so the same client receives the same address after a restart . The push "redirect-gateway def1 bypass-dhcp" directive makes the VPN the default gateway for the clients, and the push "dhcp-option DNS" directives set the DNS servers.
The user nobody and group nogroup directives downgrade the privileges after the initialization, and the persist-key and persist-tun directives preserve the keys and the tunnel across the restart . The status directive writes the connection status to a file, and the verb 3 directive sets the log verbosity.
b. The client configuration
The client configuration defines the remote server and the credentials. The client directive is the helper that enables the pull and the TLS client mode.
# /etc/openvpn/client.conf
client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 1
cipher AES-256-GCM
auth SHA256
verb 3The client directive is the macro that enables the pull and the tls-client options . The remote vpn.example.com 1194 directive specifies the server’s address and port, and the resolv-retry infinite directive keeps the client trying to resolve the hostname . The nobind directive tells the client not to bind a local port, which is the correct behavior for the client that connects from the dynamic address.
The remote-cert-tls server directive verifies that the server’s certificate has the server authentication extended key usage, which is the MITM protection . The tls-auth /etc/openvpn/ta.key 1 directive uses the same HMAC key as the server, with the direction 1 for the client and 0 for the server . The cipher AES-256-GCM and auth SHA256 directives must match the server’s configuration, or the connection fails.
c. The routing and the forwarding
The server must enable the IP forwarding and the NAT rule for the clients to reach the internet or the network behind the server.
# Enable IP forwarding
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-openvpn.conf
sudo sysctl -p /etc/sysctl.d/99-openvpn.conf
# Add the NAT rule for the VPN subnet
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
# Allow the VPN traffic in the firewall
sudo iptables -A INPUT -i tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPTThe net.ipv4.ip_forward=1 enables the kernel’s forwarding, and the MASQUERADE rule rewrites the source address of the VPN traffic to the server’s public address . The FORWARD rules allow the traffic from the tun0 interface to the eth0 interface and the return traffic, and the INPUT rule allows the traffic to the server itself.
The client-to-client directive in the server configuration allows the clients to reach each other through the VPN, and the iroute directive in the client-config-dir is the mechanism for the site-to-site routing . The push "route 192.168.1.0 255.255.255.0" directive in the server configuration adds the route to the clients’ routing tables, and the route 192.168.1.0 255.255.255.0 directive adds the route to the server’s routing table.
Complete Example Session
# ============================================
# PART 1: INSTALL THE PACKAGES
# ============================================
sudo apt update
sudo apt install -y openvpn easy-rsa
# ============================================
# PART 2: INITIALIZE THE PKI
# ============================================
mkdir -p ~/openvpn-ca
cp -r /usr/share/easy-rsa/* ~/openvpn-ca/
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca
# ============================================
# PART 3: GENERATE THE SERVER CERTIFICATE
# ============================================
./easyrsa gen-req server nopass
./easyrsa sign-req server server
# ============================================
# PART 4: GENERATE THE DH AND TLS-AUTH
# ============================================
./easyrsa gen-dh
openvpn --genkey secret ta.key
# ============================================
# PART 5: COPY THE FILES TO /etc/openvpn
# ============================================
sudo cp pki/ca.crt pki/issued/server.crt pki/private/server.key pki/dh.pem ta.key /etc/openvpn/
# ============================================
# PART 6: 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
tls-auth /etc/openvpn/ta.key 0
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
cipher AES-256-GCM
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
EOF
# ============================================
# PART 7: ENABLE FORWARDING AND NAT
# ============================================
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-openvpn.conf
sudo sysctl -p /etc/sysctl.d/99-openvpn.conf
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
# ============================================
# PART 8: START THE SERVER
# ============================================
sudo systemctl start openvpn@server
sudo systemctl enable openvpn@server
sudo systemctl status openvpn@server
# ============================================
# PART 9: GENERATE THE CLIENT CERTIFICATE
# ============================================
./easyrsa gen-req client1 nopass
./easyrsa sign-req client client1
# ============================================
# PART 10: CREATE THE CLIENT CONFIGURATION
# ============================================
sudo tee /etc/openvpn/client.conf > /dev/null <<'EOF'
client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 1
cipher AES-256-GCM
auth SHA256
verb 3
EOF
# ============================================
# PART 11: TEST THE CONNECTION
# ============================================
sudo openvpn --config /etc/openvpn/client.conf
# In another terminal:
ip addr show tun0
ping -c 2 10.8.0.1The eleven parts demonstrate the complete OpenVPN setup: the package installation, the PKI initialization, the server certificate, the DH and TLS-auth, the file copy, the server configuration, the forwarding and NAT, the server start, the client certificate, the client configuration, and the connection test. The critical steps are Parts 3 and 9: the server and client certificates are signed by the CA, and the remote-cert-tls server directive on the client verifies the server’s identity.
Quick Reference
Easy-RSA Commands
| Command | Purpose |
|---|---|
./easyrsa init-pki | Initialize the PKI |
./easyrsa build-ca | Create the CA |
./easyrsa gen-req <name> nopass | Generate a key and request |
./easyrsa sign-req server <name> | Sign the server certificate |
./easyrsa sign-req client <name> | Sign the client certificate |
./easyrsa gen-dh | Generate the DH parameters |
openvpn --genkey secret ta.key | Generate the TLS-auth key |
Server Configuration
| Directive | Purpose |
|---|---|
server 10.8.0.0 255.255.255.0 | Tunnel subnet and IP pool |
tls-auth ta.key 0 | HMAC authentication (server direction) |
push "redirect-gateway def1" | Full tunnel for the clients |
push "route ..." | Route to the network behind the server |
client-to-client | Allow the clients to reach each other |
ifconfig-pool-persist | Persist the client IP assignments |
Client Configuration
| Directive | Purpose |
|---|---|
client | Client mode helper |
remote <host> 1194 | Server address and port |
remote-cert-tls server | Verify the server certificate |
tls-auth ta.key 1 | HMAC authentication (client direction) |
resolv-retry infinite | Keep trying to resolve the hostname |
nobind | Do not bind a local port |
Forwarding and NAT
| Command | Purpose |
|---|---|
sysctl -w net.ipv4.ip_forward=1 | Enable forwarding |
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE | NAT the VPN traffic |
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT | Allow the forward traffic |
Best Practices
✅ Do This:
# Use the tls-auth key
tls-auth /etc/openvpn/ta.key 0 # ✅
# Verify the server certificate on the client
remote-cert-tls server # ✅
# Enable IP forwarding on the server
sysctl -w net.ipv4.ip_forward=1 # ✅
# Add the NAT rule for the VPN subnet
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE # ✅
# Use the server directive helper
server 10.8.0.0 255.255.255.0 # ✅
# Persist the client IP assignments
ifconfig-pool-persist /var/log/openvpn/ipp.txt # ✅❌ Don’t Do This:
# Omit the tls-auth key
# The server is vulnerable to the DoS and port scanning # ❌
# Omit the remote-cert-tls on the client
# The client is vulnerable to the MITM attack # ❌
# Forget the IP forwarding
# The tunnel is up but the traffic is not forwarded # ❌
# Forget the NAT rule
# The clients cannot reach the internet # ❌
# 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 the internet | No NAT rule | Add the MASQUERADE rule |
| Client cannot reach the LAN | No push "route" | Add the route push |
| TLS handshake fails | tls-auth direction mismatch | 0 on the server, 1 on the client |
| MITM warning | No remote-cert-tls server | Add the directive on the client |
Real-World Examples
1. Initialize the PKI
./easyrsa init-pki && ./easyrsa build-ca2. Generate the server certificate
./easyrsa gen-req server nopass && ./easyrsa sign-req server server3. Generate the DH and TLS-auth
./easyrsa gen-dh && openvpn --genkey secret ta.key4. Server configuration
server 10.8.0.0 255.255.255.0
tls-auth /etc/openvpn/ta.key 0
push "redirect-gateway def1 bypass-dhcp"5. Client configuration
client
remote vpn.example.com 1194
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 16. Enable forwarding
sysctl -w net.ipv4.ip_forward=17. NAT rule
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE8. Start the server
systemctl start openvpn@server9. Test the tunnel
ping -c 2 10.8.0.110. Check the status
systemctl status openvpn@serverVisual
The OpenVPN Setup Flow
┌──────────────────────────────────────────────────────────────┐
│ PKI → CERTIFICATES → SERVER CONFIG → CLIENT CONFIG │
│ │
│ 1. Easy-RSA init-pki │
│ 2. build-ca │
│ 3. gen-req server + sign-req server │
│ 4. gen-dh + genkey ta.key │
│ 5. server.conf + client.conf │
│ 6. Enable forwarding + NAT │
│ 7. Start the server + connect the client │
│ │
│ Each step depends on the previous one. │
└──────────────────────────────────────────────────────────────┘The Server and Client Files
┌──────────────────────────────────────────────────────────────┐
│ THE SERVER AND THE CLIENT SHARE THE CA AND THE TLS-AUTH │
│ │
│ Server Client │
│ ├── ca.crt ├── ca.crt (same) │
│ ├── server.crt ├── client1.crt │
│ ├── server.key ├── client1.key │
│ ├── dh.pem ├── ta.key (same) │
│ ├── ta.key └── client.conf │
│ └── server.conf │
│ │
│ The CA verifies both certificates. │
│ The ta.key authenticates the control channel. │
└──────────────────────────────────────────────────────────────┘The tls-auth Direction
┌──────────────────────────────────────────────────────────────┐
│ THE DIRECTION NUMBER IS THE HMAC KEY DIRECTION │
│ │
│ Server: tls-auth ta.key 0 │
│ └── uses the first half of the key for the outgoing HMAC │
│ └── uses the second half for the incoming HMAC │
│ │
│ Client: tls-auth ta.key 1 │
│ └── uses the second half for the outgoing HMAC │
│ └── uses the first half for the incoming HMAC │
│ │
│ The two directions must be opposite, or the HMAC fails. │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| PKI tool | Easy-RSA |
| CA creation | ./easyrsa build-ca |
| Server cert | gen-req server nopass + sign-req server server |
| Client cert | gen-req client1 nopass + sign-req client client1 |
| DH parameters | ./easyrsa gen-dh |
| TLS-auth key | openvpn --genkey secret ta.key |
| Server config | /etc/openvpn/server.conf |
| Client config | /etc/openvpn/client.conf |
| Server helper | server 10.8.0.0 255.255.255.0 |
| TLS-auth direction | 0 on the server, 1 on the client |
| MITM protection | remote-cert-tls server on the client |
| Forwarding | net.ipv4.ip_forward=1 |
| NAT | MASQUERADE on the VPN subnet |
| Service | openvpn@server |
Key takeaways:
- The PKI must exist before the server can start. The Easy-RSA commands create the CA, the server certificate, the client certificate, the DH parameters, and the TLS-auth key. The CA signs both the server and client certificates, and the
remote-cert-tls serverdirective on the client verifies the server’s identity . - The
serverdirective is the helper that configures the tunnel. Theserver 10.8.0.0 255.255.255.0directive sets thetundevice, the TLS server mode, the IP pool, and the routes. Thepushdirectives add the routes and the DNS servers to the clients . - The
tls-authdirection must be opposite on the server and the client. The server uses0, and the client uses1. The direction mismatch is the common cause of the TLS handshake failure . - The
remote-cert-tls serverdirective is mandatory on the client. It verifies that the server’s certificate has the server authentication extended key usage, which protects against the MITM attack . - The server must enable the IP forwarding and the NAT rule. The
net.ipv4.ip_forward=1enables the kernel’s forwarding, and theMASQUERADErule rewrites the source address of the VPN traffic to the server’s public address . - The client configuration must match the server’s
cipherandauth. Thecipher AES-256-GCMandauth SHA256on both sides are the cryptographic settings that the peers negotiate. A mismatch causes the connection to fail.
Remember: The OpenVPN setup is a chain of dependencies. The PKI creates the certificates, the certificates configure the server and the client, and the forwarding and NAT rules let the traffic flow. The server directive configures the tunnel, the push directives route the clients, and the tls-auth key protects the control channel. The remote-cert-tls server on the client is the MITM protection. The result is a VPN that authenticates both peers with certificates, encrypts the data with AES-GCM, and routes the traffic through the tunnel.
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!