Console Login
Home / Blog / Tutorials / Stop Leaking Data: Building a Bulletproof OpenVPN Gateway on CentOS 5
Tutorials ‱ ‱ 0 views

Stop Leaking Data: Building a Bulletproof OpenVPN Gateway on CentOS 5

@

Stop Leaking Data: Building a Bulletproof OpenVPN Gateway on CentOS 5

Let’s be honest: relying on PPTP in 2009 is professional negligence. With the vulnerabilities exposed in MS-CHAPv2 and the sheer instability of GRE protocol traversal through standard NAT routers, you are asking for trouble. Whether you are connecting from a client site in Oslo or a hotel Wi-Fi in Kyiv, cleartext traffic—yes, even your FTP sessions and POP3 email—is being sniffed.

I recently audited a consultancy firm that had their entire SVN repository comprised because a developer committed code over an unencrypted café connection. Don't be that guy. The solution is an SSL-based VPN using OpenVPN.

Unlike IPsec, which can be a nightmare to configure with dynamic IPs, OpenVPN operates in user space and offers granular control. But it requires a VPS provider that actually understands Linux networking.

The Hardware Reality: Why TUN/TAP Matters

Most budget VPS hosts oversell their nodes using Virtuozzo or old OpenVZ implementations that restrict kernel modules. If you try to load the tun module, you get a permission denied error. Game over.

At CoolVDS, we use Xen hypervisors. This means you get a genuine kernel environment. We enable the TUN/TAP device by default because we assume our customers are competent admins who need to route traffic, not just host static HTML.

Step 1: The Environment

We are deploying on CentOS 5.3 (32-bit is fine for a VPN gateway, saves RAM). You need the EPEL repository because Red Hat doesn't ship OpenVPN in base.

wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-3.noarch.rpm
rpm -ivh epel-release-5-3.noarch.rpm
yum install openvpn

Step 2: The PKI Nightmare (Simplified)

Encryption is only as strong as your keys. We aren't using shared secrets here; we are building a proper Public Key Infrastructure (PKI). Copy the easy-rsa scripts to /etc/openvpn.

Pro Tip: Edit the vars file before you generate anything. Set KEY_SIZE=2048. The default 1024 is technically okay for now, but with computing power doubling, why risk it? Also, set your KEY_COUNTRY and KEY_PROVINCE correctly—Datatilsynet (The Norwegian Data Inspectorate) likes to see proper organizational data if you are audited.
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-key client1
./build-dh

This generates the Diffie-Hellman parameters. On a slow shared VPS, this takes forever. On a CoolVDS instance with RAID-10 SAS storage and dedicated CPU cycles, it finishes before you can grab a coffee.

Step 3: Server Configuration

Create /etc/openvpn/server.conf. We are using UDP for speed (TCP over TCP leads to meltdown due to retransmission timers) and a tun interface for routing.

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Step 4: Routing and IPTables

This is where 90% of setups fail. You have a tunnel, but packets have nowhere to go. You must enable IP forwarding in the kernel.

Edit /etc/sysctl.conf: net.ipv4.ip_forward = 1

Apply it with sysctl -p. Now, configure iptables to masquerade traffic leaving your VPS. This effectively turns your CoolVDS server into your router on the internet.

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

Why Location Matters

If you are in Norway, tunneling through a US server adds 150ms of latency. It makes SSH sessions feel like you are typing through molasses. You need a breakout point in Oslo.

Feature Budget Host (US) CoolVDS (Oslo)
Ping to NIX ~140ms < 5ms
Virtualization Virtuozzo (No TUN) Xen (Full Kernel)
Data Jurisdiction Patriot Act Risk Personopplysningsloven

Final Thoughts

Once you start the service with service openvpn start, your traffic is encrypted inside the tunnel. Your ISP sees UDP garbage on port 1194. You see the internet.

Don't let a sloppy network configuration compromise your client data. If you need a reliable, Xen-based node with 15k RPM drive speeds to handle encryption overhead, spin up a CoolVDS instance today. We don't mess with your kernel, so you can lock down your network exactly how you need to.

/// TAGS
← Back to All Posts