Stop Trusting Public Networks: The Case for OpenVPN

Let's be real for a moment. If you are logging into your production servers via SSH from a hotel Wi-Fi in Gardermoen or a coffee shop in Grünerløkka, you are asking for trouble. Unencrypted HTTP traffic is wide open to anyone with a copy of Wireshark, and even SSH handshakes can be scrutinized for timing attacks if the network is hostile enough.

The solution isn't new, but few implement it correctly: OpenVPN. It creates a secure tunnel, encapsulating your traffic in 2048-bit encryption before it ever hits the wire. But here is the catch: most generic virtual servers choke on VPN traffic.

I've spent the last week debugging a setup for a client in Oslo who couldn't keep a stable connection to their internal wiki. The culprit? Their previous budget host had oversold the CPU so badly that the encryption overhead caused massive packet loss. We moved them to a CoolVDS instance with guaranteed CPU cycles and proper Xen virtualization, and the tunnel has been rock solid since.

The Prerequisite: Tun/Tap and Virtualization

Before you even type yum install, you need to understand the underlying architecture. OpenVPN requires the tun or tap network drivers. On legacy OpenVZ containers (which many budget providers still force on you), you are at the mercy of the host kernel. If the provider hasn't enabled the module for your container, you are dead in the water.

This is why serious sysadmins prefer VPS Norway solutions based on Xen or KVM (like we use at CoolVDS). We give you your own kernel. You load the modules you need. No begging support tickets required.

Step 1: The Environment (CentOS 5.5)

We are using CentOS 5.5 for this deployment because of its stability in enterprise environments. First, we need the EPEL repository, as OpenVPN isn't in the base CentOS repos.

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

Step 2: The PKI Infrastructure

Security relies on keys, not passwords. We will use the easy-rsa scripts included with the documentation.

cp -r /usr/share/doc/openvpn-2.1.1/easy-rsa/2.0 /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
chmod 755 *

Edit the vars file. Don't leave the defaults as "Changeme". Set KEY_COUNTRY="NO" and KEY_PROVINCE="Oslo". This matters if you ever need to audit your certificates later.

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

Pro Tip: Generating the Diffie-Hellman parameters (build-dh) involves heavy math. On a cheap, shared VPS, this can take 20 minutes because of low entropy. On high-performance storage systems like the RAID-10 SAS arrays we run at CoolVDS, this clears much faster due to lower I/O wait times.

Step 3: Server Configuration

Create /etc/openvpn/server.conf. We are going to use UDP because TCP-over-TCP leads to "TCP Meltdown" when packet loss occurs.

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.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 IP Tables

This is where 90% of setups fail. You have a tunnel, but traffic goes nowhere. You must enable IP forwarding and configure NAT.

Edit /etc/sysctl.conf: net.ipv4.ip_forward = 1 Run sysctl -p to apply.

Then, configure iptables to masquerade traffic leaving the VPN subnet:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
/etc/init.d/iptables save
/etc/init.d/iptables restart

Why Latency Matters in Norway

If your team is in Oslo, routing your encrypted traffic through a server in Germany or the US adds unnecessary milliseconds to every packet. For SSH sessions, that lag is torture. It makes typing feel like walking through mud.

By hosting your VPN endpoint locally in Norway, you keep the latency low (often sub-10ms). Furthermore, complying with the Personal Data Act (Personopplysningsloven) and the guidelines from Datatilsynet is significantly easier when your data transit points remain within national borders.

Final Thoughts

A VPN is your first line of defense. Don't put it on hardware that can't handle the math. While OpenVPN 2.1 is efficient, the context switching between user space and kernel space demands a responsive CPU.

If you are tired of "Connection Reset" errors during file transfers, it’s time to upgrade your infrastructure. Deploy a managed hosting solution that understands the Linux kernel.

Ready to lock down your network? Spin up a CentOS 5 instance on CoolVDS today and get your tunnel running in under 10 minutes.