Stop Trusting the Coffee Shop: A Guide to OpenVPN on CentOS 5
Let’s be honest: connecting to your corporate backend or checking your email over unencrypted hotel Wi-Fi is asking for trouble. With packet sniffers becoming easier to use, your plain-text FTP credentials and session cookies are floating in the air for anyone to grab. If you value your data—or your job—you need an encrypted tunnel.
I recently spent a weekend troubleshooting a client's "secure" setup on a budget VPS. They were trying to run OpenVPN on a restricted OpenVZ container where the host node had disabled the TUN/TAP driver. It was a nightmare. The lesson? You need a virtual server that acts like real hardware.
This guide walks you through setting up OpenVPN 2.1 on CentOS 5.5. We aren't using scripts. We are doing this manually so you understand exactly what iptables is doing to your packets.
The Prerequisites
Before we touch the config files, you need the right environment. OpenVPN requires the tun kernel module to create a virtual network interface. Many budget providers oversell their nodes and disable this to save kernel resources.
Pro Tip: Check your VPS immediately. Runcat /dev/net/tun. If you getFile descriptor in bad state, you are good. If you getPermission deniedorNo such device, open a ticket or switch providers. At CoolVDS, we enable TUN/TAP by default on all our Xen instances because we know sysadmins need it.
Step 1: Installing the Software
CentOS 5 doesn't have OpenVPN in the default repositories. We need EPEL (Extra Packages for Enterprise Linux).
wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
rpm -ivh epel-release-5-4.noarch.rpm
yum update
yum install openvpn
We also need openssl installed to generate our certificates. Don't skip the updates; security vulnerabilities in older SSL libraries are not something you want on a public-facing gateway.
Step 2: The PKI Infrastructure (Easy-RSA)
Encryption relies on trust. We need to become our own Certificate Authority (CA). Copy the easy-rsa scripts to your configuration directory to keep them safe from updates.
mkdir -p /etc/openvpn/easy-rsa/2.0
cp -r /usr/share/openvpn/easy-rsa/2.0/* /etc/openvpn/easy-rsa/2.0/
cd /etc/openvpn/easy-rsa/2.0
Edit the vars file. This saves you from typing your country and organization fifty times. Since we are focusing on Norwegian data sovereignty, set it accordingly:
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 certificates. This includes the CA, the server certificate, and the client keys. While 1024-bit keys are still common, I recommend bumping the key size to 2048-bit in the vars file if your CPU can handle the overhead. Security is moving that way.
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-key client1
./build-dh
Generating Diffie-Hellman parameters (build-dh) will take time. On a standard shared host, this entropy generation can stall. On our high-performance CoolVDS clusters, the dedicated CPU cycles make this significantly faster.
Step 3: Server Configuration
Create /etc/openvpn/server.conf. We will use UDP for speed (TCP over TCP leads to "meltdown" latency issues) and the tun interface.
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.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
The line push "redirect-gateway def1" is the magic. It forces the client to route all internet traffic through your secure server. Whether you are in a café in London or a train station in Berlin, your traffic looks like it's coming from your secure server in Oslo.
Step 4: IP Forwarding and IPTables
OpenVPN handles the encryption, but the Linux kernel handles the routing. You must enable IP forwarding.
Edit /etc/sysctl.conf:
net.ipv4.ip_forward = 1
Apply it with sysctl -p. Now, we configure the firewall. This is where many people fail. We need to NAT the traffic coming from the VPN subnet (10.8.0.0/24) out to the internet via the main interface (usually eth0).
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
service iptables save
service iptables restart
Performance and Hardware Considerations
Encryption is CPU intensive. If you are pushing heavy traffic (like transferring large ISOs or backups), a weak CPU will bottleneck your network speed. We often see "CPU Steal" on budget VPS providers, where your neighbor's usage slows down your encryption/decryption process.
At CoolVDS, we prioritize CPU scheduling and use enterprise RAID-10 SAS storage. While OpenVPN doesn't hit the disk hard, the logging and system responsiveness depend on low I/O wait times. You don't want your SSH session lagging while someone else compiles a kernel on the same node.
The Norwegian Legal Advantage
Hosting your VPN endpoint in Norway isn't just about latency—though ping times to NIX (Norwegian Internet Exchange) are superb. It's about the Personopplysningsloven (Personal Data Act). Having your data transit through a jurisdiction with strong privacy traditions offers peace of mind compared to hosting in less regulated territories. The Datatilsynet (Data Inspectorate) is known for being strict, which benefits those who value privacy.
Final Testing
Start the service:
service openvpn start
Copy ca.crt, client1.crt, and client1.key to your client machine. On Windows, drop them into the config folder of the OpenVPN GUI. Connect, and check your IP address on a site like whatismyip.com. It should match your VPS IP, not your local ISP.
If it works, you have a private, encrypted tunnel. If not, check /var/log/messages. 90% of the time, it's a firewall rule or a missing TUN/TAP driver.
Don't let a budget host compromise your security architecture. Deploy your VPN on a platform built for stability.
Ready to secure your traffic? Deploy a CoolVDS Xen instance in Oslo today and take control of your routing.