Tunnel Vision: Building a Bulletproof OpenVPN Gateway on CentOS 6

Let's be honest. If you are logging into your production servers via plain FTP or Telnet from a coffee shop in Grünerløkka, you deserve to get hacked. Even unencrypted HTTP traffic is a goldmine for anyone running Firesheep or a basic packet sniffer on the local network.

Security isn't about paranoia; it's about physics and protocol. As a sysadmin, you need a secure pipe. You need to route your traffic through a trusted endpoint before it hits the open internet. You need a VPN. But relying on third-party VPN services means trusting their logs. The only way to be sure is to build it yourself.

Today, we are deploying OpenVPN 2.2 on CentOS 6. Why OpenVPN? Because IPsec can be a nightmare to debug through NAT, and PPTP has been cryptographically broken for years. OpenVPN is the industry standard for SSL-based tunneling.

The Latency Equation

Before we touch the terminal, let's talk about geography. If you are working in Oslo and your VPN endpoint is in Texas, your packets are crossing the Atlantic twice. Your ping goes from 4ms to 180ms. Your SSH sessions will lag. It becomes unusable.

For Norwegian professionals, the endpoint needs to be in Norway. This is why I provision my tunnels on CoolVDS. Their datacenter is peered directly at NIX (Norwegian Internet Exchange), meaning the latency from my laptop to the VPN server is effectively negligible. You want your encryption overhead to be the bottleneck, not the speed of light.

Step 1: The Foundation

We assume you have a fresh CoolVDS VPS instance running CentOS 6.2 (or similar RHEL 6 derivative). First, we need the EPEL (Extra Packages for Enterprise Linux) repository, as OpenVPN isn't in the standard Red Hat repos.

Step 2: The PKI Infrastructure

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 with the documentation.

Copy the scripts to a working directory so future updates don't overwrite your keys:

Edit the vars file. This saves you from typing your country and organization fifty times. Open it with vi and scroll to the bottom:

Now, build the CA and the Server Key. Warning: The `clean-all` command wipes any existing keys. Only run this on a fresh install.

When asked for the "Common Name", use your server's hostname. Next, generate the Diffie-Hellman parameters. This generates the entropy needed for key exchange. On a standard VPS, this might take a minute or two.

Step 3: Server Configuration

This is where the magic happens. We need to tell OpenVPN how to handle the tunnel. Create /etc/openvpn/server.conf. I prefer UDP over TCP for tunnels to avoid the "TCP meltdown" effect where retransmissions stack up.

Pro Tip: If you are concerned about Datatilsynet compliance and data retention, ensure your logging verbosity is kept low (verb 3 is standard) and setup log rotation. You don't want to store connection logs longer than necessary.

Step 4: Packet Forwarding & Routing

By default, Linux is a host, not a router. We need to enable IP forwarding. Edit /etc/sysctl.conf:

Apply the change immediately:

Now, we must configure iptables to translate the private 10.8.0.x addresses from the VPN clients to the public IP of your CoolVDS instance. This is NAT (Network Address Translation).

If you don't save the iptables rules, they vanish on reboot, and your VPN connects but passes zero traffic. I've seen senior admins lose hours debugging this.

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 (Secure Copy). Do not email these files.

Why Infrastructure Matters

You can configure the tightest encryption in the world (AES-256-CBC), but if the underlying host is unstable, your connection drops. OpenVPN is sensitive to packet loss. When I deploy these gateways for clients in Oslo or Bergen, I specifically request CoolVDS instances because of the I/O stability.

In a shared hosting environment, a "noisy neighbor" maxing out their disk can cause jitter in your VPN packets. CoolVDS uses strict resource isolation (KVM), ensuring your CPU cycles are actually yours. For a security gateway, that consistency is non-negotiable.

Final Verification

Start the service:

Connect from your client. Once the tunnel is up, visit a site like `whatismyip.com`. You should see the IP address of your VPS, not your local ISP connection. You are now encrypted. You are now tunneling through a secure fortress in Norway.

Security is a process, not a product. Keep your server updated, rotate your keys annually, and never settle for high-latency connections. Ready to build your own secure gateway? Deploy a high-performance instance on CoolVDS today and lock down your traffic.