Building a Fortress: The Definitive Guide to OpenVPN on CentOS 6

Let’s be honest: the internet is a hostile environment. Since the release of tools like Firesheep a couple of years ago, sitting in a coffee shop in Grünerløkka and logging into your backend without a tunnel is practically inviting disaster. HTTPS isn't everywhere yet, and if you are pushing code or managing databases over plain text protocols, you are compromised. Period.

I've seen too many systems administrators rely on PPTP because it's "easy" to set up on Windows Server. It’s also broken. The encryption is weak, and it can be cracked in hours. If you are serious about security, you use OpenVPN. It’s the industry standard for a reason: SSL/TLS security, robust configuration, and it works over UDP.

In this guide, we are going to build a hardened OpenVPN server on CentOS 6.2. We aren't using a script. We are doing this manually so you understand exactly what is happening in your kernel.

The Hardware Reality: Latency Matters

Before touching the terminal, let's talk about where this packet tunnel lives. You can set this up on an EC2 instance in Virginia, but if you are working from Oslo, your latency is going to jump from 5ms to 120ms. SSH typing becomes painful. vi becomes unusable.

For my setups, I rely on CoolVDS. Why? Because they peer directly at NIX (Norwegian Internet Exchange). When I ping my gateway, I want single-digit latency. Furthermore, OpenVPN is CPU-heavy when you crank up the encryption keys. Many "cheap" VPS providers oversell their CPU cycles using OpenVZ, leading to jittery connections when your neighbors get busy. CoolVDS uses KVM virtualization, meaning my allocated CPU cycles are actually mine.

Step 1: Preparation and Dependencies

First, ensure your system is updated. We need the EPEL repository because OpenVPN isn't in the standard CentOS base repo.

Pro Tip: Always verify the GPG key of the EPEL repo. I've skipped it here for brevity, but in a production environment, never trust a package blindly.

Step 2: The PKI Infrastructure (Don't mess this up)

OpenVPN relies on a Public Key Infrastructure (PKI). We need a Certificate Authority (CA), a server certificate, and client certificates. We will use the easy-rsa scripts provided by the package, but we are going to modify them for higher security. 1024-bit keys were fine in 2008. In 2012, we use 2048-bit.

Find the line export KEY_SIZE=1024 and change it to:

Now, build the CA and the server key. This might take a moment depending on the entropy available on your VPS. If it hangs, generate some I/O on the disk.

The build-dh (Diffie-Hellman) parameter generation is the most critical part for forward secrecy. On a standard VPS, this takes time. Grab a coffee.

Step 3: Server Configuration

Create the config file at /etc/openvpn/server.conf. Do not use the defaults. We want to force traffic through the tunnel and drop privileges for security.

Why UDP? TCP over TCP is a bad idea. When the underlying connection drops packets, the TCP retransmission timers fight each other, leading to a "meltdown" of the tunnel. Always use UDP for VPNs unless a firewall strictly blocks it.

Step 4: Routing and IP Tables

A VPN is useless if it doesn't forward traffic. Enable IP forwarding in the kernel:

Make it permanent in /etc/sysctl.conf.

Now, the part that scares most developers: iptables. We need to NAT the traffic coming from the VPN subnet (10.8.0.0/24) out through the public interface (usually eth0). Without this, your packets hit the server and die there.

If you are running a strict firewall (which you should be), ensure port 1194 UDP is open.

Step 5: Client Generation

Generate a key for your laptop:

You need to securely transport ca.crt, client1.crt, and client1.key to your local machine. Use SCP. Do not email these keys. If you email your private key, you might as well print it out and tape it to a lamppost in Oslo Central Station.

Local Nuances: Privacy and The Datatilsynet

Operating a VPN node in Norway brings specific advantages. The Personopplysningsloven (Personal Data Act) is strict. While we aren't storing customer data on this VPN, hosting your infrastructure within Norwegian borders under Norwegian jurisdiction provides a layer of legal clarity that you don't get hosting in cheaper, offshore jurisdictions.

However, compliance requires control. You must know where your physical bits reside. CoolVDS guarantees that your data stays in their Oslo datacenter, satisfying the requirement for data sovereignty often requested by Norwegian enterprise clients.

Conclusion

You now have a secure, encrypted tunnel. Your ISP sees only a stream of UDP packets to a single IP. Your traffic is safe from prying eyes at the airport or the hotel.

But remember, a VPN is only as fast as the pipe it runs on. Encryption adds overhead. If you run this on a budget VPS with high "steal time" on the CPU or congested I/O, your connection speed will tank. I use CoolVDS because the I/O throughput is consistent, and the network blend is optimized for Nordic traffic. Security shouldn't come at the cost of performance.

Next Steps: Lock down your SSH to listen only on the VPN interface (10.8.0.1). That way, even if someone finds your public IP, port 22 is closed to the world. Stay paranoid.