Console Login

Bulletproof Your Remote Access: Building a Hardened OpenVPN Gateway on Linux (2009 Edition)

Stop Leaking Data: The Case for a Private VPN Gateway

It is 2009, yet I still see seasoned sysadmins logging into critical infrastructure via unencrypted FTP or HTTP over coffee shop WiFi. With tools like Firesheep and Wireshark becoming increasingly accessible to script kiddies, relying on "security through obscurity" is professional suicide. If you are managing servers or accessing sensitive client data while roaming, you need an encrypted tunnel. Period.

Commercial VPN services are often overloaded, capping your bandwidth and routing your traffic through high-latency nodes in the US or Germany. For Norwegian professionals, this adds unacceptable lag to SSH sessions. The solution? Roll your own OpenVPN endpoint on a high-performance VPS located right here in Oslo.

The Architecture: Why Latency Matters

When you tunnel TCP over TCP (which happens if you use SSH inside a TCP-based VPN), you encounter the "TCP meltdown" problem during packet loss. This is why we stick strictly to UDP for the tunnel transport layer. Furthermore, physical distance is the enemy of throughput.

Hosting your VPN on a CoolVDS instance peering directly at NIX (Norwegian Internet Exchange) ensures your round-trip time (RTT) remains in the single digits within Norway. We aren't talking about standard shared hosting here; we are talking about dedicated slices of SAS RAID10 storage and guaranteed CPU cycles that don't get stolen by noisy neighbors.

Step 1: The Environment

We will use CentOS 5.4 (32-bit or 64-bit) for this deployment. It is battle-tested, stable, and the standard for enterprise deployments.

Pro Tip for VPS Users: Before you begin, verify that your kernel supports the TUN/TAP driver. On many budget providers using old OpenVZ kernels, this is disabled. On CoolVDS, we enable TUN/TAP and IPTables modules by default on all instances.

Check your TUN/TAP status:

cat /dev/net/tun

If you see File descriptor in bad state, you are good to go. If you see No such device, submit a ticket to your host immediately.

Step 2: Installing OpenVPN 2.1

The standard repositories don't always carry the latest stable OpenVPN. We will use the EPEL (Extra Packages for Enterprise Linux) repository to fetch OpenVPN 2.1.

# Install EPEL repository rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-3.noarch.rpm # Install OpenVPN yum install openvpn -y

Step 3: Public Key Infrastructure (PKI) Setup

OpenVPN relies on OpenSSL for encryption. We need to generate a Certificate Authority (CA), a server certificate, and client keys. Copy the `easy-rsa` scripts to a safe working directory to avoid overwriting updates.

cp -R /usr/share/openvpn/easy-rsa/2.0 /etc/openvpn/easy-rsa cd /etc/openvpn/easy-rsa

Edit the vars file to reflect your organization. This is crucial for compliance with the Personopplysningsloven (Personal Data Act) if you are identifying employees.

export KEY_COUNTRY="NO" export KEY_PROVINCE="Oslo" export KEY_CITY="Oslo" export KEY_ORG="CoolVDS_Hosting" export KEY_EMAIL="admin@coolvds.no"

Now, build the PKI:

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

This process generates your Diffie-Hellman parameters. On a standard VPS, this might take a minute. On our high-clock speed instances, it flies.

Step 4: Server Configuration

Create the file /etc/openvpn/server.conf. We will use Blowfish-CBC (the current default) for speed, though AES-256 is an option if you have CPU cycles to burn.


port 1194
proto udp
dev tun

# Certificates
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

# Network Topology
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

# Route all traffic through the VPN
push "redirect-gateway def1"

# Use OpenDNS (prevents DNS leaks)
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

# Security settings
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Step 5: Routing and Firewalls

The VPN allows you to connect to the server, but to browse the internet through it, we need NAT. First, enable IP forwarding.

sysctl -w net.ipv4.ip_forward=1 sed -i 's/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/' /etc/sysctl.conf

Next, configure iptables to masquerade traffic coming from the VPN subnet (10.8.0.0/24) out to the internet interface (usually venet0 or eth0).

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

Step 6: Client Configuration

Generate a key for your laptop:

./build-key laptop-01

Transfer the `.crt`, `.key`, and `ca.crt` files securely (use SCP, not email!) to your client machine. Your client config (`client.ovpn`) should match the protocols defined above:


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

Why Infrastructure Choice Matters

You can configure the software perfectly, but if the underlying host is oversold, your VPN packet jitter will make VoIP calls or SSH sessions unbearable. OpenVPN is CPU-intensive when encrypting high-bandwidth streams.

At CoolVDS, we utilize high-performance SAS RAID arrays and maintain strict density limits per node. Whether you are complying with the Data Inspectorate's requirements for data residency or just want to watch NRK while traveling abroad, physical location and hardware quality are the differentiators.

Next Steps

Start the service with service openvpn start and ensure it runs on boot with chkconfig openvpn on. Don't leave your digital footprint exposed. Spin up a secure, low-latency VPS instance today and own your connection.