L2TP über IPsec: Warum der Tunnel ein zweites Protokoll braucht und wo es noch passt

L2TP/IPsec ist ein VPN aus zwei übereinander gestapelten Protokollen. L2TP (Layer 2 Tunneling Protocol) gräbt den Tunnel und transportiert Ihre PPP-Sitzung hindurch, verschlüsselt aber selbst nichts. IPsec ESP schützt jedes dieser Pakete, und das Paar ist nach wie vor in Windows, in den Apple-Einstellungen und in unzähligen Routern enthalten – startet jedoch langsam, macht hinter NAT Probleme und stirbt an einer einzigen Firewall-Regel.

Ein Name, zwei Protokolle

L2TP entstand als Verschmelzung von Microsofts PPTP und Ciscos L2F und wurde im August 1999 als RFC 2661 veröffentlicht. Seine Aufgabe ist reine Kleinarbeit: PPP-Frames zwischen Client und Server zu transportieren. Vertraulichkeit wurde ausgelagert, und RFC 3193 legte fest, wie: IPsec ESP im Transportmodus, verpflichtend für Steuer- und Datenpakete. IPsec' eigener Tunnelmodus bleibt normalerweise ungenutzt, weil L2TP selbst bereits den Tunnel bereitstellt.

Was beim Drücken von „Verbinden“ passiert

Die Fehlersuche beginnt mit der Abfolge. IKEv1 verhandelt zuerst die IPsec-Security-Association, über UDP 500 (allein der Main Mode benötigt 6 Nachrichten, plus 3 weitere für den Quick Mode). Dann schaltet sich ESP im Transportmodus ein: Der Kanal ist privat, aber es fließt noch nichts hindurch. Erst danach nutzt L2TP UDP 1701, eingepackt in ESP, um den Tunnel aufzubauen. Zuletzt kommt PPP, das Sie mit PAP, CHAP oder MS-CHAPv2 anmeldet und den eigentlichen Datenverkehr trägt.

Das bedeutet zwei getrennte Zugangsdaten. Der Rechner weist sich in der IPsec-Stufe mit einem Pre-Shared Key oder einem Zertifikat aus; Ihr Benutzername und Ihr Passwort öffnen die PPP-Sitzung. Ein falscher Schlüssel beendet die Verbindung sofort, ein falsches Passwort lässt IPsec erfolgreich verlaufen und scheitert stattdessen am PPP-Schritt.

Ports und das NAT-Problem

Rohes ESP hat keine Portnummern, und ein Heimrouter, der Adressübersetzung betreibt, hat nichts, woran er Rückpakete zuordnen könnte. NAT Traversal (nach RFC 3947 und RFC 3948) behebt das, indem es ESP in UDP 4500 verlagert. Routermenüs verbergen die zugehörigen Schalter unter Bezeichnungen wie IPsec passthrough.

Windows bringt eine eigene Falle mit: Standardmäßig lehnt der Client NAT-T-Security-Associations ab, wenn der VPN-Server selbst hinter NAT sitzt. Die Lösung ist der Wert AssumeUDPEncapsulationContextOnSendRule unter HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent (1, wenn der Server hinter NAT sitzt, 2, wenn beide Enden es tun), gefolgt von einem Neustart.

Auch die doppelte Kapselung frisst an der Paketgröße: PPP, L2TP, ESP und oft ein UDP-4500-Header drücken die nutzbare MTU unter 1500. Wenn kleine Seiten laden, aber große Übertragungen hängen, wenden Sie MSS Clamping auf dem Router an.

Der gemeinsame Schlüssel, den alle kennen

RFC 3193 beschreibt die Schwäche selbst in Abschnitt 5.1.4. Im IKEv1 Main Mode kann der Server einen roaming-Benutzer nicht identifizieren, bevor er einen Schlüssel wählt, sodass ein gruppeweiter Pre-Shared Key am Ende von jedem Abonnenten geteilt wird. Während der IKE-Phase weist dann keine der beiden Seiten ihre Identität aus: Jeder, der den Gruppenschlüssel besitzt, kann sich als Server ausgeben, und ein gefälschter Server kann CHAP-Anmeldungen für einen Wörterbuchangriff einsammeln. Der Aggressive Mode verhindert diese Form der Server-Imitation, legt aber die Benutzeridentität offen, und sein Schlüssel-Hash lässt sich offline knacken. Der RFC empfiehlt, dass Implementierungen keinen Gruppenschlüssel verwenden sollten (SHOULD NOT). Viele Privatkunden-VPN-Anbieter veröffentlichen dennoch einen gemeinsamen Schlüssel für alle Abonnenten; ein Serverzertifikat beseitigt die Schwäche vollständig.

Warum L2TP/IPsec als Legacy gilt

Die Kritik ist berechtigt. IKEv1 redet deutlich mehr als IKEv2, Verschlüsselungskonfigurationen setzen auf AES-CBC mit einem separaten HMAC statt auf moderne AEAD-Modi, und jedes Paket zahlt für zwei Protokollebenen. Der Wechsel von WLAN zu mobilen Daten erzwingt ein vollständiges erneutes Verbinden, weil es kein roaming gibt. Feste Ports und lesbare IKE-Header bedeuten, dass eine einzige Firewall-Regel das gesamte Protokoll blockiert, ohne Verschleierung, hinter der man sich verstecken könnte. Die Plattformunterstützung schrumpft stetig. Das Setup, das die meisten Geräte heute tatsächlich verwenden, ist in unserem IKEv2-Glossar-Eintrag beschrieben.

Wo L2TP/IPsec noch sinnvoll ist

Es passt zu Geräten, deren einzige Option der integrierte Client ist: die in Windows oder Apple integrierten VPN-Einstellungen, Android 11 und älter, viele Heim- und Kleinbüro-Router, NAS-Geräte, ältere Office-Gateways. Internetanbieter betreiben auch reines L2TP als Transport für die Breitband-Aggregation, dort dient es jedoch dem Datentransport und nicht dem Datenschutz. Vermeiden Sie das Paar in Netzwerken, die VPN-Verkehr filtern, und für alles, was einem ernsthaften Gegner gegenübersteht.

L2TP/IPsec-Unterstützung bei VPN-Diensten

Von 543 Privatkunden-VPNs in der VPNRadarLab-Datenbank geben 67 an, L2TP/IPsec anzubieten, 46 bieten es ausdrücklich nicht an, und 430 veröffentlichen nicht, ob sie es unterstützen. Das L2TP-Ranking listet die 67 Dienste, die angeben, L2TP/IPsec anzubieten.

L2TP/IPsec-FAQ

Ist L2TP dasselbe wie IPsec?

Nein. L2TP baut den Tunnel, IPsec schützt, was hindurchreist.

Kann L2TP ohne IPsec laufen?

Technisch ja, aber dann wird nichts verschlüsselt.

Welche Ports müssen offen sein?

UDP 500 und UDP 4500, plus IP-Protokoll 50, wo kein NAT auf dem Weg sitzt.

Funktioniert L2TP/IPsec hinter NAT?

Ja, über NAT Traversal auf UDP 4500; unter Windows wenden Sie den Registry-Fix an, wenn der Server hinter NAT sitzt.

L2TP/IPsec in Kürze

Ein L2TP-Tunnel, geschützt durch IPsec ESP, mit per IKEv1 ausgehandelten Schlüsseln, angemeldet über PPP, erreichbar auf UDP 500 und 4500. Behalten Sie es für Geräte, deren einziger Client der integrierte ist, verwenden Sie Zertifikate statt eines gemeinsamen PSK, und wechseln Sie zu IKEv2 oder WireGuard, wo die Hardware es erlaubt.