Secure Your Data: Building a Bulletproof OpenVPN Gateway on Ubuntu 12.04
Let’s be honest: trusting the Wi-Fi at your local coffee shop in 2012 is digital suicide. Tools like Firesheep proved two years ago just how easy it is to hijack sessions. If you are administering servers or accessing sensitive corporate data over an unencrypted connection, you aren't just taking a risk. You are being negligent.
SSH tunnels are a quick fix, but they don't scale for mobile devices or non-TCP traffic. You need a proper VPN. While PPTP is widespread, it’s fundamentally broken security-wise (MS-CHAPv2 is dead). IPsec is a nightmare to configure behind NAT. That leaves us with the heavy hitter: OpenVPN.
In this guide, we aren't just installing packages. We are building a hardened OpenVPN gateway on Ubuntu 12.04 LTS (Precise Pangolin). We will use 2048-bit RSA keys (because 1024-bit is getting too close to the cracking threshold) and configure proper IP forwarding.
The Infrastructure Prerequisite
Latency kills VPNs. If your handshake takes 400ms, your SSH sessions inside the tunnel will lag. It’s unbearable. You need a host with clean peering.
Pro Tip: Location matters. If you are in Oslo or Northern Europe, routing traffic through a US server adds 100ms+ of unnecessary latency. For this tutorial, I'm spinning up an instance on CoolVDS because they peer directly at NIX (Norwegian Internet Exchange). Their I/O performance on the new SSD arrays is also fast enough that logging verbosity doesn't create a bottleneck.
Step 1: Installation and PKI Setup
First, update your repositories and install the binaries. We need openvpn and easy-rsa to manage our Public Key Infrastructure (PKI).
apt-get update
apt-get install openvpn easy-rsa
Don't configure the CA in the default directory. It will get wiped on package updates. Copy the easy-rsa generation scripts to /etc/openvpn.
mkdir -p /etc/openvpn/easy-rsa
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/
Now, edit the vars file. This saves you from typing your country and organization fifty times. Open /etc/openvpn/easy-rsa/vars in vim:
export KEY_COUNTRY="NO"
export KEY_PROVINCE="Oslo"
export KEY_CITY="Oslo"
export KEY_ORG="CoolVDS_Ops"
export KEY_EMAIL="admin@example.com"
Crucial Security Step: Look for the KEY_SIZE parameter. Default is often 1024. Change it.
export KEY_SIZE=2048
Source the variables and build your Certificate Authority (CA) and server keys. This is the root of trust.
cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
The Diffie-Hellman parameter generation (build-dh) will take time. On a standard HDD VPS, this takes forever. On CoolVDS high-performance storage, it flies. Go grab a coffee anyway.
Step 2: Server Configuration
We need a robust server.conf. We are going to use UDP for speed (TCP over TCP leads to meltdown) and a specific subnet.
Create /etc/openvpn/server.conf:
port 1194
proto udp
dev tun
ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/server.crt
key easy-rsa/keys/server.key
dh easy-rsa/keys/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist 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
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
Configuration Breakdown
| Directive | Why we use it |
|---|---|
proto udp |
Lower latency. TCP retries on the VPN layer conflict with TCP retries inside the tunnel. |
push "redirect-gateway..." |
Forces all client web traffic through the VPN. Essential for securing public Wi-Fi usage. |
user nobody |
Drops privileges after initialization. If OpenVPN has a buffer overflow exploit, the attacker doesn't get root. |
Step 3: IP Forwarding and iptables (The Tricky Part)
By default, Linux drops packets not destined for itself. We need to tell the kernel to forward traffic from the VPN subnet to the internet.
Edit /etc/sysctl.conf and uncomment:
net.ipv4.ip_forward=1
Reload it: sysctl -p.
Now, the firewall. We need NAT (Network Address Translation) so your VPN traffic looks like it's coming from the VPS IP. I use iptables directly. Forget ufw for a second; you need to understand what is happening.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
To make this persistent on reboot, I usually dump the rules to a file and restore them in /etc/rc.local, or use iptables-persistent.
Step 4: Client Keys
Generate a key for your laptop/phone:
cd /etc/openvpn/easy-rsa
source ./vars
./build-key client1
You need to securely transfer ca.crt, client1.crt, and client1.key to your client device. Do not email these. Use scp.
Why Infrastructure Choice Affects Security
We often focus on encryption ciphers and forget physical sovereignty. If you host your VPN in a jurisdiction with loose data laws, your 2048-bit keys don't matter when the host is subpoenaed.
This is why I prefer hosting in Norway. Under the Personopplysningsloven (Personal Data Act), privacy is treated seriously. CoolVDS operates under these strict Norwegian guidelines. Furthermore, they don't oversell their virtualization. When you run encryption/decryption at line speed, you burn CPU cycles. Shared hosts that steal CPU time will cause your VPN to jitter. CoolVDS uses KVM, so your CPU time is yours.
Final Test
Start the service:
service openvpn start
Check the logs at /var/log/syslog. If you see Initialization Sequence Completed, you are live. Connect your client, and check your IP address on a site like whatismyip.com. It should show your CoolVDS server IP, not your coffee shop IP.
Security isn't a product; it's a process. But having a dedicated, low-latency entry point into the internet is a massive part of that process. Don't rely on "free" VPN services that likely sell your data.
Need a rock-solid foundation for your privacy? Deploy a VPS Norway instance on CoolVDS today. With our new NVMe storage tiers and NIX peering, your encrypted tunnel will feel like a local connection.