Tunnel Vision: Architecting a Hardened OpenVPN Gateway on CentOS 6

The Illusion of Safety on Public Networks

It is 2012. If you are sitting in a coffee shop in Grünerløkka or waiting for a flight at Gardermoen, connecting to open WiFi is akin to shouting your passwords across the room. With tools like Firesheep making session hijacking trivial, and HTTP still dominating the web over HTTPS, your data is naked. Period.

Corporate espionage is not a movie plot; it is a business model. If you are a developer pushing code or a sysadmin managing remote servers without a secure tunnel, you are negligent. The solution isn't expensive hardware appliances. It's a robust, self-hosted VPN (Virtual Private Network) on a reliable Linux box.

Why host it yourself? Because "free" VPN services monetize your traffic logs. In Norway, we have the Personopplysningsloven (Personal Data Act), but once your data leaves the border, jurisdiction gets murky. By anchoring your exit node in Oslo on a CoolVDS instance, you retain control, low latency to Norwegian infrastructure (NIX), and legal clarity.

Prerequisites and Architecture

We aren't building a toy. We are building a gateway capable of handling your entire team's traffic. We will use OpenVPN 2.2 on CentOS 6.2. This combination is battle-tested and stable.

The Stack:

• OS: CentOS 6.2 (64-bit)
• VPN Software: OpenVPN 2.2 (via EPEL)
• Encryption: AES-256-CBC with 2048-bit RSA keys
• Firewall: iptables

Architect's Note: Many budget VPS providers use OpenVZ virtualization. This often causes headaches with the tun/tap device required for OpenVPN, as it requires host-node enabling. CoolVDS uses KVM (Kernel-based Virtual Machine), providing a true hardware virtualization layer. This means you have full control over kernel modules and networking devices. Never compromise on virtualization technology.

Step 1: System Prep and Dependencies

First, we need the EPEL (Extra Packages for Enterprise Linux) repository, as CentOS base repos do not ship OpenVPN.

# Update the system
yum update -y

# Install EPEL repository for EL6
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm

# Install OpenVPN and OpenSSL
yum install openvpn openssl -y

Step 2: Building the PKI (Public Key Infrastructure)

Encryption is only as strong as your keys. We will use `easy-rsa` to generate our Certificate Authority (CA) and server/client keys. Do not rely on default 1024-bit keys; computation is cheap, and security is priceless. We are moving to 2048-bit.

Copy the scripts to a working directory:

cp -R /usr/share/openvpn/easy-rsa/2.0 /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa

Edit the vars file. This saves you from typing the same parameters repeatedly. Set KEY_SIZE=2048.

vi vars

Change these lines to reflect your organization:

export KEY_COUNTRY="NO"
export KEY_PROVINCE="Oslo"
export KEY_CITY="Oslo"
export KEY_ORG="CoolVDS_Ops"
export KEY_EMAIL="admin@yourdomain.no"
export KEY_SIZE=2048

Now, build the certificates. This is the critical phase where entropy matters. On a standard HDD, this can take time. On CoolVDS's high-performance SSD storage, the I/O operations for key generation finish significantly faster.

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

Note: build-dh (Diffie-Hellman parameters) will take time. Go grab a coffee.

Step 3: Server Configuration

Create the config file at /etc/openvpn/server.conf. We are going to use a routed setup (tun) rather than bridged (tap) for efficiency on mobile networks.

port 1194
proto udp
dev tun

# Certificate paths
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem

# Network topology
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

# Push routes to client to redirect gateway
push "redirect-gateway def1 bypass-dhcp"

# Use Google DNS or your ISP's DNS
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

# Security hardening
cipher AES-256-CBC
user nobody
group nobody

# Compression and reliability
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Step 4: IP Forwarding and iptables

Your server needs to act like a router. Enable packet forwarding in the kernel.

sysctl -w net.ipv4.ip_forward=1
# Make it permanent
sed -i 's/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/g' /etc/sysctl.conf

Now, configure iptables to NAT the traffic leaving the VPN tunnel out to the internet. Replace eth0 with your public interface if different.

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

Step 5: Client Generation

Generate a key for your laptop or mobile device:

cd /etc/openvpn/easy-rsa
source ./vars
./build-key client-laptop

You will need to transfer ca.crt, client-laptop.crt, and client-laptop.key to your client machine securely (use SCP, not email!).

Why Infrastructure Matters

You might think, "Can't I run this on a cheap $2 VPS?" You can, if you enjoy packet loss. Encryption is CPU intensive. While OpenVPN is single-threaded, the context switching and I/O wait times on over-sold host nodes will kill your throughput.

When you tunnel all your traffic—VoIP, SSH sessions, huge file transfers—through a single point, that point becomes your bottleneck. We designed CoolVDS for high-availability workloads. By using pure SSD storage and uncongested 1Gbps uplinks to the NIX exchange, we ensure that your "secure tunnel" doesn't become a "slow tunnel." Security should not cost you productivity.

Final Launch

Start the service and ensure it runs on boot:

service openvpn start
chkconfig openvpn on

Check the logs at /var/log/messages or the status log. If you see Initialization Sequence Completed, you are live. Connect your client, check your IP address, and browse knowing that the prying eyes at the airport are seeing nothing but encrypted noise.