Fortify Your Traffic: Deploying OpenVPN on Ubuntu 10.04 LTS in the Norwegian Cloud

It happened again last week. I was auditing a client's logs—a mid-sized logistics firm operating out of Bergen—and noticed suspicious login attempts originating from an IP block associated with a popular hotel chain in Oslo. Their sales director was on the road, connecting via unencrypted hotel Wi-Fi, and someone was sniffing packets. In 2010, where HTTP is still the default for far too many intranets and login portals, sending cleartext data over the air is professional suicide.

If you are managing infrastructure or traveling for business, you cannot rely on the perimeter security of the coffee shop in Grünerløkka or the airport lounge. You need a tunnel. Specifically, you need OpenVPN.

While PPTP is available, its encryption has known weaknesses. OpenVPN, utilizing SSL/TLS for key exchange, is the industry standard for robust security. However, deploying it on a Virtual Private Server (VPS) comes with a catch that trips up many junior admins: the virtualization platform.

The Virtualization Trap: Most budget hosting providers stuff you onto OpenVZ or Virtuozzo containers. In these environments, you share a kernel with hundreds of others. Often, the tun/tap device required for OpenVPN is disabled by the host node to save resources. You follow a tutorial, and it fails with modprobe: FATAL: Module tun not found.

At CoolVDS, we refuse to compromise. We use KVM (Kernel-based Virtual Machine) virtualization. This gives you a dedicated kernel. You can load your own modules, configure your own iptables chains, and never worry about a noisy neighbor crashing your VPN daemon.

The Architecture

We are going to deploy an OpenVPN 2.1 server on Ubuntu 10.04 LTS (Lucid Lynx). This release is rock-solid and will be supported for years. We will configure it to route all client traffic through the VPN, effectively masking your location and encrypting your data stream.

Prerequisites:

• A CoolVDS KVM instance (256MB RAM is sufficient, 512MB recommended for heavier encryption).
• Root access (SSH).
• A clean OS install.

Step 1: Installation and PKI Setup

First, ensure your repositories are up to date and install the OpenVPN package along with OpenSSL.

OpenVPN relies on a Public Key Infrastructure (PKI) to authenticate clients. We don't need a commercial certificate authority for this; we will build our own using the included easy-rsa scripts. Copy the scripts to a configuration directory so updates don't overwrite your keys.

Now, edit the vars file to set your default parameters. This saves you from typing your country and organization repeatedly.

Scroll down and change these values to match your organization. Since we are operating under Norwegian jurisdiction—adhering to the Personopplysningsloven—accuracy here is good practice.

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

Initialize the PKI:

Follow the prompts. Next, generate the server certificate and the Diffie-Hellman parameters. The DH generation will take time—grab a coffee.

Step 2: Server Configuration

We need a configuration file. Ubuntu provides a sample that we can decompress and modify.

Inside server.conf, we must make specific adjustments to ensure traffic is actually routed through the tunnel. Look for and uncomment/modify the following lines:

# 1. Use the keys we just generated
ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/server.crt
key easy-rsa/keys/server.key
dh easy-rsa/keys/dh1024.pem

# 2. Force all client traffic through the VPN
push "redirect-gateway def1 bypass-dhcp"

# 3. Provide DNS servers to prevent DNS leaking
# Using OpenDNS or Google DNS (8.8.8.8) is common
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

# 4. Drop privileges for security
user nobody
group nogroup

Step 3: IP Forwarding and Routing

This is where 90% of installations fail. If the server doesn't know how to forward packets from the virtual adapter to the physical ethernet adapter, your traffic hits a dead end.

Enable packet forwarding in the kernel:

To make this permanent, edit /etc/sysctl.conf and uncomment net.ipv4.ip_forward=1.

Now, configure iptables to NAT the traffic. Assuming your WAN interface is eth0 (standard on CoolVDS KVM instances):

Save these rules so they persist after a reboot. In Ubuntu 10.04, I prefer using a simple pre-up script in /etc/network/interfaces or utilizing iptables-save.

Then add this line to /etc/network/interfaces under the eth0 block:

Step 4: Client Generation

Never share certificates between users. If a laptop is stolen, you want to revoke just that one certificate, not rebuild your whole PKI. Generate a client key:

You will need to securely transfer ca.crt, client1.crt, and client1.key to your client machine.

Performance: The Norwegian Advantage

Why host this in Norway? Latency and law.

If your team is in Oslo, Stavanger, or Trondheim, routing your encrypted traffic through a server in Germany or the US adds unnecessary milliseconds. CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange). The round-trip time (RTT) from your home DSL to our datacenter is often single-digit milliseconds. This makes the VPN feel invisible.

Furthermore, data stored here falls under the jurisdiction of the Datatilsynet. We are not subject to the same broad surveillance sweeps found in other jurisdictions. Your data remains your data.

Start the Engine

Fire it up using the init script:

Check the logs at /var/log/syslog. You should see `Initialization Sequence Completed`.

In an era where packet sniffing tools like Wireshark are available to any script kiddie, an unencrypted connection is a liability. By combining the raw power of KVM virtualization with the security of OpenVPN, you create a fortress that follows you everywhere.

Ready to secure your communications? Deploy a KVM VPS with CoolVDS today and get full root access in under 2 minutes.