Stop Trusting Public Wi-Fi: It’s Time to Build Your Own Gateway

If you have been paying attention to the security scene since late 2010, you know the game has changed. The release of Firesheep made session hijacking accessible to anyone with a Firefox plugin. That guy sipping a latte at the cafe in Grünerløkka isn't just checking emails; he could be cloning your session cookies. If you are accessing critical infrastructure or client data over an open network without a tunnel, you are negligent. Period.

Corporate VPN concentrators are often overloaded, and routing your traffic through a headquarters in London just to access a server in Oslo adds unacceptable latency. The solution? Roll your own OpenVPN endpoint on a local Norwegian VPS. You get the security of 2048-bit RSA and the low latency required for SSH sessions that don't lag.

I’ve seen too many sysadmins rely on PPTP because it's "easy." It’s also broken. MS-CHAPv2 is vulnerable. We are doing this the right way: OpenVPN on Ubuntu 10.04 LTS (Lucid Lynx).

The Hardware Reality: Encryption Costs CPU

Before we touch the config, let's talk metal. Encrypting traffic at line speed is CPU intensive. Most budget VPS providers oversell their CPU cycles on aging hardware. If you are pushing 10Mbps of AES-256 encrypted traffic on a congested node, your throughput will tank.

This is where architecture matters. CoolVDS runs on the latest Intel Xeon 5600 series (Westmere) architecture. Why does that matter to you? AES-NI instructions. These CPUs have hardware acceleration specifically for encryption. On a standard VPS, OpenVPN eats CPU for breakfast. On an AES-NI enabled CoolVDS instance, the overhead is negligible. Don't build a security gateway on a calculator.

Step 1: The Foundation

We assume you have a fresh CoolVDS instance running Ubuntu 10.04 LTS. First, update your repositories and grab the package. We aren't compiling from source today; the repo version (2.1.0) is stable enough for production.

root@coolvds:~# apt-get update
root@coolvds:~# apt-get install openvpn python-software-properties

Step 2: PKI and Key Generation

OpenVPN relies on a Public Key Infrastructure (PKI). Do not skip this or use weak keys. We will copy the `easy-rsa` generation scripts to a safe location.

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa

Edit the vars file. This saves you from typing your country and organization fifty times. Set KEY_SIZE=2048. Paranoia is a virtue in 2011. 1024-bit is technically "safe" for now, but compute power is cheap. Future-proof your keys.

export KEY_COUNTRY="NO"
export KEY_PROVINCE="Oslo"
export KEY_CITY="Oslo"
export KEY_ORG="CoolVDS_Ops"
export KEY_EMAIL="[email protected]"

Now, build the Certificate Authority (CA) and server keys:

source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh

Note: Generating Diffie-Hellman parameters (build-dh) on a 2048-bit key takes time. Go grab a coffee. If you were on a slow disk, this would take forever, but CoolVDS Enterprise RAID arrays chew through this entropy generation reasonably fast.

Step 3: Server Configuration

Create /etc/openvpn/server.conf. We are going to use UDP for speed (TCP-over-TCP causes meltdown when packets drop) and the tun device for routing.

port 1194
proto udp
dev tun
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/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 through the VPN
push "redirect-gateway def1 bypass-dhcp"

# Use Google Public DNS (released recently) or OpenDNS
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

keepalive 10 120
comp-lzo # Compression is vital for mobile networks (3G/HSDPA)
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Step 4: IP Forwarding & IPTables

Your server needs to act like a router. Enable packet forwarding in the kernel.

echo 1 > /proc/sys/net/ipv4/ip_forward

Now for the NAT. We need to masquerade traffic coming from the VPN subnet (10.8.0.0/24) so it looks like it's coming from your CoolVDS public IP. This effectively gives you a static Norwegian IP address wherever you are in the world—essential for accessing geo-locked services or passing IP whitelists on corporate firewalls.

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

Pro Tip: Don't lose these rules on reboot. Save them using iptables-save > /etc/iptables.rules and load them in your network interfaces config. A downed firewall is a breach waiting to happen.

Local Nuances: The Norwegian Context

Why host this in Norway? Aside from the obvious latency benefits for local work (ping times to NIX in Oslo from a CoolVDS slice are typically under 2ms), there is the legal aspect. The Personopplysningsloven (Personal Data Act) and the vigilant eye of Datatilsynet make Norway a safe harbor compared to other jurisdictions. By keeping your traffic endpoint within Norwegian borders, you maintain data sovereignty.

Furthermore, relying on "free" VPN services usually means you are the product. They log your data. By running your own instance on CoolVDS, you control the logs. Set verb 0 in your config if you want zero logging. You are the admin. You decide.

Performance Verification

Once your client connects, check your throughput. On a standard ADSL line, your upload will be the bottleneck, but on fiber or high-speed university networks (Uninett), you will notice the difference hardware acceleration makes. A CoolVDS instance handles the encryption overhead without introducing jitter, crucial if you are running VoIP or RDP sessions through the tunnel.

Security isn't a product; it's a process. But having the right infrastructure makes the process a hell of a lot smoother. Stop broadcasting your cookies to the world.

Ready to lock down your connection? Spin up a CoolVDS instance in Oslo. We offer pure KVM virtualization perfect for custom kernel modules and tunneling.