Ein nicht ganz objektiver Vergleich von VPN-Varianten

…die uns in pfSense® & OPNsense® zur Verfügung stehen

Willkommen zurück zum zweiten Artikel unserer Kategorie Netzwerk & Firewall.
Wir starten ins Jahr 2026 direkt mit einem kleinen Vergleich an VPN-Varianten, die uns auf unseren beiden Firewall-Projekten zur Verfügung stehen.

Warum aber das „nicht ganz objektiv“ im Titel?
Nun, weil man bei der Planung einer VPN-Verbindung immer diverse Rahmenbedingungen berücksichtigen muss und man deshalb gewisse Vorgaben hat. Daher kann man selten eine Entscheidung nach eigenem Gusto treffen, sondern ist in vielen Fällen auf die Gegebenheiten der VPN-Gegenstelle beschränkt.

Natürlich gibt es auch die Variante, dass man alles völlig frei entscheiden kann und alle Parteien selbst festlegen kann. Trotzdem betrachten wir jetzt einmal nur die drei VPN-Varianten, die aktuell am häufigsten Einsatz finden, sowie Varianten, die diese als Basis nutzen. Speziellere Tools wie beispielsweise tinc, stunnel oder sslh lassen wir hier zunächst außen vor.

IPsec vs. OpenVPN vs. WireGuard

Die wohl bekannteste Dreifaltigkeit der VPN-Szene besteht derzeit aus IPsec als Internet-Urgestein, OpenVPN und WireGuard als jüngstem Spross.
Schauen wir uns also an, was diese drei vereint und was ihre Unterschiede sind.

IPsec

IPsec existiert seit 1996 und ist damit der Oldie unter den VPNs. Das inzwischen häufig obsolete IKEv1-Verfahren reicht dabei am weitesten zurück, wurde aber später durch IKEv2 abgelöst.

Für die Verschlüsselung steht eine moderate Palette an Algorithmen, Hashes und DH-Gruppen für beide Phasen der Verbindung zur Verfügung. Neben dem klassischen Transport-Mode für die zweite Phase kann IPsec mit einem VTI-Tunnel auch echtes Routing anbieten, worauf dann mit Protokollen wie BGP oder OSPF aufgebaut werden kann.

Zusätzlich kann IPsec auch als Einwahl-VPN genutzt werden und hat hier durch sein Alter und den Status als IETF-Standard den Vorteil, dass es in vielen Betriebssystemen direkt integriert ist.

Eine IPsec-Verbindung ist häufig auf die UDP-Ports 500 bzw. 4500 sowie 1701 (bei L2TP) festgelegt. Zusätzlich werden je nach Setup noch die Protokolle ESP oder AH benötigt. Bei IPsec-Tunneln sind die beiden Seiten theoretisch gleichberechtigt, die Verbindung kann von jeder Seite aus initiiert werden. Es gibt keine dedizierte Server⁠-⁠Seite, auch wenn man dies konfigurieren könnte, indem auf einer Seite der Remote-Partner nicht spezifiziert wird.

OpenVPN

OpenVPN ist fünf Jahre jünger als IPsec und startete erst 2001, wird also im Mai dieses Jahres sein stolzes 25-jähriges Jubiläum feiern.
Im Gegensatz zu IPsec baut OpenVPN auf der OpenSSL-Bibliothek auf und kann damit alle Cipher-Kombinationen nutzen, die OpenSSL zur Verfügung stellt.

Anders als IPsec kann OpenVPN einen VPN-Tunnel sowohl als Layer-2-Bridge als auch als Layer-3-Tunnel verwenden. Ein Policy-Routing wie beim IPsec-Transport findet hier nicht statt, denn es wird alles geroutet.

Ebenso wie IPsec kann OpenVPN als Einwahl-VPN für Clients konfiguriert werden, ist allerdings oftmals nicht direkt in Betriebssystemen enthalten und benötigt die Installation einer zusätzlichen Client-Applikation.

OpenVPN nutzt als bekanntesten Port den UDP-Port 1194, kann aber grundsätzlich auf einem beliebigen UDP-Port konfiguriert werden. Zusätzlich dazu unterstützt OpenVPN auch das Tunneln via TCP und kann somit auch über einen TCP-Port betrieben werden. Mehr als dieser eine Port ist für den Verbindungsaufbau nicht notwendig.

Allerdings nutzt OpenVPN ein striktes Client-Server⁠-⁠Prinzip. Bei einer Tunnelverbindung ist eine Seite dediziert der Server, die andere der Client und dieser baut die Verbindung zum Server auf.

WireGuard

WireGuard ist das jüngste VPN im Vergleich.
Im Jahr 2015 initial gestartet, war die Prämisse, ein neues, sicheres VPN zu schaffen, das keine komplexe Konfiguration erfordert, kryptografisch sicher ist und eine geringere Angriffsfläche als die vorhandenen Lösungen bietet – und das möglichst performant.

Aus diesem Grund ist die Konfiguration von WireGuard deutlich kompakter als bei IPsec oder OpenVPN. Es gibt keine Auswahl von Verschlüsselungsmethoden, Ciphers, Hashes oder Keygroups. WireGuard nutzt stattdessen eine fest definierte Kombination moderner Frameworks (Noise), Kryptokurven (Curve25519), Cipher und Hashes.

Um eine möglichst hohe Performance zu erreichen, setzt auch WireGuard auf UDP als Transportprotokoll und nutzt standardmäßig den Port 51820, kann aber ebenfalls auf beliebigen UDP-Ports betrieben werden.

Statt Zertifikaten, HMACs oder PSKs kommt hier zur Verifikation der Gegenseite ein Cryptokey-Verfahren zum Einsatz, das ähnlich wie PGP/GPG funktioniert. Jede Seite besitzt ein Schlüsselpaar aus privatem und öffentlichem Schlüssel, wobei die öffentlichen Schlüssel gegenseitig ausgetauscht werden, um die Peers zu authentifizieren. Optional kann die Verbindung zusätzlich durch einen PSK abgesichert werden.

Port, IPs oder Hostnamen der Gegenstelle sowie die zu routenden Netze – und die Konfiguration für einen Site-to-Site-Tunnel ist fast schon fertig.
Ähnlich wie OpenVPN wird WireGuard jedoch oftmals nicht nativ vom Betriebssystem unterstützt, sodass für Einwahl-VPNs meist ein zusätzlicher Client erforderlich ist.

…nicht ganz objektiver Vergleich?

Nun kennen wir die drei VPN-Varianten, die aktuell am häufigsten eingesetzt werden.
Aber wo liegen die Probleme? Und gibt es vielleicht doch einen eindeutigen Gewinner?

Wie so oft lautet die Antwort: „Kommt darauf an…“

IPsec – Standard mit Sternchen?

IPsec arbeitet bei den meisten Systemen im Kernelspace und nicht wie OpenVPN im Userspace. Dadurch kann IPsec bei Performance und Durchsatz punkten.
Als Standard, der überall vorhanden ist, klingt das zunächst wie ein Traum. In der Praxis ist es jedoch häufig eher ein Albtraum.

Denn IPsec mag zwar standardisiert sein, doch da man auf die Gegenstelle angewiesen ist, was tatsächlich gefordert, unterstützt und verwendet wird, artet der Aufbau eines Tunnels häufig in ein Tabellenkalkulations-Drama aus. Große Excel-Sheets werden hin- und hergeschickt, in denen jede Seite eintragen soll, welche Hardware eingesetzt wird, welche IPs oder Hostnamen genutzt werden, welche IKE⁠-⁠Verfahren, Cipher, Hashes und DH-Gruppen unterstützt werden und so weiter.

Am Ende findet man hoffentlich einen gemeinsamen Nenner.

Mit pfSense & OPNsense haben wir immerhin den Vorteil, dass der verwendete IPsec-Service nahezu alle aktuell sicheren Verfahren unterstützt. Meist können wir daher schlicht antworten: „Bitte tragt eure besten Einstellungen ein.“

Dennoch erinnert IPsec hier stark an VoIP/SIP: Ein Standard, der existiert, bei dem man aber nie genau weiß, welche Teile davon die Gegenstelle tatsächlich implementiert hat.
Die Aussage „Gegenseite unterstützt IPsec“ bedeutet noch lange nicht, dass es am Ende auch wirklich funktioniert.

Hinzu kommt, dass man aus Sicht der Open-Source-Community häufig den Eindruck gewinnt, dass manche Hersteller moderne Crypto-Einstellungen nur sehr zögerlich einführen oder ihre Geräte nicht ausreichend aktualisieren. Das führt dazu, dass wir selbst 2025 noch mit IKEv1-Verbindungen und Gegenstellen ohne Support für moderne AEAD-Cipher wie AES-GCM oder ChaCha20 kämpfen müssen, was CPU und Crypto-Hardware unnötig belastet.

Ähnlich unerquicklich gestaltet sich das Thema Einwahl-Clients. Die Konfiguration gleicht oft einem Puzzlespiel:
Funktionieren Windows- und macOS-Clients, scheitern plötzlich Android-Geräte. Funktioniert iOS, fallen Windows-Clients wieder heraus. Ein universelles Setup ist unnötig schwer zu erreichen und endet meist in sicherheitstechnischen Kompromissen.

OpenVPN – Rettung mit eigenen Problemen?

Es gibt gute Gründe, warum OpenVPN gerade für Einwahl-Clients und später auch für Site-to-Site-Tunnel populär wurde. Das IPsec-Puzzle entfällt, da OpenVPN ohnehin eine eigene Client-Applikation benötigt und damit auf nahezu allen Plattformen eine weitgehend einheitliche Konfiguration ermöglicht.

Natürlich gibt es auch hier kleinere Fallstricke, etwa Parameter, die in bestimmten Clients (z. B. in den offiziellen iOS- oder Android-Apps) Probleme verursachen. Diese lassen sich jedoch meist durch die sehr flexible Server⁠-⁠Konfiguration umgehen oder client-spezifisch lösen.

Wie IPsec authentifiziert auch OpenVPN Einwahl-Clients per Benutzername und Passwort, kann jedoch zusätzlich Zertifikate, MFA-Mechanismen oder TOTP-Einmalcodes integrieren, was einen klarer Vorteil darstellt.

Bei Tunneln zwischen Netzen kann es jedoch erneut komplex werden. Hier spielt die eingesetzte OpenVPN-Version der Gegenstelle eine entscheidende Rolle. Besonders bei Mobil-Routern oder Industrie-Komponenten erleben wir häufig, dass zwar OpenVPN beworben wird, aber keinerlei Einblick in Version oder Konfiguration möglich ist.

Ein Beispiel aus der Praxis:
Ein LTE⁠-⁠Router warb mit OpenVPN 2.6, erzeugte intern jedoch Konfigurationen im Stil von OpenVPN 2.4, die gar nicht starten konnten. Erst nach manuellem Eingriff per Shell funktionierte die Verbindung. Jede Änderung über die GUI zerstörte das Setup erneut. Solche Erfahrungen lassen OpenVPN unnötig kompliziert erscheinen. Doch das wir dem Projekt nicht gerecht.

Gerade mit OpenVPN 2.6 und der Einführung von DCO (Data-Channel Offloading) hat sich viel getan. Der Daten- und Crypto-Pfad wurde in den Kernel verlagert, wodurch OpenVPN-Tunnel heute performance-seitig auf Augenhöhe mit IPsec und WireGuard liegen. Viele Aussagen über langsames OpenVPN basieren schlicht auf veralteten Setups.

WireGuard – der Retter des VPNs?

WireGuard überzeugt durch seine kompakte Konfiguration, geringe Fehleranfälligkeit und hohe Performance. Besonders für einfache Setups oder Einwahl-VPNs punktet es mit Komfort, etwa durch QR-Code-Importe für Clients.

Allerdings zeigt sich in größeren Umgebungen schnell die Kehrseite: WireGuard ist nicht an Interfaces gebunden, sondern lauscht lediglich auf einem Port. In Cluster-Setups führt das zu Problemen bei Failover-Szenarien, da WireGuard nicht sauber mit virtuellen IPs arbeitet. Auch Multi-WAN-Umgebungen lassen sich nur mit Workarounds abbilden.

Hinzu kommen funktionale Einschränkungen:
WireGuard authentifiziert Geräte, nicht Benutzer. Es gibt keine native MFA-Unterstützung, kein LDAP oder AD-SSO, keine sauberen Verbindungslogs und keine Benutzer-Sessions. Auch ein TCP-Fallback existiert nicht, da WireGuard ausschließlich UDP nutzt.

Nicht zuletzt ist WireGuard kryptografisch stark festgelegt. Sollte es hier jemals ein Problem geben, müssten sämtliche beteiligten Komponenten wie Firewalls, Clients und Router aktualisiert werden. In bestimmten Industrie- oder Embedded-Szenarien kann das problematisch sein.

Gewinner?

Einen klaren Gewinner gibt es nicht. und das ist auch gut so.
Wie man also sieht, das „Kommt darauf an…!“ war hier absolut berechtigt.
Alle drei VPN-Varianten sind weiterhin relevant. Performance ist heute kaum noch ein ausschlaggebendes Argument. Entscheidend sind vielmehr Umgebung, Anforderungen und Gegenstellen.

Aber: Gibt es nicht zumindest für die Client-Einwahl noch eine bessere Idee? Tatsächlich ja!

VPN-Overlay-Netze

Für Client-Einwahl gibt es mittlerweile eine spannende Alternative: VPN-Overlay-Netze.
Lösungen wie NetBird oder Tailscale bauen auf WireGuard auf, erweitern dieses jedoch um eine Control-Plane, Benutzer-Identitäten, MFA, Logging und feingranulare Zugriffskontrolle.

Die Anmeldung erfolgt über einen Identity Provider, Geräte lassen sich Benutzern zuordnen, Zugriffe können auf Dienste statt auf ganze Netze beschränkt werden. Zero-Trust-Ansätze lassen sich so praxisnah umsetzen – inklusive API-Anbindung und Automatisierung.

Über unsere Erfahrung und Eigenentwicklung auf Basis von NetBird können Sie hier nachlesen (auf Englisch)

Fazit

Für VPN-Tunnel gibt es nach wie vor verschiedene Möglichkeiten, die alle ihre Daseinsberechtigung haben. Die Performance ist inzwischen in vielen Fällen kein Entscheidungskriterium mehr, da sich IPsec, OpenVPN mit DCO und Wireguard hier kaum etwas schenken. Ausschlaggebend dafür, was man einsetzen kann, sind am Ende die Systemumgebung, die Netzstruktur sowie die Gegenstelle. Für die Client-Einwahl gibt es neben OpenVPN dank WireGuard und Overlay-Netzen inzwischen wirklich erstaunliche und vielfältige Möglichkeiten mit Potenzial, die Sicherheit weiter zu verbessern.

Wenn Sie nach unserem Erfahrungsbericht Interesse oder Fragen dazu haben, wie Sie VPN-Lösungen oder NetBird in Ihrer eigenen Netzwelt unterbringen können: Melden Sie sich gern bei uns!