VPNs sind 2026 keine Frage des “ob”, sondern des “wie”. Remote-Arbeit, verteilte Standorte und externe Dienstleister verlangen verschlüsselte Verbindungen, die schnell, stabil und wartungsarm sind. Die beiden dominanten Open-Source-Protokolle bleiben WireGuard und OpenVPN — doch die Lücke zwischen beiden ist im Lauf der letzten Jahre deutlich grösser geworden.
Wir haben in unserem Testlabor in Neuburg beide Protokolle auf identischer Hardware gegeneinander antreten lassen und liefern Ihnen in diesem Artikel reproduzierbare Zahlen statt Marketing-Aussagen. Am Ende erfahren Sie, wann WireGuard die klare Wahl ist und in welchen Sonderfällen OpenVPN immer noch unverzichtbar bleibt.
Testaufbau: Hardware, Software und Methodik
Damit die Ergebnisse vergleichbar sind, haben wir auf beiden Seiten die gleiche Konfiguration gefahren. Als Gegenstellen kamen zwei OPNsense-Firewalls auf Supermicro-Hardware zum Einsatz, dazwischen ein 10-GbE-Switch ohne weitere Last.
| Komponente | Konfiguration |
|---|---|
| CPU | Intel Xeon E-2488 (8C/16T, 3,2 GHz) |
| RAM | 32 GB DDR5 ECC |
| NIC | Intel X710-DA2 (10 GbE SFP+) |
| Betriebssystem | OPNsense 26.1 (FreeBSD 14.2) |
| WireGuard | Kernel-Modul, Version 1.0.20251115 |
| OpenVPN | 2.6.12 mit DCO (Data Channel Offload) |
| Cipher | ChaCha20-Poly1305 (beide) |
| MTU | 1420 (WG), 1500 mit fragment 1400 (OVPN) |
| Messwerkzeug | iperf3 3.18, 60 Sekunden, je 5 Wiederholungen |
Die Latenz wurde parallel mit ping -i 0.2 über die Tunnelschnittstelle gemessen, die CPU-Last mit top -SH und vmstat 1. Alle Werte sind Mittelwerte aus fünf Läufen, Ausreisser wurden verworfen.
Durchsatz: Single-Stream und Multi-Stream
Der Single-Stream-Test ist die härteste Disziplin — er entscheidet sich an der Effizienz pro CPU-Kern. Hier zeigt sich der Vorteil des schlanken WireGuard-Codes (rund 4.000 Zeilen) gegenüber dem deutlich umfangreicheren OpenVPN-Stack besonders deutlich.
| Test | WireGuard | OpenVPN 2.6 + DCO | OpenVPN 2.6 ohne DCO |
|---|---|---|---|
| Single-Stream TCP | 9,32 Gbit/s | 7,84 Gbit/s | 1,91 Gbit/s |
| 4 parallele Streams | 9,41 Gbit/s | 9,18 Gbit/s | 3,62 Gbit/s |
| 16 parallele Streams | 9,42 Gbit/s | 9,29 Gbit/s | 5,84 Gbit/s |
| UDP 1500 MTU | 9,38 Gbit/s | 9,12 Gbit/s | 2,40 Gbit/s |
Zwei Erkenntnisse stechen hervor: Erstens hat OpenVPN mit dem in Version 2.6 standardmässig aktiven Data Channel Offload (DCO) massiv aufgeholt — ohne DCO ist OpenVPN heute schlicht nicht mehr konkurrenzfähig. Zweitens skaliert WireGuard bereits mit einem einzigen Stream nahezu am Wire-Speed der 10-GbE-Strecke. Für klassische Backup-Übertragungen oder NFS-Replikation zwischen zwei TrueNAS-Systemen ist das ein spürbarer Unterschied.
Latenz und Jitter
Niedrige Latenz ist im Alltag oft wichtiger als der reine Spitzendurchsatz — besonders bei VoIP, RDP-Sitzungen oder Datenbankreplikation. Wir haben die Round-Trip-Time mit 1000 ICMP-Paketen über jeden Tunnel gemessen.
| Metrik | WireGuard | OpenVPN 2.6 + DCO |
|---|---|---|
| RTT min | 0,21 ms | 0,38 ms |
| RTT avg | 0,27 ms | 0,52 ms |
| RTT max | 0,89 ms | 2,14 ms |
| Jitter (Stddev) | 0,04 ms | 0,21 ms |
| Paketverlust | 0,0 % | 0,0 % |
WireGuard liefert nicht nur eine niedrigere Durchschnittslatenz, sondern auch einen deutlich stabileren Jitter. Das liegt am Verzicht auf TLS-Handshake-Overhead und am Cookie-basierten DDoS-Schutz, der ohne State-Tracking auskommt. Für Standort-zu-Standort-Verbindungen mit Echtzeitanforderungen ist das ein klares Plus.
CPU-Last: Effizienz pro Watt
Wer 24/7-VPN-Gateways betreibt, schaut nicht nur auf die Gigabit-Zahl, sondern auch auf die Stromrechnung. Die CPU-Last bei 5 Gbit/s konstantem TCP-Traffic war eindeutig:
WireGuard: 12,4 % CPU-Last (verteilt auf 4 Kerne)
OpenVPN 2.6 DCO: 19,8 % CPU-Last (verteilt auf 4 Kerne)
OpenVPN klassisch: 78,3 % CPU-Last (Single-Core gesaettigt)
WireGuard arbeitet im Kernel und nutzt pro Peer einen eigenen Worker, der sauber über alle Kerne skaliert. OpenVPN profitiert mit DCO ebenfalls vom Kernel-Pfad, hat aber durch den OpenSSL-Stack weiterhin einen Overhead, der sich bei kleinen Paketen besonders auswirkt. Für SMB-Hardware mit Atom- oder N-Series-CPUs bedeutet das in der Praxis: WireGuard ermöglicht oft erst die volle Auslastung der Glasfaser-Anbindung.
Wann OpenVPN 2026 noch die richtige Wahl ist
Trotz aller Zahlen wäre es falsch, OpenVPN abzuschreiben. Es gibt klare Szenarien, in denen es weiterhin punktet:
- Legacy-Clients und MDM-Bestand: Ältere Endgeräte oder fest verbaute Industrie-Hardware unterstützen oft nur OpenVPN-Profile. Ein Wechsel würde Hardware-Tausch oder aufwändige Firmware-Updates bedeuten.
- TCP-443-Tunnel durch restriktive Firewalls: WireGuard nutzt ausschliesslich UDP. Wer aus Hotelnetzen oder Carrier-NAT-Umgebungen mit aggressivem Port-Filtering tunneln muss, ist mit OpenVPN über TCP/443 weiterhin im Vorteil. Tools wie
udp2rawkönnen WireGuard zwar kapseln, fügen aber Komplexität hinzu. - Feingranulare Benutzerverwaltung mit PKI: OpenVPN bringt eine vollständige Zertifikats-Infrastruktur mit Username-/Passwort-Authentifizierung, OTP-Integration und Revocation Lists mit. WireGuard kennt nur Public Keys — für klassische Roadwarrior-Setups mit hundert wechselnden Mitarbeitenden ist das umständlicher und erfordert ein zusätzliches Tool wie
wg-portaloderfirezone. - Compliance-Vorgaben mit X.509: Manche Branchen verlangen explizit X.509-Zertifikate — hier ist OpenVPN gesetzt.
Praxisempfehlung für SMB-Umgebungen
In 95 % aller Neuinstallationen, die wir 2026 ausrollen, fällt die Wahl auf WireGuard. Die Konfiguration ist kürzer, der Funktionsumfang ist bewusst klein gehalten, und das Kernel-Modul ist seit Linux 5.6 bzw. FreeBSD 13.2 fester Bestandteil des Betriebssystems. Ein vollständiger Site-to-Site-Tunnel sieht heute so aus:
# /etc/wireguard/wg0.conf -- Standort A
[Interface]
PrivateKey = QGV4YW1wbGVQcml2YXRlS2V5MTIzNDU2Nzg5MA==
Address = 10.99.0.1/30
ListenPort = 51820
PostUp = sysctl net.ipv4.ip_forward=1
[Peer]
PublicKey = QGV4YW1wbGVQdWJsaWNLZXlBQkNERUZHSElKS0w=
AllowedIPs = 10.99.0.2/32, 192.168.20.0/24
Endpoint = standort-b.example.de:51820
PersistentKeepalive = 25
Auf Linux-Servern reicht ein systemctl enable --now wg-quick@wg0, und der Tunnel steht. Für Roadwarrior empfehlen wir die Kombination aus WireGuard und einem Portal wie wg-portal oder direkt der OPNsense-eigenen Verwaltung — das löst die Schlüssel- und Benutzerverwaltung sauber. Backup-Strecken zwischen zwei TrueNAS-Systemen profitieren am stärksten vom Durchsatzgewinn und sollten ohnehin auf WireGuard migriert werden.
Fazit
Die 2026er-Zahlen sind eindeutig: WireGuard ist schneller, latenzärmer und sparsamer. OpenVPN 2.6 mit DCO hat sich beachtlich gesteigert, bleibt aber durch seinen historischen Ballast langsamer und komplexer. Für neue Deployments ist WireGuard die Standardwahl — für Bestandsumgebungen mit Compliance-, Legacy- oder NAT-Sonderfällen bleibt OpenVPN ein verlässlicher Partner. Häufig sieht die Realität in mittelständischen Netzen so aus, dass beide Protokolle parallel betrieben werden: WireGuard für Standortkopplungen und moderne Clients, OpenVPN als Fallback für problematische Netze.
DATAZONE unterstützt Sie bei Konzeption, Aufbau und Migration Ihrer VPN-Infrastruktur — von der Auswahl der passenden Firewall-Hardware über die Integration in Ihre OPNsense-Umgebung bis zur abgesicherten Anbindung Ihrer Aussenstellen. Sprechen Sie uns an, wenn Sie Ihre VPN-Landschaft auf den Stand 2026 bringen möchten: Kontakt zu DATAZONE.
Weitere Artikel
OPNsense VLAN-Routing: 6 Best Practices für Mittelstands-Netze
OPNsense VLAN-Routing richtig planen: Management-Isolation, DHCP per VLAN, Default-Deny, MAC-Tracking, Unbound-Views und IoT-Segmentierung im Detail.
OPNsense DynDNS via Cloudflare API: dynamische Public IP automatisieren
OPNsense DynDNS mit Cloudflare API: os-ddclient Plugin, scoped API Token, Multi-WAN, niedrige TTL und schnelle DNS-Propagation für SMB-Netzwerke.
Home-Office-IT: Mitarbeiter sicher anbinden
Sicheres Home-Office im KMU: VPN mit OPNsense, MDM, RDP-Gateway, Vaultwarden, MFA mit Yubikey. Konfigurations-Blueprint vom Notebook über VPN bis zur Terminal-Session.