Don't Let Public WiFi Compromise Your Data
It’s 2009. You’re sitting at a coffee shop in Oslo, connecting to their open WLAN to push some code. You might as well be broadcasting your passwords over a loudspeaker. With packet sniffers becoming standard tools for script kiddies, using unencrypted protocols over public networks is professional suicide.
The solution isn't to stop working remotely; it's to control the pipe. You need a Virtual Private Network (VPN) endpoint that you control, sitting in a datacenter with laws you understand. This isn't just about paranoia; it's about compliance with Personopplysningsloven (The Personal Data Act). If you are handling customer data over an unsecured HSDPA or WiFi link, you are failing your due diligence.
In this guide, we are going to deploy OpenVPN 2.1 on a CentOS 5 server. We choose OpenVPN over IPsec/L2TP because of its flexibility with SSL/TLS security and its ability to punch through restrictive NAT firewalls using standard TCP/UDP ports.
Why Hardware Matters for Encryption
Encryption is math. Math requires CPU cycles. Most budget VPS providers in Europe are selling you OpenVZ containers packed like sardines. When ten users on the same node start downloading torrents, your VPN throughput hits the floor because the CPU creates a bottleneck known as 'steal time'.
At CoolVDS, we utilize Xen virtualization. This ensures dedicated RAM and rigid CPU scheduling. When you are encrypting traffic with AES-256 or Blowfish, you need that guaranteed processing power. Plus, our servers are physically located in Norway with direct peering to NIX (Norwegian Internet Exchange), ensuring your latency remains in the single digits.
Step 1: The Environment
We assume you have a fresh CoolVDS instance running CentOS 5.3 or 5.4 (32-bit or 64-bit). First, we need the EPEL repository, as OpenVPN isn't in the base CentOS repo.
su -
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
yum update -y
yum install openvpn -y
Step 2: PKI and Key Generation
Security relies on the Public Key Infrastructure (PKI). Do not skip this. We will use the easy-rsa scripts included in the documentation.
cp -R /usr/share/doc/openvpn-2.1/easy-rsa/2.0 /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
vi vars
Edit the vars file. Increase the key size to 2048 bits if you are paranoid (and you should be), though 1024 bits is still the standard default. Set your country to NO (Norway) and define your organization.
export KEY_SIZE=2048
export KEY_COUNTRY="NO"
export KEY_PROVINCE="Oslo"
Now, build the CA and server keys:
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
Step 3: Server Configuration
Create the /etc/openvpn/server.conf file. We will use UDP for speed, as TCP over TCP can lead to 'meltdown' packet re-transmission loops on unstable connections.
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
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
Pro Tip: The `push "redirect-gateway def1"` directive is the magic sauce. It forces all your client's web traffic to route through the tunnel, effectively masking your location and encrypting your browsing, not just your LAN access.
Step 4: IP Forwarding and NAT
Linux is designed to stop traffic routing by default. We must enable IP forwarding.
Edit /etc/sysctl.conf and set:
net.ipv4.ip_forward = 1
Apply it with sysctl -p.
Next, we need iptables to Masquerade the traffic leaving the VPN tunnel onto the internet. This acts like a router for your connected clients.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
service iptables save
service iptables restart
The Latency Factor
Why host this in Norway? If you are in Oslo or Bergen and your VPN endpoint is in Texas, your packets have to cross the Atlantic twice for every keystroke. Physics dictates a latency penalty of 100ms+. By hosting on CoolVDS in our Oslo facility, you keep your ping times minimal. Furthermore, keeping data within Norwegian borders satisfies the stricter interpretations of Datatilsynet regarding data export.
Comparison: CoolVDS vs. Generic Budget Host
| Feature | Generic OpenVZ Host | CoolVDS Xen Platform |
|---|---|---|
| Encryption Performance | Unstable (CPU Steal) | Consistent (Dedicated Cycles) |
| TUN/TAP Device | Often disabled by host | Enabled by default |
| Disk I/O | Slow SATA II | High-Speed 15k RPM SAS RAID-10 |
Conclusion
Setting up OpenVPN takes about 15 minutes, but the peace of mind is permanent. Don't risk your credentials or client data on an open network. Spin up a rock-solid Xen instance today.
Ready to secure your connection? Deploy a high-performance CoolVDS instance in Oslo now and get full root access in under 2 minutes.