IKEv2 VPN (Internet Key Exchange Version 2) ist ein VPN-Protokoll, das auf IPsec basiert. Heute gehört es zu den bekanntesten – und unter Fachleuten – umstrittensten VPN-Protokollen. Aber kennen Sie die Geschichte, wie es dazu gekommen ist?
In diesem Beitrag werfen wir einen technischen Blick in die IPsec-Protokollsuite, beleuchten die wichtigsten IKE-Erweiterungen und bewerten die Vor- und Nachteile von IKEv2 VPN im Vergleich zu IKEv1.
Lesen Sie weiter und erfahren Sie, wie IKEv2 VPN fast das perfekte VPN-Protokoll geworden wäre.
Inhalt:
IPsec und IKE: Die Grundlagen
IPsec ist vielen ein Begriff, die sich schon einmal mit dem Thema VPN beschäftigt haben. Wussten Sie jedoch, dass IPsec selbst gar kein VPN-Protokoll ist? Tatsächlich handelt es sich bei IPsec um eine Protokollsuite, die aus verschiedenen Protokollen besteht, von denen jedes eine bestimmte Aufgabe erfüllt.
In diesem Deep Dive betrachten wir ESP und IKE genauer.
Was ist ESP?
ESP (Encapsulating Security Payload) ist das zentrale VPN-Protokoll zum Austausch von verschlüsselten und integritätsgeschützten Daten. Es kann verwendet werden, um den Inhalt eines IP-Pakets zu verschlüsseln oder ganze IP-Pakete über ein IP-Netzwerk wie das Internet zu tunneln.
ESP wurde 1998 standardisiert und ist ein relativ einfaches Protokoll, denn in Sachen Sicherheit gilt: Je einfacher, desto besser. Zudem ist ESP sehr schnell und kann dank seiner flexiblen Struktur zu einem der sichersten VPN-Protokolle gemacht werden – durch die Unterstützung zahlreicher kryptografischer Verfahren.
Alles, was Sie für einen ESP-Tunnel benötigen, ist, dass sich beide Seiten auf die zu verwendenden kryptografischen Verfahren sowie einen Satz kryptografischer Schlüssel einigen. Dann kann es losgehen …
… außer: Wie sollen sich beide Seiten auf Verfahren einigen, und wie überträgt man sicherheitskritische Schlüssel von einer Seite zur anderen, wenn einem nur ein unsicheres Medium wie das Internet zur Verfügung steht?
Hier kommt ein weiteres Protokoll der Suite ins Spiel: IKE (Internet Key Exchange).
Was ist IKE?
IKE basiert auf einem allgemeineren Protokoll namens ISAKMP (Internet Security Association and Key Management Protocol). Die Aufgabe von IKE lässt sich wie folgt beschreiben: Es soll eine sichere Verbindung zwischen zwei Endpunkten herstellen und diese sichere Verbindung nutzen, um Sitzungsschlüssel und Parameter für einen tatsächlichen IPsec-Tunnel auszuhandeln.
Im Gegensatz zu ESP, das ein Layer-4-Protokoll ist und direkt auf IP aufsetzt (also dort, wo man normalerweise Protokolle wie UDP, TCP oder ICMP erwartet), handelt es sich bei IKE um ein Layer-7-Protokoll, das auf UDP aufsetzt und Port 500 verwendet. UDP ist, genau wie ESP, ein verbindungsloses Protokoll – es kennt das Konzept einer Verbindung nicht, sondern sendet einfach Pakete mit bestimmten Parametern an ein Ziel und hofft, dass sie ankommen. IKE hingegen versteht sehr wohl, was eine Verbindung ist, und nutzt UDP lediglich als Transportmechanismus, da UDP schnell und einfach ist.
Das OSI-Modell
IKE-Phasen
Eine IKE-Verbindung lässt sich in drei Phasen unterteilen:
Phase Eins: Kontaktaufnahme
In der ersten Phase wird ein Endpunkt kontaktiert, man einigt sich auf kryptografische Verfahren, leitet Sitzungsschlüssel für die aktuelle Session ab und führt eine gegenseitige Authentifizierung der Endpunkte durch.
Phase Zwei: Aushandlung
In der zweiten Phase werden die Parameter und Schlüssel für den gewünschten IPsec-Tunnel ausgehandelt.
Diese Parameter und Schlüssel werden auch als Security Association (SA) bezeichnet. Ein IPsec-Tunnel benötigt in der Regel zwei SAs, da sie unidirektional sind – eine SA wird für das Senden von Daten benötigt, eine weitere für den Empfang. In manchen Fällen können auch mehrere SAs ausgehandelt werden.
Phase Drei: Überwachung
Die dritte und letzte Phase dient der Überwachung der laufenden Verbindung sowie der regelmäßigen Erneuerung aller SAs, da die Verwendung derselben kryptografischen Schlüssel über einen längeren Zeitraum das gesamte System zunehmend angreifbar macht.
IKE-Erweiterungen: Hauptprobleme und Lösungen
Trotz seiner Komplexität fehlte dem IKE-Protokoll grundlegende Funktionalität, die erst später durch Erweiterungen ergänzt wurde. Einige dieser Erweiterungen wurden standardisiert und gelten heute als offizielle Ergänzungen, andere kamen nie über den Entwurfsstatus hinaus – wurden aber dennoch weit verbreitet implementiert, weil es schlicht keine besseren Alternativen gab und Hersteller keine Wahl hatten.
Dieser Abschnitt gibt einen Überblick über die zugrunde liegenden Probleme und die jeweiligen Erweiterungen, die zur Lösung eingeführt wurden.
Dead Peer Detection
Man könnte argumentieren, dass IKE ursprünglich nicht für eine Client-Gateway-Architektur konzipiert wurde, sondern eher für eine Gateway-zu-Gateway-Architektur. Das bedeutet, es wurde entwickelt, um IPsec-Verbindungen zur Tunnelung von Datenverkehr zwischen Netzwerken (z. B. Hauptsitz und Zweigstelle) aufzubauen – und nicht für ein sogenanntes „Road Warrior“-Szenario (z. B. Homeoffice, Außendienst, Geschäftsreisen).
Zum Beispiel wird eine IKE-Verbindung in Phase drei typischerweise über einen längeren Zeitraum hinweg keine Daten austauschen. Dies kann ein Problem für Router mit Network Address Translation (NAT) darstellen, da diese ihre NAT-Zuordnung verlieren. Dadurch bricht die IKE-Verbindung unbemerkt ab – bis IKE erneut versucht, Daten zu senden. Dasselbe gilt für Firewalls mit Stateful Packet Inspection (SPI), da auch sie den nötigen Status verlieren, um IKE-Pakete durchzulassen.
Geht schließlich ein Endpunkt plötzlich offline, bleibt auch das unbemerkt, da der IPsec-Tunnel das Fehlen von Antworten nicht erkennt – nicht jeder ausgehende Datenverkehr führt zu einer Antwort.
All diese Probleme wurden durch die Einführung einer Erweiterung namens DPD (Dead Peer Detection) gelöst.
NAT-Router und NAT-Traversal
Da wir gerade über NAT-Router gesprochen haben, ist es wichtig zu erwähnen, dass diese grundsätzlich ein Problem mit dem Umgang von ESP haben, da sie in der Regel Portnummern umschreiben, um NAT durchzuführen – was zu zwei Problemen führt:
- ESP besitzt keine Portnummern, sondern lediglich eine Indexnummer namens SPI (Security Parameters Index), um den Tunnel zu identifizieren.
- Selbst wenn ein NAT-Router ESP verstehen würde, könnte er den SPI nicht umschreiben, ohne die Pakete zu zerstören, da diese durch Integritätsschutz gesichert sind – jede Veränderung unterwegs macht das Paket ungültig.
Die Lösung: NAT-Router erkennen und ESP-Pakete bei Bedarf in UDP verpacken. Damit dies funktioniert, musste eine weitere Erweiterung eingeführt werden – NAT-T (NAT-Traversal). Da viele Hersteller jedoch nicht auf die Finalisierung dieser Erweiterung warten wollten, begannen sie mit der Implementierung von NAT-T, als es sich noch im Entwurfsstadium befand. Aus diesem Grund unterstützen IPsec-Clients und Gateways heute bis zu sieben verschiedene Entwurfsfassungen sowie den endgültigen Standard.
Einige davon nutzen unterschiedliche Protokoll- oder Portnummern – sodass zwei Endpunkte hoffentlich eine gemeinsame NAT-T-Version finden, auf die sie sich einigen können. Die späteren Entwürfe und der endgültige Standard verwenden den bekannten UDP-Port 4500.
Benutzerauthentifizierung (XAUTH)
Große Unternehmen verfügen in der Regel über eine zentrale Datenbank für ihre Benutzerbasis (Active Directory, Open Directory/LDAP, RADIUS usw.) – und natürlich wollten sie, dass sich VPN-Nutzer genauso gegen diese Datenbanken authentifizieren wie beim Zugriff auf den Mailserver, interne Websites oder beim Einloggen am Arbeitsplatz.
IKE erlaubt es Endpunkten, sich entweder über Zertifikate oder über einen Pre-Shared Key (ein geheimes Passwort, das beide Seiten im Voraus kennen müssen) zu authentifizieren. Viele Unternehmen hatten jedoch keinen sicheren Rollout-Prozess für Benutzerzertifikate. Die Verwendung eines PSK als Benutzerpasswort würde zwar grundsätzlich funktionieren – aber woher soll das Gateway wissen, welcher Benutzername erforderlich ist, um das richtige Passwort abzurufen?
Man könnte versuchen, das Identifier-Feld dafür (missbräuchlich) zu nutzen. Doch im Main-Exchange-Modus (eine der zwei möglichen Arten, wie IKE eine Verbindung aufbaut) wird das Passwort bereits benötigt, bevor der Identifier überhaupt übermittelt wurde.
Im Aggressive-Exchange-Modus hingegen kann ein Angreifer, der den IKE-Datenverkehr mitschneidet, versuchen, den PSK per Offline-Angriff zu knacken. Das bedeutet, die Sicherheit des Unternehmens hängt davon ab, ob die Nutzer starke Passwörter wählen – und wir wissen alle, wie schlecht Nutzer darin sind, sichere Passwörter auszuwählen.
Die Lösung war eine Erweiterung namens XAUTH (eXtended AUTHentication), die verschiedenste Formen der Benutzerauthentifizierung unterstützt – von einfachen Klartextpasswörtern bis hin zu Challenge-Verfahren.
XAUTH führt einen neuen Austauschmodus ein (Transaction Exchanges), der zwischen Phase eins und zwei einer IKE-Verbindung stattfindet – also über eine bereits kryptografisch abgesicherte Verbindung. Erst nach erfolgreichem Abschluss dieses Schritts darf ein IPsec-Tunnel ausgehandelt werden.
Dies ermöglichte nicht nur die Authentifizierung von Benutzern, sondern auch Funktionen wie Accounting oder eine einfache Möglichkeit, Nutzer vom VPN auszuschließen. Trotz seiner großen Bedeutung – heute wird XAUTH von etwa vier von fünf Gateways unterstützt – blieb die Erweiterung jedoch im Entwurfsstadium stecken und wurde schließlich aufgegeben, ohne dass eine Alternative definiert wurde.
Automatic configuration and Mode Config
The other thing every big IPsec setup calls for, and every network admin begs for, is automatic configuration.
DHCP was developed for the same reason why users no longer want to assign IP addresses by hand anymore: they also don't want to configure IPsec network parameters for every individual user by hand.
The solution to this challenge has been named MCFG (Mode ConFiG, aka IKECFG or IKEConfig). MCFG builds upon the transaction exchange introduced by XAUTH and just like XAUTH, it never got past an early draft state. Still, it's widely adopted and around two third of all IPsec gateways offer MCFG today.
Using MCFG a gateway can assign a VPN client an IP address and a subnet mask, it can tell the client about available remote DNS servers, and distribute a few other configuration parameters.
Yet even that extension had a major oversight: There's no way to tell a client about available remote networks. This was such an important missing feature that Cisco extended MCFG (yes, they extended an unfinished draft extension to a protocol), adding this feature and naming the whole thing "Easy VPN". Since its introduction, even that proprietary, undocumented extension has been widely adopted by many other vendors simply because of how useful the feature is.
IKEv2 VPN als Retter?
Mit all diesen Erweiterungen – und noch weiteren, die hier gar nicht aufgeführt sind – wurde IKE schnell zu einem äußerst komplexen Protokoll und zu einem wahren Albtraum in Sachen Kompatibilität. Jeder Client und jedes Gateway unterstützte unterschiedliche Funktionsumfänge oder verschiedene Entwurfsfassungen der Erweiterungen.
Hinzu kommt, dass viele dieser Erweiterungs-„Standards“ schlecht dokumentiert sind und zahlreiche offene Fragen hinterlassen. Oft ist gar nicht klar, wie sie korrekt implementiert werden sollen – insbesondere, da verschiedene Implementierungen sich in zentralen Punkten widersprechen.
Im Jahr 2010 hatte die IETF (Internet Engineering Task Force) genug von all den Kompatibilitätsproblemen und standardisierte schließlich IKE Version 2 (IKEv2).
Kerneigenschaften von IKEv2 VPN
Von Anfang an bot IKEv2 VPN Funktionen wie DPD und NAT-T als festen Bestandteil. Zudem basiert das Protokoll nicht mehr auf ISAKMP, sondern ist ein eigenständiges Protokoll – dort, wo keine Änderungen nötig waren, weiterhin kompatibel mit IKE, aber dennoch in vielen Punkten grundlegend anders.
Beispielsweise erfordert eine vollständige ESP-Tunnel-Aushandlung je nach gewähltem Austauschmodus mindestens 9 bis 11 Pakete. IKEv2 VPN hingegen bietet nur einen einzigen Austauschmodus und benötigt für die Aushandlung nur minimal 4 Pakete.
Ein weiteres Problem bei IKEv1 war, dass für jede Kombination vorgeschlagener Sicherheitsparameter ein eigener Vorschlag erforderlich war. Dadurch wurden die Pakete schnell sehr groß, wenn zu viele Parameter angeboten wurden. In IKEv2 VPN hingegen werden die Parameter einfach in einem oder zwei Vorschlägen zusammengefasst, und die Gegenseite wählt daraus die bevorzugten Parameter – was die Pakete klein und übersichtlich hält.
IKEv2 VPN hatte das Potenzial, alle bekannten Schwächen von IKE zu beheben und IPsec zur besten VPN-Protokollsuite überhaupt zu machen – aber Spoiler: So kam es nicht.
Es wurden neue Fehler gemacht, einige Designentscheidungen sind höchst fragwürdig – doch das größte Problem, das viele VPN-Experten ratlos zurücklässt: Alte Fehler wurden einfach wiederholt.
Hier zwei Beispiele:
Hauptschwächen von IKEv2 VPN
Remote-Netzwerke
Obwohl IKEv2 VPN eine eingebaute Unterstützung für den Konfigurationsaustausch bietet – wodurch Mode Config nicht mehr erforderlich ist – fehlt weiterhin eine Möglichkeit, eine Liste von Remote-Netzwerken zu übermitteln.
Diese eine Funktion war so wichtig, dass Cisco Mode Config erweitern und ein eigenes proprietäres Protokoll entwickeln musste, damit auch andere Hersteller diese nutzen konnten – und trotzdem wurde sie in IKEv2 erneut weggelassen!
Stattdessen unterstützt IKEv2 VPN etwas namens Traffic Selector (TS)-Aushandlung, das jedoch aus zwei Gründen kein gleichwertiger Ersatz sein kann:
Erstens kann die Anzahl der Remote-Netzwerke auf diese Weise nicht ausgehandelt werden. Damit TS als Ersatz funktioniert, müsste der Client die Anzahl der verfügbaren Remote-Netzwerke im Voraus kennen.
Zweitens kann es zu Missverständnissen kommen: Während der TS-Aushandlung schlägt der Client bestimmte Remote-Netzwerke vor, und das Gateway schränkt diese Vorschläge auf passende Subnetze ein. Wenn der Client keine Kenntnis über die Remote-Netzwerke hat, könnte er vorschlagen, den gesamten Datenverkehr zu tunneln – woraufhin das Gateway dies auf die verfügbaren Netzwerke beschränken könnte. Die Konfiguration des Gateways könnte entweder nur spezifische Netzwerkzugriffe erlauben oder tatsächlich vollen Datenverkehrstunnel zulassen.
Das führt zu Mehrdeutigkeiten: Wenn der Client „gesamten Datenverkehr“ anfordert, ist unklar, ob er wirklich komplettes Tunneling meint oder nur Remote-Netzwerkzugriff. Im schlimmsten Fall bittet der Client um „alles“ – und das Gateway erlaubt es, obwohl das gar nicht beabsichtigt war.
Die Lage ist so unübersichtlich, dass ein Anbieter die Cisco-Mode-Config-Erweiterung bereits auf IKEv2 portiert hat – was nun wiederum proprietär ist und von anderen Herstellern nicht unterstützt wird. Dabei wäre es so einfach gewesen, die Konfiguration einer Liste von Remote-Netzwerken zu ermöglichen. Da Konfigurationsoptionen ohnehin optional sind, gab es eigentlich keinen Grund, dies nicht zu tun.
EAP-Authentifizierung
Ein weiteres großes Problem ist, dass IKEv2 VPN zur Benutzerauthentifizierung nicht mehr XAUTH verwendet, sondern ein Protokoll namens EAP (Extensible Authentication Protocol). Die Idee, ein vorhandenes Protokoll zu nutzen, das auch bei anderen Netzwerkprotokollen eingesetzt wird und für das bereits Code vorhanden sein könnte, klingt zunächst sinnvoll – bringt in der Praxis aber viele Nachteile mit sich.
EAP selbst definiert nur ein einziges verpflichtendes Authentifizierungsverfahren – das heute kaum jemand nutzen möchte. Für alle anderen Verfahren gibt es Dutzende EAP-Erweiterungen, aber keine davon ist verpflichtend. Selbst wenn ein Client und ein Gateway beide EAP unterstützen, gibt es keine Garantie, dass sie sich auf ein gemeinsames Verfahren einigen können oder dürfen.
Das Ergebnis: Viele IKEv2-VPN-kompatible Gateways unterstützen EAP gar nicht oder nur mit einem gängigen Verfahren – jenem, das Microsoft Windows verwendet. Viele EAP-Implementierungen unterstützen zumindest dieses einfache Verfahren mit Benutzername und Passwort.
Sobald Gateways OTP- oder 2FA-Verfahren anbieten möchten, greifen sie nicht auf EAP zurück, sondern setzen auf eigene proprietäre Lösungen – was die Kompatibilität zwischen verschiedenen Anbietern, Gateways und Clients zerstört.
Dabei hätte sich das Problem leicht vermeiden lassen: Der IKEv2-VPN-Standard hätte einfach eine definierte Auswahl an EAP-Verfahren verpflichtend vorschreiben können, um sicherzustellen, dass jede IKEv2-EAP-Implementierung mindestens den gleichen Funktionsumfang bietet wie XAUTH bei IKE.
Wie sieht die Zukunft von IPsec aus?
Das Ergebnis dieser wiederholten Fehler ist, dass einige Hersteller IPsec als Client-Protokoll aufgegeben haben und stattdessen auf eigene, proprietäre VPN-Protokolle setzen.
Viele argumentieren: Wenn man ohnehin proprietäre Erweiterungen zu IKEv2 hinzufügen muss, um es zu einem brauchbaren Standard zu machen, kann man gleich vollständig auf ein eigenes VPN-Protokoll umsteigen – oder eine andere Lösung verwenden, die bereits alle Anforderungen erfüllt, wie zum Beispiel OpenVPN oder WireGuard®.
Auf der anderen Seite setzten andere Hersteller einfach weiterhin auf IKEv1 – mitsamt all seiner eigenwilligen Erweiterungen – und verzichteten komplett auf die Unterstützung von IKEv2.
In vielerlei Hinsicht ist IKEv2 eine verpasste Chance: so nah dran, die perfekte Lösung zu sein – und doch, wie man so schön sagt, ist „knapp daneben“ eben auch vorbei.
Mit IKEv2 VPN in VPN Tracker verbinden
Sie verwenden eine IKEv1- oder IKEv2-VPN-Verbindung? Dann ist VPN Tracker die beste Wahl als VPN-Client für Mac, iPhone und iPad. Die eigens entwickelte IKEv2-VPN-Engine von VPN Tracker bietet umfassende Unterstützung für alle relevanten IKE-Erweiterungen und sorgt für nahtlose Kompatibilität mit den beliebtesten IKEv1- und IKEv2-VPN-Gateways von Cisco, Fortinet, Zyxel, TP Link, Draytek und vielen weiteren.
Sie möchten IKE hinter sich lassen? Kein Problem – VPN Tracker unterstützt außerdem OpenVPN, PPTP (nur für Mac), L2TP (nur für Mac), WireGuard, SSTP, SonicWall SSL, Cisco AnyConnect SSL und Fortinet SSL-Verbindungen.
Warum VPN Tracker?
- Sichere Verbindung mit Ihrem Heim- und Büronetzwerk
- Verwendung Ihres eigenen VPN-Gateways
- Unterstützung für 10 VPN-Protokolle mit eigenen Engines
-
Vorkonfigurierte Profile für über 300 VPN-Geräte
- Produktivitätsfunktionen speziell für Teams
- Für Mac, iPhone und iPad
- Alle Funktionen entdecken
