Defeating Firesheep: Deploying OpenVPN on CentOS 5 for Secure Remote Access

If the recent release of the Firesheep extension for Firefox has taught us anything, it is that the era of implicit trust on public networks is over. Until last month, session hijacking was a dark art reserved for packet-sniffing experts using command-line tools. Now, any script kiddie in a coffee shop in Oslo or a hotel lobby in Bergen can hijack your Facebook or corporate webmail session with a single click. It is a security nightmare.

As system administrators, we cannot rely on application-level SSL (HTTPS) alone, especially when half the web still defaults to HTTP. The only robust solution is tunneling your entire traffic stream through a trusted endpoint. This guide covers setting up OpenVPN 2.1 on a CentOS 5.5 VPS. We choose OpenVPN over IPsec/L2TP because of its resilience across NAT firewalls and its ability to run over UDP.

Note: This tutorial assumes you are running on a CoolVDS Linux VPS. Unlike budget providers that oversubscribe OpenVZ nodes and disable kernel modules, CoolVDS guarantees the tun/tap device is available—a mandatory requirement for VPN tunneling.

1. Prerequisites and Repository Setup

First, verify your environment. You need root access and the TUN/TAP device enabled. If you are using a standard kernel, this is usually loaded. If you are on a virtualized container, verify it with:

If you see File descriptor in bad state, you are good to go. If you get Permission denied or No such device, open a ticket with your host immediately. (CoolVDS users: this is enabled by default on all nodes).

CentOS 5 does not include OpenVPN in the base repository. We need the Extra Packages for Enterprise Linux (EPEL). Install the RPM for your architecture (i386 or x86_64):

rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum update
yum install openvpn

2. The Public Key Infrastructure (PKI)

Do not use shared secrets (pre-shared keys) for multiple users; it does not scale. We will build a proper Certificate Authority (CA) using the easy-rsa scripts provided with the documentation.

Copy the scripts to a working directory to avoid overwriting them during updates:

cp -R /usr/share/doc/openvpn-2.1.1/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 details fifty times. Set the key size to 2048 bits. 1024 bits is currently "acceptable" but with computing power doubling, we must think ahead to 2012 and beyond.

Now, initialize the PKI and build your master CA and server certificate:

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

Once the server key is built, generate the Diffie-Hellman parameters. This calculation requires significant entropy and CPU cycles. On a low-end VPS, this can take several minutes. On CoolVDS high-performance nodes, it usually completes rapidly due to higher clock speeds.

3. Server Configuration

Create the config file at /etc/openvpn/server.conf. We will use the UDP protocol for lower latency. TCP over TCP leads to "meltdown" when packet loss occurs, causing retransmission storms.

port 1194
proto udp
dev tun

# Certificates
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

# Network
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

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

Pro Tip: The line push "redirect-gateway def1" is critical. It forces the client to route all internet traffic through the tunnel, not just traffic destined for the internal VPN network. This is what protects you from the Firesheep sniffers.

4. Routing and IPTables Masquerading

Even with the VPN running, your server needs to know how to pass traffic from the virtual tun0 interface to the physical eth0 interface. First, enable IP forwarding in the kernel:

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

Now, the part where most setups fail: the firewall. We must use NAT (Network Address Translation) to masquerade the VPN traffic so it looks like it is coming from the server's public IP. Without this, the internet cannot route packets back to your laptop.

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

Start the OpenVPN service:

5. Client Configuration

You will need to generate a key for your client (laptop/mobile) using ./build-key client1 on the server, then securely transfer the ca.crt, client1.crt, and client1.key to your local machine.

Create a client.ovpn file:

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

Why Hosting Location Matters

When you tunnel all your traffic, your internet speed is limited by the upload speed of your VPN server and the latency between you and that server. If you are sitting in Oslo but tunneling through a budget server in Texas, your browsing will feel sluggish due to the transatlantic round-trip time (RTT).

Data residency is also becoming a concern under the Personal Data Act (Personopplysningsloven) and the scrutiny of Datatilsynet. Keeping your traffic endpoint within Norway or the EEA ensures better legal footing than routing through jurisdictions with questionable data retention laws.

CoolVDS offers premium peering at NIX (Norwegian Internet Exchange). For a developer in Scandinavia, the latency to our nodes is often under 10ms. This makes the SSH session through the VPN feel instantaneous rather than laggy. We also use high-RPM SAS RAID arrays, ensuring that logging and encryption overhead don't bottleneck the CPU during heavy transfer sessions.

Final Security Check

Once connected, visit a site like whatismyip.com. It should show the IP address of your CoolVDS server, not the coffee shop's ISP. If it does, you are secure. The Firesheep users can capture your packets, but they will see nothing but encrypted garbage.