Locking Down the Pipe: Building a Hardened OpenVPN Gateway on CentOS 5
Let’s be honest: trusting the unencrypted Wi-Fi at a hotel or your local coffee shop is professional suicide. Packet sniffers like Wireshark make it trivial for anyone sitting two tables away to pull cleartext passwords, IMAP emails, and unencrypted session cookies out of the air. If you are managing servers or accessing corporate data remotely, you are one man-in-the-middle attack away from a resume-generating event.
SSH tunnels are a quick fix, but for a full network solution that handles UDP and routes all traffic transparently, you need a proper VPN. While PPTP is widespread, its security flaws are well-documented. IPsec is a nightmare to configure behind NAT.
The solution is OpenVPN. It’s robust, SSL-based, and when configured correctly, impenetrable.
In this guide, we are going to build a battle-ready OpenVPN server on a CoolVDS Xen VPS running CentOS 5.3. We chose Xen because, unlike OpenVZ, it gives us full control over kernel modules like tun/tap and iptables, which are non-negotiable for this setup.
Why Host This in Norway?
Latency and Law. Those are the two L's that matter.
If you are in Northern Europe or Ukraine, routing your traffic through the US or UK adds unnecessary milliseconds. You want your endpoint close. A CoolVDS instance sitting in Oslo peers directly at NIX (Norwegian Internet Exchange), giving you sub-20ms latency to most of Scandinavia.
More importantly, we have the Personopplysningsloven (Personal Data Act). Norway is outside the direct jurisdiction of the US Patriot Act. If you care about data sovereignty and keeping your traffic logs (or lack thereof) away from prying eyes, hosting under the watchful eye of Datatilsynet offers a layer of legal comfort you don't get in Ashburn, Virginia.
Prerequisites
- A CoolVDS VPS (Minimum 256MB RAM recommended for OpenVPN).
- Root access (SSH).
- CentOS 5.x installed.
Step 1: Enable the EPEL Repository
CentOS default repositories are conservative. We need the Extra Packages for Enterprise Linux (EPEL) to fetch the OpenVPN binaries without compiling from source (which is a maintenance headache).
rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-3.noarch.rpm
Now, install the software:
yum install openvpn
Step 2: The PKI Infrastructure (Easy-RSA)
Security is only as good as your keys. We aren't using static keys here; we are building a proper Public Key Infrastructure (PKI). Copy the easy-rsa scripts to your configuration directory:
cp -R /usr/share/openvpn/easy-rsa/2.0 /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
Edit the vars file. Don't leave the defaults. If you leave the fields empty, you're just being lazy.
export KEY_COUNTRY="NO"
export KEY_PROVINCE="Oslo"
export KEY_CITY="Oslo"
export KEY_ORG="CoolVDS_Ops"
export KEY_EMAIL="admin@yourdomain.com"
Pro Tip: Increase the key size. The default is often 1024-bit. In 2009, computing power is cheap enough that we should be using 2048-bit keys to future-proof against brute force attacks. Changeexport KEY_SIZE=1024to2048in thevarsfile.
Now, build the Certificate Authority (CA) and server keys:
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
This will generate your Diffie-Hellman parameters. It might take a few minutes. Go grab a coffee.
Step 3: Server Configuration
Create /etc/openvpn/server.conf. This is where the magic happens. We will use UDP for speed, as TCP-over-TCP causes "TCP Meltdown" when packet loss occurs.
port 1194
proto udp
dev tun
ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/server.crt
key easy-rsa/keys/server.key
dh easy-rsa/keys/dh2048.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
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" line. This forces all client web traffic through the VPN, which is exactly what we want for securing public Wi-Fi usage.
Step 4: IP Forwarding and Iptables
OpenVPN handles the encryption, but the Linux kernel must handle the routing. If you don't enable forwarding, your packets hit the server and die there.
Edit /etc/sysctl.conf:
net.ipv4.ip_forward = 1
Apply it instantly:
sysctl -p
Now for the firewall. We need to NAT the traffic coming from the VPN subnet (10.8.0.0/24) out to the internet via the server's public interface. On CoolVDS Xen instances, this is usually eth0.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
service iptables save
service iptables restart
Step 5: Client Keys and Connection
Generate a key for your laptop:
cd /etc/openvpn/easy-rsa
source ./vars
./build-key client-laptop
Transfer ca.crt, client-laptop.crt, and client-laptop.key to your local machine using SCP. Do not email them. If you email your private key, you might as well publish it on a billboard.
Performance: The CoolVDS Advantage
Encryption is CPU intensive. When you are pushing 10-20 Mbps of encrypted traffic, a weak CPU will choke, introducing latency (jitter) into your SSH sessions. This is where the underlying hardware matters.
Many budget hosts oversell their CPU cores. You might see "2.4GHz," but if the host node is overloaded with 500 containers, your steal time (checking via top) will skyrocket. At CoolVDS, we maintain strict tenant ratios. We use high-speed SAS RAID-10 storage arrays which, while not strictly necessary for VPN buffering, ensure that system logging doesn't block I/O operations during heavy traffic spikes.
Final Check
Start the service:
service openvpn start
Check the logs at /var/log/messages. If you see Initialization Sequence Completed, you are live.
You now have a private, encrypted tunnel directly into the backbone of the Norwegian internet. No more worrying about the guy with the Pringles can antenna in the parking lot.
Ready to secure your communications? Deploy a CentOS 5 instance on CoolVDS today and lock your network down in under 10 minutes.