IKEv2/IPsec: Wie das eingebaute VPN-Protokoll verbindet, roamt und blockiert wird

IKEv2 (Internet Key Exchange version 2) ist der Teil eines IPsec-VPNs, der beide Enden authentifiziert, Algorithmen aushandelt und Schlüssel ableitet; IPsec ESP verschlüsselt dann jedes Datenpaket. Das Paar wird zusammen als IKEv2/IPsec bezeichnet und ist in Windows, Apple-Geräten und aktuellen Android-Versionen enthalten, sodass keine separate App zum Verbindungsaufbau nötig ist.

Kontrollseite versus Datenseite

Die Suite teilt die Arbeit auf. IKEv2 ist die Steuerungskommunikation: Sie prüft Identitäten, verhandelt Chiffren und erzeugt Schlüssel. ESP (Encapsulating Security Payload) ist der Datenpfad, der jedes Paket versiegelt. IKEv2 allein transportiert keinerlei Nutzdaten.

Die Mechanik steckt in Security Associations. Die IKE-SA schützt die Verwaltungskommunikation zwischen Client und Server. Jede Child-SA ist ein Paar aus zwei unidirektionalen IPsec-SAs, eine pro Richtung, das die eigentlichen Daten überträgt. Das Protokoll geht auf RFC 4306 aus dem Dezember 2005 zurück, wurde 2010 als RFC 5996 überarbeitet und ist heute in RFC 7296 verankert, einem Internet-Standard, der vor allem von Microsoft und Cisco vorangetrieben wurde. Gegenüber IKEv1 benötigt es vier statt neun Nachrichten zum Aufbau eines Tunnels, und NAT-Durchquerung sowie Liveness-Prüfungen sind eingebaut statt nachträglich ergänzt. Die beiden Versionen sind nicht interoperabel.

Vier Nachrichten bis zum funktionierenden Tunnel

Der erste Austausch, IKE_SA_INIT, enthält Chiffren-Vorschläge, öffentliche Diffie-Hellman-Werte, zufällige Nonces und NAT-Erkennungs-Hashes. Ein stark belasteter Server kann mit einem zustandslosen Cookie antworten und den Client seine Nachricht wiederholen lassen, wodurch Paketfluten mit gefälschten Absenderadressen abgewehrt werden, bevor aufwendige Berechnungen anfallen. Danach folgt IKE_AUTH, bereits verschlüsselt: Identitäten, Identitätsnachweis, Traffic-Selektoren und die erste Child-SA. Danach fließt der Datenverkehr.

Später fügt CREATE_CHILD_SA Tunnel hinzu und erneuert alte per Rekeying. Läuft bei einem Rekey ein neuer Diffie-Hellman-Austausch, lassen sich alte Mitschnitte nicht aus den neuen Schlüsseln rekonstruieren – genau das ist der Sinn von Perfect Forward Secrecy. INFORMATIONAL-Nachrichten behandeln Dead-Peer-Erkennung, Löschungen, Fehler und, wie unten beschrieben, Adressaktualisierungen.

Die Authentifizierung gibt es in drei Varianten. Zertifikate sind der sichere Weg. EAP erlaubt einem Nutzer die Anmeldung mit Benutzername und Passwort, während sich der Server per Zertifikat ausweist. Ein Pre-Shared Key, der jedem Nutzer eines Servers ausgehändigt wird, ist die Schwachstelle: Wer ihn besitzt, kann sich als dieser Server ausgeben.

MOBIKE: der Tunnel folgt Ihrem Telefon

Verlassen Sie die WLAN-Reichweite, bezieht das Telefon eine Mobilfunk-IP-Adresse. Ohne Zusatzmaßnahmen zerbrechen die Security Associations, und der Client muss den vollständigen Handshake erneut durchlaufen, was für Apps einen Verbindungsabbruch bedeutet. MOBIKE (RFC 4555, Juni 2006) behebt das: Der Client sendet eine UPDATE_SA_ADDRESSES-Benachrichtigung von seiner neuen Adresse, der Server passt die IKE-SA und die IPsec-SAs an die neue Adresse an, und die Sitzung übersteht das innerhalb eines Round Trips. Kein neuer Handshake, keine neue Anmeldung. Multihoming erlaubt einem Gerät mit mehreren Adressen den Wechsel auf eine andere. Deshalb fühlt sich IKEv2 auf Mobiltelefonen so wohl.

Eingebaute Clients und feste Ports

Windows, macOS, iOS, iPadOS und Android 11+ haben den Client in den Systemeinstellungen: Sie geben eine Serveradresse, eine Remote-ID sowie ein Zertifikat, einen PSK oder Zugangsdaten ein. Linux und ältere Android-Versionen benötigen strongSwan oder Libreswan. Was Sie gegenüber einer Anbieter-App verlieren, sind die Extras: Ein Kill Switch etwa verhindert den Leak, wenn der Tunnel im Hotel-WLAN stirbt.

Der Austausch beginnt auf UDP 500 und wechselt zu UDP 4500, sobald NAT erkannt wird, mit in UDP verpacktem ESP. Ohne NAT läuft ESP als IP-Protokoll 50, das viele Heimrouter und Firewalls verwerfen. IKEv2 zu blockieren ist trivial: Die Ports sind fest, der Header mit SPIs und Austauschtyp geht im Klartext über die Leitung, und der Standard sieht keinen Verschleierungsmodus vor. Eine einzige Firewall-Regel, die UDP 500 und 4500 verwirft, genügt, und DPI erkennt den Handshake sofort; der Ausweg ist eine Ausweichoption wie OpenVPN über TCP 443 oder ein Stealth-Protokoll des Anbieters.

IKEv2 neben WireGuard und OpenVPN

WireGuard ist schlanker, nutzt einen festen, modernen Cipher-Satz und roamt ebenfalls gut, doch weder es noch IKEv2 entzieht sich der Deep Packet Inspection. OpenVPN punktet in restriktiven Netzwerken, in denen nur Web-Ports überleben.

IKEv2 unter den VPN-Diensten

Von 543 Privatkunden-VPN-Diensten in der VPNRadarLab-Datenbank geben 133 an, IKEv2 anzubieten, 105 erklären, es nicht anzubieten, und 305 schweigen, was nur bedeutet, dass sie es nicht veröffentlichen. Das IKEv2-Ranking listet alle 133 mit Wertungen, Preisen und Laufzeiten.

FAQ

Was bedeutet IKEv2 in den VPN-Einstellungen meines Telefons?

Es ist der Protokolltyp dieses Profils. Wählen Sie es, wenn Ihr Anbieter Ihnen IKEv2-Daten übergibt.

Ist IKEv2 noch sicher?

Ja, solange der Server moderne Cipher-Suiten anbietet und die Authentifizierung korrekt eingerichtet ist. Veraltete Vorschläge und gemeinsame Schlüssel sind es, was das Protokoll schwächt.

IKEv2 oder OpenVPN?

IKEv2 auf dem roamenden Telefon, OpenVPN über TCP 443, wo UDP gefiltert wird.

Kann das Netzwerk erkennen, dass ich IKEv2 nutze?

Es sieht das Protokoll und die Ports, niemals den Inhalt des Tunnels.

IKEv2 in Kürze

Ein Schlüsselaustausch mit vier Nachrichten plus ESP-Verschlüsselung, standardisiert in RFC 7296, in den großen Betriebssystemen eingebaut und dank MOBIKE auch unterwegs stabil. Sein lesbarer Header und die festen UDP-Ports 500 und 4500 machen es leicht zu blockieren, daher halten Sie für gefilterte Netzwerke eine besser verschleiernde Ausweichoption bereit.