Tunneling Through the Noise: A Hardened OpenVPN Setup on Debian Squeeze
Let’s be honest: if you are pushing code or logging into administrative backends from a coffee shop WiFi without a tunnel, you are asking for trouble. With tools like Firesheep making session hijacking trivial for any script kiddie, the days of trusting the transport layer are over.
Sure, you could use PPTP. It’s built into everything. It’s also fundamentally broken. MS-CHAPv2 has been cracked, and relying on it in 2011 is professional negligence. If you care about your data—and your clients' data—you need OpenVPN. It’s robust, it’s open source, and it utilizes OpenSSL for encryption.
But here is the catch: OpenVPN requires resources. It creates a userspace context switch for every packet. If you put this on a cheap, oversold box with high CPU steal time, your throughput will tank. You need a system with dedicated cycles and a clean pipe to NIX (Norwegian Internet Exchange).
The Architecture: Why Location Matters
Latency is the enemy of a good VPN experience. If you are in Oslo or Stockholm and you tunnel your traffic through a server in Texas, you are adding 150ms of latency to every handshake. That makes SSH sessions unbearable.
Furthermore, we have to talk about the elephant in the room: the USA PATRIOT Act. Data hosted on US soil (or by US companies) is subject to inspection without your consent. By hosting your endpoint in Norway, you fall under the jurisdiction of the Personopplysningsloven (Personal Data Act) enforced by Datatilsynet. It’s a matter of sovereignty as much as performance.
Prerequisites
- A VPS in Norway (Latency < 10ms preferred).
- Debian 6.0 (Squeeze) minimal install.
- Root access.
- TUN/TAP enabled.
Pro Tip: Many budget VPS providers use older OpenVZ kernels that disable the TUN/TAP device by default to save overhead. If `cat /dev/net/tun` returns a permission error, your provider is hamstringing you. CoolVDS enables TUN/TAP on all nodes by default because we know you need it.
Step 1: The Build
First, update your repositories. We want the stable release of OpenVPN.
apt-get update && apt-get upgrade
apt-get install openvpn chkconfig
We need to copy the easy-rsa scripts to generate our Public Key Infrastructure (PKI). Do not skip this. Pre-shared keys are for amateurs.
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
Edit the `vars` file. Increase the key size. The default 1024-bit is acceptable for now, but compute is getting cheaper. Future-proof yourself with 2048-bit keys.
export KEY_SIZE=2048
Run the build scripts:
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-key client1
./build-dh
This will generate your Diffie-Hellman parameters. It takes time. On a standard spinning disk VPS, this entropy generation can take forever. On CoolVDS SSD instances, the high I/O operations finish this in seconds. Time is money.
Step 2: Server Configuration
Create `/etc/openvpn/server.conf`. We are going to use UDP for speed (TCP over TCP leads to meltdown) and the `tun` device for routing.
port 1194
proto udp
dev tun
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/dh2048.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
Step 3: Network Address Translation (NAT)
The VPN is useless if traffic can't leave the server. We need to enable IP forwarding and configure `iptables`.
Edit `/etc/sysctl.conf`:
net.ipv4.ip_forward=1
Apply it with `sysctl -p`. Now, the firewall rules. This is where most admins fail. You must masquerade traffic leaving your physical interface (usually `eth0` or `venet0` on a VPS).
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
For managed hosting clients, we often configure a strict firewall that drops all non-VPN traffic. But for this setup, ensure port 1194 UDP is open.
Step 4: Client Side
Transfer `ca.crt`, `client1.crt`, and `client1.key` to your laptop securely (use SCP, not email). Install the OpenVPN GUI client. Your client config (`client.ovpn`) should match the server protocols:
client
dev tun
proto udp
remote [YOUR_COOLVDS_IP] 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
comp-lzo
verb 3
Performance vs. Security
Encryption costs CPU cycles. Using AES-256-CBC provides military-grade security but requires a processor capable of handling the math. Many budget hosts overload their physical nodes, resulting in "noisy neighbors" stealing your CPU time. This causes jitter in your VPN connection.
At CoolVDS, we isolate resources. Whether you are running a simple VPN or a complex database cluster, the CPU cycles you pay for are yours. Combined with our low latency connection to the major European hubs, you get a secure tunnel that feels like a local connection.
The Bottom Line
Data privacy in Europe is shifting. With the implementation of the Data Protection Directive, you are responsible for how you transmit client data. An unencrypted FTP session or an HTTP login over public WiFi is a compliance nightmare waiting to happen.
Don't risk it. Spin up a Debian instance, lock down your ports, and own your infrastructure. If you need a node that supports advanced iptables modules and TUN devices out of the box, we have capacity in our Oslo datacenter ready to go.
Ready to secure your traffic? Deploy a high-performance VPS Norway instance on CoolVDS today and get your tunnel running in under 5 minutes.