Stop Trusting the Coffee Shop WiFi: Build Your Own Encrypted Tunnel

If you are still sending plain-text HTTP traffic or relying on PPTP VPNs in 2012, you might as well hand your root passwords to the guy sitting next to you at the airport terminal. With tools like Firesheep making session hijacking trivial for script kiddies, and the Data Retention Directive looming over European ISPs, the only network you can trust is the one you own.

I've seen too many developers assume their 3G connection or hotel Ethernet is secure. It isn't. The only way to guarantee integrity between your laptop and your infrastructure is a hardened, self-hosted VPN. While IPsec is robust, it's a nightmare to configure through NAT. That leaves us with the industry standard: OpenVPN.

This isn't a guide for hobbyists. We are deploying a production-grade OpenVPN endpoint on Ubuntu 12.04 LTS (Precise Pangolin). We will focus on AES-256 encryption, 2048-bit keys, and optimizing the network stack for low latency across the Norwegian backbone.

The Hardware: Why Virtualization Matters

Encryption is CPU expensive. If you try to run AES-256-CBC on a cheap, oversold OpenVZ container where the host CPU is being stolen by 500 other neighbors, your throughput will tank. You'll see latency spikes that make SSH typing feel like sending smoke signals.

For this setup, we rely on KVM virtualization. Unlike containers, KVM provides a dedicated kernel and reserved CPU cycles. At CoolVDS, we use pure KVM on high-IOPS SSD arrays. This ensures that when OpenVPN needs to encrypt a packet, the cycle is there immediately. No wait states. No jitter.

Step 1: The Foundation and PKI

First, update your repositories and install the necessary binaries. We are using the standard repositories for stability.

OpenVPN relies on a Public Key Infrastructure (PKI). We need a Certificate Authority (CA) to sign our keys. Copy the easy-rsa generation scripts to a safe location so updates don't overwrite your configuration.

Now, configure the variables. This saves you from typing your country code fifty times.

Edit the bottom of the file to match your organization. Since we are operating out of Norway to leverage strict privacy laws (Datatilsynet context), set the country appropriately:

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

Load the variables and build the CA. Warning: This is where you clean the environment. Do not run ./clean-all if you already have keys you want to keep.

Step 2: Generating Server and Client Certs

Now we generate the certificate for the server itself. When asked for a challenge password, leave it blank for an automated startup.

We also need Diffie-Hellman parameters. This takes time. On a standard spinning-disk VPS, this can take minutes. On CoolVDS SSD instances, the entropy generation is significantly faster due to higher I/O throughput aiding the random number generation pool.

Step 3: The Server Configuration

This is the critical part. Most tutorials give you a default config that works but isn't optimized. We are going to use UDP for speed (TCP over TCP results in meltdown due to retransmission timers) and enable compression.

Create /etc/openvpn/server.conf:

port 1194
proto udp
dev tun

# Point to the certs we just made
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

# Subnet for VPN clients
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

# Push routes to client so all traffic goes through VPN
push "redirect-gateway def1 bypass-dhcp"

# Use Google DNS or OpenDNS to avoid DNS leaks from local ISP
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

# Security hardening
keepalive 10 120
cipher AES-256-CBC   # 256-bit encryption
comp-lzo             # Compression
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Pro Tip: If you are connecting from a restrictive network (like a corporate firewall or a hotel blocking UDP), change proto udp to proto tcp and port 1194 to port 443. It mimics HTTPS traffic, making it much harder to block. However, you will suffer a performance penalty.

Step 4: IP Forwarding and Routing

By default, Linux drops packets not destined for itself. We need to turn our CoolVDS instance into a router.

To make this permanent across reboots, edit /etc/sysctl.conf and uncomment net.ipv4.ip_forward=1.

Next, we need iptables to NAT the traffic. Without this, your traffic hits the VPN but has no way to exit to the internet.

To ensure these rules survive a reboot on Ubuntu 12.04, we can use iptables-save or a simple rc.local script, but the cleanest way currently is using iptables-persistent if available, or just dumping it manually:

Add this line to /etc/network/interfaces under the eth0 block to restore it on boot:

Step 5: Client Deployment

Generate a key for your laptop:

You need to securely transfer ca.crt, client-laptop.crt, and client-laptop.key to your local machine. Do not email these. Use scp.

Why Hosting Location Matters

Latency is determined by physics. If you are in Oslo or Northern Europe, routing your VPN traffic through a US server adds 100ms+ of lag. By hosting this on a CoolVDS node in our Oslo datacenter, you connect directly to NIX (Norwegian Internet Exchange).

Furthermore, under the Norwegian Personal Data Act (Personopplysningsloven), you gain a layer of legal clarity regarding data sovereignty that you simply don't get with budget hosts located in indeterminate jurisdictions.

Start the service:

Check the logs to ensure the tunnel is up:

If you see Initialization Sequence Completed, you are dark. Your traffic is now encrypted, authenticated, and routing through a high-speed SSD VPS. Don't let a sloppy open WiFi network compromise your SSH keys. Deploy your tunnel today.