9 December 2006Own project · NetworksOwn post

OpenVPN over Wi-Fi: a 266 MHz router at full load

Summary

In December 2006 I tested how much my home-built router based on a WRAP board could handle when the Wi-Fi was secured only by OpenVPN. With AES-256, OpenVPN used about 90 percent of the 266 MHz CPU and throughput averaged around 800 kB/s. This post from my old blog shows the measurement, why a small computer hit its limit here and how WireGuard and kernel offload solve the problem today.

The setup

My router was a WRAP board running Debian with three network ports: eth0 to the DSL modem via PPPoE, eth1 to the internal LAN, eth2 for Wi-Fi and DMZ. eth2 was connected to a simple router that only provided an open Wi-Fi network. This link was encrypted by OpenVPN alone; its server ran on the WRAP.

There was a lot to be said for such a setup at the time: WEP had been considered broken since 2001, WPA2 had not yet reached every device, and OpenVPN encrypted with proven methods on every device that ran the client. The price: every packet from the Wi-Fi had to pass through the router’s small CPU.

The test

For the measurement I connected a notebook to the Wi-Fi, set up the tunnel and pushed large files to the computer on the LAN. The OpenVPN configuration used the maximum that was common in 2006:

# /etc/openvpn/openvpn.conf (Auszug)
dh /etc/openvpn/zertifikate/dh2048.pem
cipher AES-256-CBC
comp-lzo

After a short while, top on the board looked like this (shortened):

top - 01:04:12 up 97 days, 12:52,  1 user,  load average: 1.03, 1.12, 1.22
Cpu(s): 47.5% us, 20.3% sy, 0.0% ni, 0.0% id, 0.0% wa, 3.6% hi, 28.5% si
Mem:    127028k total,   122356k used,     4672k free

  PID USER      %CPU %MEM COMMAND
10790 nobody    90.4  1.9 openvpn
31225 debian-t   5.6  6.8 tor
13402 root       2.0  0.6 syslogd

What the numbers show

OpenVPN alone used over 90 percent of the CPU, and idle time was zero. The 28.5 percent for softirqs stands out: a large part of the computing time went not into encryption itself but into packet processing in the kernel. At that time OpenVPN ran entirely in user space; every packet travelled from the kernel to OpenVPN, was encrypted there and went back into the kernel.

On average about 800 kB/s got through the tunnel, enough for small amounts of data but nothing compared to the speed of the LAN. The statistics showed peaks of 329 kB/s in and 531 kB/s out. The CPU warmed up to 52 °C and stayed there. Alongside, the same board was running a Tor node, Privoxy, Samba, dnsmasq and the SNMP service, and the device had been up for 97 days without a reboot.

The crypto card I did not need

One remedy was obvious at the time: Mini-PCI cards like the Soekris vpn1411 with a Hifn 7955 chip handled AES in hardware, according to vendor figures at several hundred Mbit/s. For a few clients that seemed unnecessary to me, and in hindsight that was probably right. Later reports from the pfSense community show that OpenVPN gained little from such cards: copying data back and forth between kernel and user space ate up the benefit again. With IPsec, which runs in the kernel, the card helped noticeably.

What has changed since

Today I would secure such a network differently. WPA2 and WPA3 make an extra VPN for your own Wi-Fi mostly unnecessary. For tunnels on the road, WireGuard has been in the kernel since Linux 5.6; it works with a few fixed methods and avoids exactly the detour through user space that ate the CPU in 2006. With version 2.6 from 2023, OpenVPN got Data Channel Offload, which moves encryption of the payload into the kernel.

Two settings from back then should not be copied: AES-256-GCM has replaced AES-256-CBC as the default, and comp-lzo is obsolete because compression before encryption can leak information about the content. What remains: modern routers have AES instructions in the CPU, and a load test with top and a large file still shows in five minutes where the bottleneck is.

Numbers at a glance

WRAP board with a 266 MHz Geode CPU and 128 MB RAM, 97 days of uptime at the time of the test.
OpenVPN with AES-256-CBC and comp-lzo used 90.4 percent CPU, plus 28.5 percent softirq load.
Average throughput about 800 kB/s, peaks 329 kB/s in and 531 kB/s out, CPU temperature 52 °C.
WireGuard has been in the kernel since Linux 5.6; OpenVPN 2.6 brings Data Channel Offload.

References

Remarks

This post was originally published on 9 December 2006 in my old Plone blog. In 2026 I retrieved it from the Web Archive, revised it and added context. Measurements and configuration are those of the time; the graphs and photos have not survived.
The “average 800 kB/s” and the peaks from the statistics come from different measurement windows and therefore do not match exactly.

Original post in the Web Archive