Paranoia is a Virtue: Building a Bulletproof OpenVPN Gateway on CentOS 6 in Norway

Let’s be honest: if you are connecting to your production servers via the coffee shop Wi-Fi without a tunnel, you deserve to get hacked. Ever since Firesheep dropped in 2010, session hijacking has become script-kiddie play. But here is the problem: most commercial VPN services are garbage. They route your traffic through oversubscribed nodes, throttle your bandwidth, or worse—they log your data in jurisdictions where privacy is a suggestion, not a law.

As a sysadmin, I don't trust black boxes. I trust iptables, RSA keys, and servers I control. If you are operating in Europe, you need data sovereignty. You need your encrypted tunnel to terminate in a jurisdiction that respects the individual.

That jurisdiction is Norway. And the tool is OpenVPN.

Today, we are going to build a dedicated VPN gateway on CentOS 6 using OpenVPN 2.2. We will cover the Public Key Infrastructure (PKI) setup, routing tables, and why the underlying virtualization technology of your VPS provider determines if this setup even works.

Why Norway? (Latency and Law)

Location matters. If your development team is in Oslo, Bergen, or even London, routing your encrypted traffic through a US-based server adds 150ms of latency. That makes SSH sessions sluggish and agonizing. You want a termination point close to the NIX (Norwegian Internet Exchange).

More importantly, we have the Personopplysningsloven (Personal Data Act). Unlike the US Patriot Act, which allows broad surveillance, Norwegian law—enforced by Datatilsynet—puts heavy restrictions on data access. By hosting your own VPN node on Norwegian soil, you ensure that your traffic remains under European protective directives (95/46/EC) rather than being swept up in NSA dragnets.

The Prerequisite: TUN/TAP and Virtualization

Here is where most people fail before they start. OpenVPN requires the TUN/TAP kernel module to create virtual network devices. On cheap, oversold OpenVZ containers, providers often disable this module or fail to provision it correctly. You try to start the service, and you get:

Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory

To avoid this headache, I stick to KVM-based virtualization. It gives you a full kernel. At CoolVDS, we use KVM by default, meaning you have complete control over kernel modules and iptables without begging support to flip a switch for you.

Step 1: Installing the Repository and Software

We are using CentOS 6.2 (Standard). The stock repositories are too conservative, so we need EPEL (Extra Packages for Enterprise Linux).

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
yum update -y
yum install openvpn easy-rsa -y

Pro Tip: Always verify the GPG keys when installing third-party repositories. Man-in-the-middle attacks aren't just for browsers.

Step 2: Building the PKI (Public Key Infrastructure)

We are not using static keys; they don't provide Perfect Forward Secrecy. We are building a proper Certificate Authority (CA). Copy the easy-rsa scripts to a clean directory so updates don't wipe your changes.

mkdir -p /etc/openvpn/easy-rsa/2.0
cp -r /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa/2.0/
cd /etc/openvpn/easy-rsa/2.0

Edit the vars file. This saves you from typing your country and organization fifty times. Increase the key size to 2048 bits while you are at it—1024 is technically cracked if you have nation-state resources.

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

Now, build the CA and the server certificate.

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

This will generate the Diffie-Hellman parameters. It takes time. On a standard VPS, entropy generation can be slow. Since CoolVDS runs on high-performance enterprise hardware, this usually finishes in seconds, but be patient.

Step 3: Configuring the Server

Create the config file at /etc/openvpn/server.conf. We are going to use UDP because TCP-over-TCP leads to meltdown when packet loss occurs.

port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh2048.pem

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

# Push routes to the client to send all traffic through the VPN
push "redirect-gateway def1 bypass-dhcp"

# Use Google DNS or your own local caching resolver
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: Routing and Firewalls

This is the part that breaks connectivity if you miss it. You need to 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 to masquerade traffic from the VPN subnet (10.8.0.0/24) to the internet interface (usually eth0). Without this, your packets hit the internet with a private IP and get dropped instantly.

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

Warning: If you have a restrictive firewall policy (which you should), ensure you OPEN port 1194 UDP on the INPUT chain.

Step 5: Client Configuration

Now generate a key for your laptop:

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

Transfer ca.crt, client-laptop.crt, and client-laptop.key to your local machine securely (use SCP, not email!). Create a client.ovpn file:

client
dev tun
proto udp
remote [YOUR_COOLVDS_IP] 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client-laptop.crt
key client-laptop.key
comp-lzo
verb 3

Performance Considerations

Encryption costs CPU cycles. The default Blowfish cipher is decent, but if you are pushing massive throughput, you will see your CPU usage spike. This is why underlying hardware matters.

We have seen “budget” VPS providers throttle CPU specifically on encrypted traffic because it looks like high load. At CoolVDS, we don't play those games. Our nodes use enterprise-grade Intel Xeons with AES instruction sets that handle encryption math natively. Combined with our SSD-backed storage, the bottleneck will be your coffee shop Wi-Fi, not our infrastructure.

Final Thoughts

Setting up your own VPN isn't just about accessing Netflix from a different region; it's about securing your administrative workflow. By placing your exit node in Norway, you gain the benefit of robust privacy laws and low latency across Northern Europe.

Don't leave your security to a "free" VPN service that's monetizing your metadata. Deploy a KVM instance, configure OpenVPN, and own your pipe.

Ready to lock down your connection? Spin up a CoolVDS KVM instance in Oslo today—provisioning takes less than 60 seconds.