Tunneling Through the Noise: Bulletproof OpenVPN Setup on CentOS 5
Let's be honest. Connecting to your production servers via unencrypted Wi-Fi at a conference or a hotel is professional suicide. I've watched packet sniffers pull plain-text passwords out of the air in crowded coffee shops more times than I care to count. If you are serious about administration, you need a secure tunnel. You need a VPN. And you need it hosted on hardware you control, not some black-box service that logs your traffic.
Today, we are deploying OpenVPN 2.1 on a CentOS 5 node. Why OpenVPN? Because IPsec is a nightmare to configure through NAT, and PPTP security is a joke that was cracked years ago. OpenVPN is the industry standard for SSL VPNs. It's robust, it handles dynamic IPs gracefully, and it works over UDP to keep your latency manageable.
The Hardware Reality: Why Latency Matters
Before we touch the config files, understand this: encryption costs CPU cycles. Encapsulation adds overhead. If you put your VPN gateway on an overloaded budget VPS in a datacenter across the Atlantic, you are going to feel it. SSH sessions will lag. typing... will... look... like... this.
For those of us operating in the Nordics, geography is physics. You want your endpoint close to NIX (Norwegian Internet Exchange) in Oslo. This is why we provision CoolVDS instances with dedicated CPU slices. When you are pushing AES encryption at line speed, you cannot afford 'noisy neighbors' stealing your CPU time. We use enterprise-grade RAID-10 SAS storage to ensure that logging and status updates don't create I/O bottlenecks that stall your connection.
Step 1: The Environment
We assume you have a fresh CoolVDS instance running CentOS 5.4 or 5.5. First, we need the EPEL repository because Red Hat, in their infinite wisdom, doesn't include OpenVPN in the base repos.
wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-3.noarch.rpm
rpm -ivh epel-release-5-3.noarch.rpm
yum update
yum install openvpn
Crucial Step for VPS Users: If you are on a standard OpenVZ container, you often hit a wall here because the TUN/TAP device isn't enabled by the host. This is a common support ticket generator. At CoolVDS, we enable the TUN/TAP module by default on all unmanaged VPS plans so you don't have to beg support for permission to run a VPN.
Step 2: CA and Key Generation
OpenVPN uses PKI (Public Key Infrastructure). Do not use a static key unless you want to rotate it manually every time an employee leaves. We'll 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
source ./vars
./clean-all
./build-ca
When asked for the 'Country Name', put NO. For 'Common Name', use your server's FQDN. This isn't just vanity; it helps when you are auditing logs later.
SysAdmin Tip: When generating the Diffie-Hellman parameters (./build-dh), go grab a coffee. On a slow virtual machine, this takes forever. On CoolVDS high-frequency cores, it's done before you get back, but it's still computationally heavy math.
Step 3: Server Configuration
Create /etc/openvpn/server.conf. We are going to use UDP because TCP-over-TCP leads to a meltdown called 'TCP Meltdown' where retransmissions stack up and kill your throughput.
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
Note the push "redirect-gateway def1". This forces all your client's web traffic through the tunnel. This is what protects you at the airport Wi-Fi. It also means your home IP address is masked, appearing as your CoolVDS server's IP in Oslo. This is vital for accessing geo-restricted services or complying with corporate access policies that whitelist only specific static IPs.
Step 4: Routing and IP Forwarding
The VPN allows you to talk to the server, but to talk through the server to the internet, we need iptables NAT.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
service iptables save
echo 1 > /proc/sys/net/ipv4/ip_forward
Edit /etc/sysctl.conf to make that forwarding permanent. If you forget this, your VPN connects, but you can't ping Google. I've seen senior admins lose hours debugging this simple toggle.
The Compliance Angle (Datatilsynet)
Hosting this in Norway isn't just about ping times. It's about data sovereignty. under the Personal Data Act (Personopplysningsloven), you have specific obligations regarding where your data transit occurs. By terminating your VPN on a server physically located in Oslo, under Norwegian jurisdiction, you avoid the legal gray areas of routing sensitive corporate traffic through US-owned servers where the Patriot Act might apply. CoolVDS infrastructure is owned and operated here, keeping you compliant with local regulations.
Final Thoughts
Once this is running, you have a private, encrypted tunnel into the heart of the Norwegian internet. No more worrying about open Wi-Fi sniffers. No more latency spikes from routing through Amsterdam just to get to a server in Bergen.
If you need a stable platform to host this gateway, don't settle for oversold hardware. Deploy a CoolVDS instance today. We offer the raw stability and I/O performance required for encryption-heavy workloads.