The Sysadmin's Guide to Encrypted Tunnels in 2009
Let’s be honest: connecting to an unsecured wireless access point at a café in Grünerløkka or an airport lounge is professional suicide. Packet sniffers are getting smarter, and unencrypted protocols (like POP3 or standard HTTP) transmit your credentials in plain text. If you value your data, you need a tunnel.
While IPsec is a nightmare to configure and PPTP has been proven insecure for years, OpenVPN remains the gold standard for flexibility and security. It operates in user space, traverses NATs easily, and uses the OpenSSL library for encryption.
In this guide, we are going to build a production-ready OpenVPN gateway on Debian 5.0 (Lenny). We will focus on routing all client traffic through the tunnel, effectively masking your location and encrypting your data stream.
Why Host This in Norway?
Latency matters. If you are working from Oslo or interacting with Nordic clients, routing your encrypted traffic through a server in Texas adds 150ms of lag. That makes SSH sessions unbearable.
Furthermore, jurisdiction is critical. Hosting your VPN endpoint within the EEA (European Economic Area) ensures you are protected under the Norwegian Personal Data Act (Personopplysningsloven) and overseen by Datatilsynet. Unlike servers in the US subject to the Patriot Act, a Norwegian VPS offers a stronger legal baseline for privacy.
Pro Tip: For this setup, avoid oversold OpenVZ containers where kernel modules like tun/tap are often disabled by the host. You need a virtualization technology like Xen (which CoolVDS uses standard) to ensure you have full control over network devices and memory allocation.
Step 1: The Environment
We assume you have a fresh install of Debian Lenny (or CentOS 5.3). You need root access. First, ensure your repository lists are up to date and install the necessary packages.
apt-get update
apt-get install openvpn openssl
Copy the easy-rsa generation scripts to a safe location. We don't want these overwritten on package updates.
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
Step 2: Building the PKI (Public Key Infrastructure)
Security is only as strong as your keys. Edit the vars file to set your default parameters (Country, Province, City, Org). Do not leave these blank.
Then, initialize the PKI:
source ./vars
./clean-all
./build-ca
Now, generate the server certificate and key. This step is CPU intensive. On a shared host with "noisy neighbors," this can take minutes. On CoolVDS's dedicated Xeon cores, it takes seconds.
./build-key-server server
./build-dh
Finally, generate your client keys:
./build-key client1
Step 3: Server Configuration
Create /etc/openvpn/server.conf. We will use UDP for speed (TCP over TCP leads to meltdown) and the tun device for routing.
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222" # OpenDNS
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
Step 4: IP Forwarding and NAT
For the VPN to act as a gateway, the Linux kernel must forward packets. Edit /etc/sysctl.conf:
net.ipv4.ip_forward=1
Apply the change with sysctl -p.
Now, the critical part: iptables. We need to masquerade traffic coming from the VPN subnet so it looks like it's coming from the server's public IP. This bypasses the need for the target server to know about your VPN subnet.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Make sure to save these rules so they persist after a reboot. On Debian, use a script in /etc/network/if-pre-up.d/ or simply install iptables-persistent if available.
Step 5: Client Connection
On your Windows XP or Vista laptop, install the OpenVPN GUI. On Mac OS X, Tunnelblick is the client of choice. Transfer your ca.crt, client1.crt, and client1.key securely (SCP or USB stick, never email).
Your client config (client.ovpn) should look like this:
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
Performance Expectations
Encryption adds overhead. However, the bottleneck is usually disk I/O (logging) or CPU (encryption) rather than bandwidth. This is where hardware choice becomes vital.
| Feature | Budget VPS (OpenVZ) | CoolVDS (Xen) |
|---|---|---|
| Kernel Access | Shared (Often no TUN/TAP) | Dedicated (Full TUN/TAP support) |
| Disk I/O | Slow SATA II | High-Speed Enterprise RAID-10 |
| CPU Access | Throttled/Shared | Guaranteed Cycles |
Conclusion
By routing your traffic through a hardened Debian server in Oslo, you gain two things: security against local snooping and the privacy protections of Norwegian law. Don't rely on expensive proprietary hardware firewalls when a Linux box can do it better.
If you need a server that supports the tun device out of the box and provides the I/O throughput necessary for multiple concurrent VPN streams, CoolVDS is built for this. Deploy your instance today and stop broadcasting your data to the world.