Building a Bulletproof OpenVPN Gateway on CentOS 5

Let’s be honest: transmitting unencrypted data over public networks in 2009 is professional suicide. Whether you are syncing code to a repository or accessing an internal administration panel, relying on the "security" of a hotel Wi-Fi or a client's open network is asking for a data breach. We have seen enough man-in-the-middle attacks this year to know that SSL/TLS for web traffic isn't enough—you need a full tunnel.

While SSH tunneling works for quick hacks, a persistent, routed solution is required for a dispersed team. That solution is OpenVPN. It is robust, open-source, and handles the erratic latency of the internet far better than IPsec in my experience.

However, setting it up correctly on a Virtual Private Server (VPS) is not trivial. Many providers oversell their virtualization platforms, leaving you with a kernel that cannot load the TUN/TAP modules required for packet tunneling. This guide will walk you through deploying a production-ready OpenVPN 2.1 server on CentOS 5, ensuring you have the encryption and routing stability your business demands.

1. The Foundation: Virtualization Matters

Before we touch a single config file, we need to talk about the underlying architecture. OpenVPN operates in user space but relies heavily on the kernel's network stack.

Pro Tip: Avoid cheap "container" hosting if you can't verify kernel module access. On legacy OpenVZ kernels, if the host node hasn't enabled the tun module for your container ID (VEID), your VPN will fail to start with a cryptic modprobe: FATAL: error.

This is why for critical infrastructure, I default to CoolVDS. We utilize Xen hypervisors which provide full hardware virtualization. This means you get your own kernel, full control over iptables modules, and guaranteed RAM. When you are encrypting traffic at line speed, you don't want to be fighting a "noisy neighbor" for CPU cycles.

2. Prerequisites and Installation

We will assume you are running a fresh install of CentOS 5.4 (x86_64). First, we need to enable the EPEL (Extra Packages for Enterprise Linux) repository, as OpenVPN isn't in the standard yum repos.

Once installed, copy the sample configuration files and the `easy-rsa` scripts. We aren't going to generate keys in the default directory; we will create a locked-down directory structure.

3. The PKI Nightmare: Certificate Management

The strength of OpenVPN lies in its use of OpenSSL for authentication. We aren't using weak pre-shared keys here. We are building a Public Key Infrastructure (PKI). Edit the vars file to save time later.

Scroll down and adjust these variables to match your organization. This is crucial for compliance with the Personal Data Act (Personopplysningsloven) if you are handling sensitive Norwegian client data; you want accurate ownership info on these certs.

Now, build the Certificate Authority (CA) and the server certificate. This is the "war room" step—do not mess this up.

The Diffie-Hellman parameter generation (build-dh) will take time. On a standard shared host, this could take 10 minutes. On a CoolVDS instance with high-performance SAS storage and dedicated CPU cores, it usually completes in under 2 minutes. While you wait, let's discuss ciphers. The default Blowfish-CBC is acceptable, but for higher security, consider AES-256-CBC if your endpoints support it.

4. Server Configuration: Optimization & Reliability

Create the main configuration file at /etc/openvpn/server.conf. We are going to use UDP for transport. TCP over TCP leads to "TCP Meltdown" when packet loss occurs, causing latency spikes that destroy VoIP quality.

Optimization Note

The comp-lzo directive enables compression. This is vital. If you are tunneling text-based traffic (like SQL queries or code), this can effectively double your throughput. However, compression requires CPU power. This is where the distinction between cheap VPS hosting and premium infrastructure becomes apparent.

5. Routing and Firewalls: The "Iptables" Dance

Your VPN is useless if traffic cannot leave the server. We need to enable IP forwarding in the Linux kernel.

Change net.ipv4.ip_forward = 0 to 1. Then apply it:

Now for the firewall. We must allow traffic on port 1194 and masquerade the VPN traffic so it looks like it's coming from the server's public IP. This is standard Network Address Translation (NAT).

Security Warning: Ensure you are not leaving your SSH port (default 22) wide open to the world while configuring this. Use hosts.allow or restrict SSH to specific IP ranges.

6. Local Compliance & Latency

Why host this in Norway? Aside from the Datatilsynet guidelines regarding data residency, latency is the killer of productivity. If your development team is in Oslo or Bergen, routing your encrypted traffic through a server in Germany or the US adds unnecessary milliseconds.

Connecting to the Norwegian Internet Exchange (NIX) ensures that your data stays local, fast, and legally compliant. When you are running rsync jobs over a VPN, that latency difference is the gap between a 5-minute sync and a 30-minute headache.

Conclusion

Once you have the server running (service openvpn start), generate your client keys using ./build-key client1 and distribute them securely (SCP is your friend). Do not email certs.

Configuring OpenVPN manually forces you to understand the network stack, but it provides a level of security and performance that automated tools simply cannot match. You need a host that respects that performance.

For a robust, low-latency foundation that supports custom kernel modules and high-speed I/O, CoolVDS is the pragmatic choice for the professional Norwegian sysadmin. Don't let your infrastructure be the bottleneck.

Next Step: Check your current latency. If you are pinging over 20ms to your own gateway, it's time to migrate. Deploy a CoolVDS instance today and verify the difference.