Stop Trusting Public Networks: Build Your Own Encrypted Tunnel
Let’s be honest. If you are logging into your production servers via SSH over a hotel Wi-Fi connection or a coffee shop hotspot without a VPN, you are asking for a breach. I recently audited a client in Oslo who lost root access to a critical database server because a developer used plain FTP over an unencrypted airport connection. Packet sniffing isn't just something script kiddies do; it's an automated industry.
Third-party VPN services are not the answer. They claim "zero logs," but when the subpoenas come, they fold. The only way to ensure the integrity of your traffic is to own the endpoint. You need a VPS, you need a Linux kernel you control, and you need OpenVPN.
In this guide, we are deploying a hardened OpenVPN endpoint on CentOS 6.3. Why CentOS? Because it is stable, predictable, and doesn't break packages every other week. We will be using a CoolVDS KVM instance because OpenVZ containers often have issues with TUN/TAP devices if the host node isn't configured correctly. With KVM, we own the kernel.
The Architecture of Trust
We aren't just installing a package. We are building a secure gateway. Our goal is to route all client traffic through an encrypted tunnel, masking your IP and encrypting your data stream with AES-256.
Pro Tip: Latency matters. If your team is in Norway, hosting your VPN in the US will add 100ms+ of lag to every handshake. Keep your VPN endpoint geographically close. Our CoolVDS datacenter in Norway peers directly with NIX (Norwegian Internet Exchange), keeping latency typically under 10ms for local traffic.
Step 1: Prerequisites and Environment
Start with a fresh CentOS 6 install. Do not use an existing web server; your security gateway should do one thing and one thing only. Ensure you have the EPEL (Extra Packages for Enterprise Linux) repository enabled, as OpenVPN isn't in the base CentOS repos.
# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# rpm -Uvh epel-release-6-8.noarch.rpm
# yum update -y
# yum install openvpn easy-rsa -y
Step 2: The PKI Infrastructure (Do Not Skip This)
Security relies on keys. We are using `easy-rsa` to generate our Certificate Authority (CA). Do not use the default 1024-bit keys. In 2012, 1024-bit is theoretically vulnerable to state-level actors. We bump this to 2048-bit.
Copy the scripts to a working directory to avoid overwriting updates:
# mkdir -p /etc/openvpn/easy-rsa/keys
# cp -rf /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 your country and organization every time you generate a key. Focus on the `KEY_SIZE` parameter.
# vi vars
# Change these lines:
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 <-- CRITICAL
Now, build the CA and the server certificate.
# source ./vars
# ./clean-all
# ./build-ca
# ./build-key-server server
# ./build-dh
This will generate `dh2048.pem`. It takes time. On a standard shared host, the entropy generation can stall. On CoolVDS's high-performance SSD backed instances, this completes rapidly due to better I/O throughput helping entropy gathering.
Step 3: Server Configuration
Create `/etc/openvpn/server.conf`. This is the brain of your VPN. We are going to use UDP for speed (TCP results in "TCP meltdown" when packets drop) and push specific routes to the client.
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
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 Public DNS or your own internal resolvers
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: Packet Forwarding and IPTables
Your VPN is useless if the server doesn't know how to pass traffic from the virtual `tun0` interface to the physical `eth0` interface. Enable IP forwarding in the kernel.
# sysctl -w net.ipv4.ip_forward=1
# sed -i 's/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/' /etc/sysctl.conf
Now, configure `iptables`. CentOS 6 relies heavily on manual iptables management. We need a NAT (Network Address Translation) rule.
# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
# service iptables save
# service iptables restart
Verify your rules with `iptables -L -t nat`. You should see the MASQUERADE rule. Without this, your packets hit the server and die there.
Step 5: Client Side Generation
Generate a key for your laptop:
# cd /etc/openvpn/easy-rsa
# source ./vars
# ./build-key laptop-client
You need to securely transfer `ca.crt`, `laptop-client.crt`, and `laptop-client.key` to your local machine. Do not email them. Use SCP.
Why Infrastructure Choice Dictates Security
You might ask, "Why not just run this on a cheap $2 VPS?" The answer is IOPS and Kernel Control. Cheap containers often oversell CPU cycles. Encryption is CPU intensive. If your host node is overloaded, your VPN throughput drops, and your SSH sessions lag.
| Feature | Generic OpenVZ VPS | CoolVDS KVM |
|---|---|---|
| Kernel Access | Shared (Restricted) | Dedicated (Full Control) |
| TUN/TAP | Often disabled by host | Always available |
| Storage | Slow spinning SATA | Pure SSD RAID-10 |
| Privacy | Host can see processes | Hardware Virtualization Isolation |
At CoolVDS, we utilize enterprise-grade SSDs in RAID-10 arrays. While standard HDDs struggle with the random I/O generated by multiple encrypted streams, SSDs handle it effortlessly. Combined with the strict data privacy laws enforced by Datatilsynet in Norway, you have a bunker for your data.
Finalizing the Deployment
Start the service and ensure it runs on boot:
# service openvpn start
# chkconfig openvpn on
Check `/var/log/messages` for any errors. If you see `Initialization Sequence Completed`, you are live.
Security isn't a product; it's a process. But starting with the right foundation—standardized protocols like OpenVPN and robust infrastructure like CoolVDS—gives you a fighting chance against the surveillance dragnet. Don't compromise on your uplink.
Need a dedicated IP for your VPN gateway? Deploy a CoolVDS instance in Oslo today and get root access in under 60 seconds.