Secure Tunneling: Deploying OpenVPN on CentOS 5 for the Paranoiode Sysadmin

I was analyzing traffic dumps from a public access point in downtown Oslo yesterday. What I saw scared me. Cleartext passwords, unencrypted POP3 request, and cookie hijacking are rampant. If you are a developer or sysadmin managing critical infrastructure remotely, relying on an open connection is professional suicide.

The solution isn't just "use a proxy." It's building a dedicated, encrypted tunnel using OpenVPN. Unlike IPsec, which can be a nightmare to debug through NAT, OpenVPN operates over SSL/TLS, making it robust and firewall-friendly.

Today, we are deploying a production-ready OpenVPN server on CentOS 5.3. We will focus on routing all traffic through the tunnel to secure your connection against local sniffers, leveraging the strict privacy protections offered by hosting physically within Norway.

The Hardware Reality: CPU Overhead

Pro Tip: Encryption is CPU intensive. Many budget VPS providers oversell their CPU cycles using container technologies like Virtuozzo without guaranteeing resources. When your RSA handshake lags, your connection drops.

This is why I run this setup on CoolVDS. They use Xen virtualization, which means I get a dedicated kernel and reserved CPU cycles. More importantly, I have the ability to load the tun/tap kernel modules myself—something that frequently requires a support ticket on lesser hosting platforms.

Step 1: The Pre-flight Check

We are using CentOS 5. Ensure your system is up to date. First, we need the EPEL (Extra Packages for Enterprise Linux) repository, as OpenVPN isn't in the base CentOS repos.

Step 2: The PKI Infrastructure

Security relies on keys. We need to generate a Certificate Authority (CA), a server certificate, and client keys. OpenVPN ships with easy-rsa scripts to simplify this, but don't get complacent—key management is critical.

Follow the prompts. When asked for "Common Name", use your server's FQDN. Next, build the server key:

And finally, a client key for your laptop:

Don't forget to generate the Diffie-Hellman parameters. This will take a moment depending on your entropy pool.

Step 3: Server Configuration

Create /etc/openvpn/server.conf. Do not just copy-paste defaults. We need to optimize for latency and reliability. Since we are hosting in Norway, we want to minimize packet loss across the NIX (Norwegian Internet Exchange).

Understanding the Config

• proto udp: TCP over TCP causes meltdown when packets are dropped. Always use UDP for tunnels.
• push "redirect-gateway def1": This forces all your client's web traffic through the secure tunnel.
• comp-lzo: LZO compression helps speed up text-based transfers, crucial when you are on a slow 3G mobile connection.

Step 4: Routing and IPTables

Your server is now a router. You must enable IP forwarding in the kernel.

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

Now for the firewall. We need to MASQUERADE traffic coming from the VPN subnet (10.8.0.0/24) so it can exit through the server's public interface (usually eth0). Without this, your packets hit the server and die.

Why Location Matters

Latency is physics. If you are working with clients in Oslo or handling data covered by the Personopplysningsloven (Personal Data Act), routing traffic through a US server is inefficient and potentially non-compliant. A CoolVDS instance located in the heart of the Nordics ensures your ping remains low—often sub-10ms within the country—while keeping your data under Norwegian jurisdiction.

Furthermore, CoolVDS utilizes high-speed RAID-10 SAS storage. While OpenVPN is CPU-bound, logging and status updates benefit from fast I/O, preventing the system from locking up during high-traffic bursts.

Final Verification

Connect your client using the generated keys. Check your IP address on a site like whatismyip.com. It should reflect your VPS IP, not your local provider's. If so, your tunnel is active.

Don't wait for a security breach to audit your connection methods. Spin up a CoolVDS instance today; the provisioning time is fast, and you can have a secure, private gateway running before you finish your coffee.