9. Dezember 2006Eigenes Projekt · NetzwerkeEigener Beitrag

OpenVPN über WLAN: Ein 266-MHz-Router unter Volllast

Zusammenfassung

Im Dezember 2006 habe ich getestet, wie viel mein selbst gebauter Router auf Basis eines WRAP-Boards schafft, wenn das WLAN nur über OpenVPN gesichert ist. Bei AES-256 belegte OpenVPN rund 90 Prozent der 266-MHz-CPU, der Durchsatz lag im Mittel bei etwa 800 kB/s. Dieser Beitrag aus meinem alten Blog zeigt die Messung, warum ein Kleinrechner hier an seine Grenze kam und wie WireGuard und Kernel-Offload das Problem heute lösen.

Der Aufbau

Mein Router war ein WRAP-Board mit Debian und drei Netzwerkanschlüssen: eth0 zum DSL-Modem per PPPoE, eth1 ins interne LAN, eth2 für WLAN und DMZ. An eth2 hing ein einfacher Router, der nur ein offenes WLAN aufspannte. Verschlüsselt war diese Strecke allein durch OpenVPN; der Server dafür lief auf dem WRAP.

Für so einen Aufbau sprach damals einiges: WEP galt seit 2001 als gebrochen, WPA2 war noch nicht in allen Geräten angekommen, und OpenVPN verschlüsselte mit geprüften Verfahren auf jedem Gerät, auf dem der Client lief. Der Preis: Jedes Paket aus dem WLAN musste durch die kleine CPU des Routers.

Der Test

Für die Messung habe ich ein Notebook ins WLAN gehängt, den Tunnel aufgebaut und große Dateien auf den Rechner im LAN geschoben. Die OpenVPN-Konfiguration nutzte das Maximum dessen, was 2006 üblich war:

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

Nach kurzer Zeit sah top auf dem Board so aus (gekürzt):

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

Was die Zahlen zeigen

OpenVPN allein belegte über 90 Prozent der CPU, die Leerlaufzeit lag bei null. Auffällig sind die 28,5 Prozent für Softirqs: Ein großer Teil der Rechenzeit ging nicht in die Verschlüsselung selbst, sondern in die Paketverarbeitung im Kernel. OpenVPN lief in dieser Zeit komplett im Userspace; jedes Paket wanderte vom Kernel zu OpenVPN, wurde dort verschlüsselt und ging zurück in den Kernel.

Im Schnitt kamen rund 800 kB/s durch den Tunnel, ausreichend für kleine Datenmengen, aber kein Vergleich zur Geschwindigkeit des LAN. Die Statistik zeigte Spitzen von 329 kB/s herein und 531 kB/s hinaus. Die CPU erwärmte sich auf 52 °C und blieb dort. Nebenbei liefen auf demselben Board noch ein Tor-Knoten, Privoxy, Samba, dnsmasq und der SNMP-Dienst, und das Gerät war seit 97 Tagen ohne Neustart in Betrieb.

Die Krypto-Karte, die ich nicht brauchte

Eine Abhilfe lag damals nahe: Mini-PCI-Karten wie die Soekris vpn1411 mit einem Hifn-7955-Chip übernahmen AES in Hardware, laut Herstellerangaben mit mehreren hundert Mbit/s. Für wenige Clients schien mir das unnötig, und im Nachhinein war das wohl richtig. Spätere Erfahrungsberichte aus dem pfSense-Umfeld zeigen, dass OpenVPN von solchen Karten wenig hatte: Das Hin- und Herkopieren der Daten zwischen Kernel und Userspace fraß den Gewinn wieder auf. Bei IPsec, das im Kernel läuft, half die Karte dagegen deutlich.

Was sich seitdem geändert hat

Heute würde ich ein solches Netz anders sichern. WPA2 und WPA3 machen ein zusätzliches VPN fürs eigene WLAN meist überflüssig. Für Tunnel zu unterwegs ist WireGuard seit Linux 5.6 im Kernel; es arbeitet mit wenigen, festen Verfahren und spart sich genau den Umweg über den Userspace, der 2006 die CPU auffraß. OpenVPN hat mit Version 2.6 von 2023 ein Data Channel Offload bekommen, das die Verschlüsselung der Nutzdaten in den Kernel verlegt.

Zwei Einstellungen von damals sollte man nicht mehr übernehmen: AES-256-CBC hat AES-256-GCM als Standard abgelöst, und comp-lzo ist überholt, weil Kompression vor der Verschlüsselung Rückschlüsse auf den Inhalt erlauben kann. Was geblieben ist: Moderne Router haben AES-Befehle in der CPU, und ein Lasttest mit top und einer großen Datei zeigt nach wie vor in fünf Minuten, wo der Engpass liegt.

Zahlen im Überblick

WRAP-Board mit 266-MHz-Geode-CPU und 128 MB RAM, 97 Tage Laufzeit zum Zeitpunkt des Tests.
OpenVPN mit AES-256-CBC und comp-lzo belegte 90,4 Prozent CPU, dazu 28,5 Prozent Softirq-Last.
Durchsatz im Mittel etwa 800 kB/s, Spitzen 329 kB/s herein und 531 kB/s hinaus, CPU-Temperatur 52 °C.
WireGuard ist seit Linux 5.6 im Kernel, OpenVPN 2.6 bringt Data Channel Offload.

Referenzen

Bemerkungen

Dieser Beitrag stand ursprünglich am 9. Dezember 2006 in meinem alten Plone-Blog. 2026 habe ich ihn aus dem Webarchiv geholt, überarbeitet und um die Einordnung ergänzt. Messwerte und Konfiguration sind die von damals; die Graphen und Fotos sind nicht erhalten.
Die Werte „im Mittel 800 kB/s“ und die Spitzen aus der Statistik stammen aus verschiedenen Messfenstern und passen deshalb nicht exakt zusammen.

Originalbeitrag im Webarchiv