Console Login

Hardening Your Network: Deploying OpenVPN on CentOS 6 with KVM

Stop Trusting Public Networks: The OpenVPN Solution

Let’s be honest for a second. If you are sitting in a coffee shop in Oslo or attending a conference at the Spektrum, and you log into your company's backend over the open Wi-Fi, you are begging to be compromised. We all saw what Firesheep did a couple of years ago. Session hijacking is trivial if you aren't tunneling your traffic.

As systems administrators, we need total control over our ingress and egress points. Relying on third-party VPN services adds latency and an unknown chain of custody to your data. The only way to ensure compliance with the Norwegian Personal Data Act (Personopplysningsloven) and keep the Datatilsynet happy is to own the infrastructure yourself.

In this guide, I’m going to walk you through deploying a production-ready OpenVPN server on a CentOS 6.2 box. We aren't doing this on a flimsy OpenVZ container where you have to beg support to enable the TUN/TAP module. We are using a proper KVM (Kernel-based Virtual Machine) environment, like the ones standard at CoolVDS, so we have full control over the kernel modules and iptables.

The Architecture: Why KVM Matters

Many low-cost VPS providers oversell resources using OpenVZ. The problem? OpenVPN requires the tun network driver. On shared kernel virtualization, if the host node hasn't enabled it for your specific container, your VPN server simply won't start. You'll see errors like:

Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

At CoolVDS, we treat your instance as a dedicated server. With KVM, you have your own kernel. You load your own modules. No tickets, no waiting. Just raw performance.

Prerequisites

  • A CoolVDS KVM instance running CentOS 6.2 (64-bit).
  • Root access (obviously).
  • The EPEL (Extra Packages for Enterprise Linux) repository enabled.

Step 1: Install OpenVPN and Easy-RSA

First, ensure your system is up to date and grab the necessary packages. We need openvpn for the daemon and easy-rsa to handle the PKI (Public Key Infrastructure). Manually managing certificates without these scripts is a nightmare you don't need.

yum update -y # If you haven't installed EPEL yet: rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm yum install openvpn easy-rsa -y

Step 2: Building the PKI (Public Key Infrastructure)

Security is only as strong as your keys. We are going to generate a Certificate Authority (CA), a server certificate, and client certificates. Do not skip the Diffie-Hellman parameters generation; it takes time, but entropy is your friend.

Copy the easy-rsa scripts to a working directory to avoid overwriting them later on updates:

mkdir -p /etc/openvpn/easy-rsa/2.0 cp -r /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa/2.0/ cd /etc/openvpn/easy-rsa/2.0

Edit the vars file. This saves you from typing your country and organization fields fifty times. Use vi vars:

export KEY_COUNTRY="NO" export KEY_PROVINCE="Oslo" export KEY_CITY="Oslo" export KEY_ORG="CoolVDS_Ops" export KEY_EMAIL="admin@yourdomain.com" export KEY_SIZE=2048
Pro Tip: Default key size is often 1024. Change KEY_SIZE to 2048. It increases the handshake time slightly, but in 2012, 1024-bit RSA is getting too close to the cracking threshold for comfort.

Now, build the keys:

source ./vars ./clean-all ./build-ca ./build-key-server server ./build-key client1 ./build-dh

Wait for the Diffie-Hellman generator. On a standard VPS, this can take a few minutes. On CoolVDS high-performance nodes, you'll notice this completes significantly faster due to better CPU allocation.

Step 3: Server Configuration

Create the config file at /etc/openvpn/server.conf. We are going to use UDP because tunneling TCP over TCP leads to "meltdown" when packet loss occurs (retransmission timers stack up).

port 1194 proto udp dev tun ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt cert /etc/openvpn/easy-rsa/2.0/keys/server.crt key /etc/openvpn/easy-rsa/2.0/keys/server.key dh /etc/openvpn/easy-rsa/2.0/keys/dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt # Push routes to the client so all traffic goes through the VPN push "redirect-gateway def1 bypass-dhcp" # Use Google DNS or your own internal DNS push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log verb 3

Step 4: Routing and IP Forwarding

This is where most people fail. The server needs to act as a router. First, enable packet forwarding in the kernel.

Edit /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Apply it:

sysctl -p

Now, configure iptables to masquerade the traffic coming from the VPN subnet (10.8.0.0/24) out to the internet via your public interface (usually eth0). Without this, your packets hit the internet with a private IP and never come back.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE service iptables save service iptables restart

Step 5: Start the Engine

Start the OpenVPN service and ensure it runs on boot.

service openvpn start chkconfig openvpn on

Latency and Geography: The Norwegian Advantage

Why host this in Norway? If your team is in Oslo, Bergen, or Trondheim, routing your encrypted traffic through a server in Frankfurt or London adds 20-40ms of unnecessary latency. By deploying on CoolVDS, located physically in Oslo, you are hitting the NIX (Norwegian Internet Exchange) directly. You get the security of the tunnel with ping times that feel like you're on the LAN.

Furthermore, data residency is becoming a massive topic. Keeping your traffic within Norwegian borders ensures you are protected by strong local privacy laws, rather than being subject to the whims of the US Patriot Act.

Conclusion

You now have a secure, encrypted tunnel for your internet traffic. Whether you are managing servers via SSH or just checking email at the airport, your data is wrapped in 2048-bit encryption.

Don't risk your infrastructure on shared, oversold containers. For cryptographic workloads and serious networking, you need dedicated resources.

Ready to secure your connection? Spin up a CoolVDS KVM instance today and have your VPN running in under 10 minutes.