Paranoid Networking: Hardening OpenVPN on Ubuntu 12.04 LTS

I was sitting in a café in Grünerløkka yesterday, watching the packet logs on my laptop. It’s terrifying. Between Firesheep script-kiddies and aggressive ISP throttling, the concept of a "trusted network" is dead. If you are pushing code or accessing production DBs over plain HTTP or even standard FTP, you are begging for a breach. PPTP is broken; don't even look at it. L2TP/IPsec is heavy and easily blocked by restrictive firewalls.

The only viable solution for the serious systems administrator in 2012 is OpenVPN. It’s SSL/TLS based, it traverses NAT like a ghost, and it’s stable.

However, a VPN is only as fast as the pipe it runs on. Encryption is math, and math costs CPU cycles. I’ve seen too many implementations fail because they were hosted on oversold OpenVZ containers where the host node was choking on I/O wait, causing packet loss on the tunnel. This guide assumes you are running on a clean, KVM-based architecture—like a CoolVDS instance—where you have access to the TUN/TAP modules and dedicated CPU time.

The Architecture of Trust

We are going to deploy an OpenVPN server on Ubuntu 12.04 LTS (Precise Pangolin). Why LTS? Because I don't want to wake up at 3 AM to patch a broken dependency tree on a bleeding-edge release. Stability is the primary feature.

Prerequisites

• A VPS running Ubuntu 12.04.
• Root access (or sudo privileges).
• Verified connectivity to NIX (Norwegian Internet Exchange) if you are targeting Nordic clients to minimize latency.

Step 1: Installation and PKI Setup

First, update your repositories and grab the binaries. We also need easy-rsa to manage our Public Key Infrastructure. Dealing with OpenSSL commands manually is a recipe for a migraine.

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

We need to create a directory for our certificate authority variables. Don't edit the files in /usr/share/ directly; that’s amateur hour.

make-cadir ~/openvpn-ca
cd ~/openvpn-ca

Now, edit the vars file. This saves you from typing your country and organization 50 times later. Since we are operating under Norwegian jurisdiction (Datatilsynet requirements matter here), set your parameters accurately.

nano vars

Change these lines to match your entity:

export KEY_COUNTRY="NO"
export KEY_PROVINCE="Oslo"
export KEY_CITY="Oslo"
export KEY_ORG="CoolVDS_Ops"
export KEY_EMAIL="admin@coolvds.com"

Pro Tip: Look for the export KEY_SIZE=1024 line. Change it to 2048. Paranoia is a virtue. 1024-bit RSA is getting long in the tooth, and with computing power doubling, we want future-proof encryption keys.

Step 2: Building the Certificate Authority

Load the variables and clean the environment. Be careful: clean-all wipes existing keys in that folder.

source vars
./clean-all
./build-ca

Hit enter through the prompts. Next, generate the server certificate and the Diffie-Hellman parameters. The DH generation will take time—this is where your VPS CPU matters. On a cheap shared host, this takes forever. On a proper KVM slice, it’s brisk.

./build-key-server server
./build-dh

Step 3: Server Configuration

OpenVPN ships with a great example config. Let's unpack it.

cd /usr/share/doc/openvpn/examples/sample-config-files
gunzip -c server.conf.gz | sudo tee /etc/openvpn/server.conf

Now we edit /etc/openvpn/server.conf. We need to point it to our new keys and harden the settings.

port 1194
proto udp
dev tun

ca /home/user/openvpn-ca/keys/ca.crt
cert /home/user/openvpn-ca/keys/server.crt
key /home/user/openvpn-ca/keys/server.key
dh /home/user/openvpn-ca/keys/dh2048.pem

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

# Push routes to the client to redirect all traffic
push "redirect-gateway def1 bypass-dhcp"

# Use Google DNS or your ISP DNS
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Step 4: Packet Forwarding and Routing

By default, Linux is a host, not a router. We need to tell the kernel to forward IPv4 packets.

sudo nano /etc/sysctl.conf

Uncomment this line:

net.ipv4.ip_forward=1

Reload with sudo sysctl -p.

Now, the firewall. We need iptables to NAT the traffic coming from the VPN subnet (10.8.0.0/24) out to the internet via your public interface (usually eth0). Without this, your packets hit the server and die there.

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

To make this persist after a reboot, I prefer the rc.local method for simplicity in 12.04, though using `iptables-save` is also valid.

Why Infrastructure Matters: The CoolVDS Reality

You might ask, "Why not run this on a $2/month container?"

Here is the reality of virtualization. OpenVPN relies heavily on context switching and encryption/decryption operations. On OpenVZ (common in budget hosting), the kernel is shared. If your neighbor gets DDoS'd or decides to compile a kernel, your VPN latency spikes. Your SSH session lags. It’s unusable for professional work.

We use KVM at CoolVDS. This provides full hardware virtualization. Your memory is yours. Your CPU cycles are reserved. Furthermore, enabling the tun/tap device—required for OpenVPN—is often a support ticket nightmare on shared kernel platforms. On CoolVDS, you load the module yourself. You control the stack.

Step 5: Client Generation

Back in your CA directory, build a key for your laptop.

./build-key client1

You need to transfer ca.crt, client1.crt, and client1.key to your client machine securely (use SCP, not email!). Create a local client.ovpn config:

client
dev tun
proto udp
remote [YOUR_COOLVDS_IP] 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 3

Legal Note for Norwegian Admins

Operating a VPN endpoint in Norway brings you under the jurisdiction of the Personopplysningsloven (Personal Data Act of 2000). While you are securing traffic, remember that logs can constitute personally identifiable information. If you are managing this for a client, ensure you have a Data Processing Agreement in place. One benefit of hosting locally in Oslo is data sovereignty—your encrypted tunnels aren't hopping through switches in jurisdictions with less favorable privacy laws before hitting the internet.

Final Thoughts

A VPN is your first line of defense. Don't compromise it by putting it on weak infrastructure. You need reliable I/O and guaranteed CPU to keep that encryption overhead from becoming a bottleneck.

Ready to lock down your access? Deploy a KVM instance on CoolVDS today. We offer pure SSD storage and unmetered bandwidth options perfect for high-traffic VPN gateways. Don't wait for a breach to take security seriously.