IPsec war eine gute Idee. Es ist Zeit, es abzuschalten.

IPsec war eine gute Idee. Leg die Verschlüsselung auf die Netzwerkschicht, unter alles andere, und jedes Protokoll, das über IP läuft, erbt Vertraulichkeit und Integrität, ohne davon zu wissen. Keine Bibliothek einzubinden. Kein Zertifikat pro Anwendung. Kein Umschreiben dessen, was du längst ausgeliefert hast. Das Paket verlässt den Rechner geschützt und kommt geschützt an, und die Router dazwischen tragen es, ohne zu wissen oder wissen zu wollen, was drinsteckt.

Dieser Entwurf ruht auf einer Annahme, und sie steht im Standard, statt nur mitgemeint zu sein: die Adresse eines Pakets bezeichnet die Maschine, von der es kam. Eine Security Association wird über die Zieladresse, die Protokollnummer und den SPI nachgeschlagen¹. Der Authentication Header geht noch weiter und signiert den IP-Header selbst, Quelle und Ziel eingeschlossen². Die Adresse ist für IPsec keine Routing-Metadaten. Sie ist Teil der Identität und Teil der Integritätsprüfung.

Dann hat diese Branche dreißig Jahre lang die Adresse weggenommen.

Zuerst NAT, damit ein Büro hinter eine Leitung passt. Dann Carrier-Grade NAT, damit mehrere hundert Haushalte hinter eine Adresse passen, weil IPv6 einzuschalten Arbeit war und eine Box zu kaufen Beschaffung — was das ganze Thema von Uns sind nie die Adressen ausgegangen. Uns ist die Mühe ausgegangen. ist, und das gehe ich hier nicht noch einmal durch. Was für diesen Beitrag zählt, ist die Folge. Genau das eine, worauf IPsec gebaut wurde, liefert das moderne Zugangsnetz nicht mehr.

Also wurde IPsec geflickt. Pack das verschlüsselte Paket in UDP, damit ein Übersetzer einen Port zum Umschreiben hat. Setz die Prüfsumme auf null, damit sie niemand nachrechnet. Schick alle zwanzig Sekunden ein Ein-Byte-Paket, für immer, damit eine Tabelle in fremder Hardware nicht vergisst, dass es dich gibt. Nimm die Identität von der Adresse weg und häng sie an einen Namen. Gib den Authentication Header auf, weil er einen umgeschriebenen Header konstruktionsbedingt nicht überleben kann. Und wenn ein Hotel UDP blockiert, pack das Ganze zusätzlich in TCP³.

Jede einzelne davon ist eine echte, standardisierte, herstellerunterstützte Lösung. Zusammen sind sie ein Protokoll, das von seinem eigenen Gerüst gehalten wird. Und das Gerüst ist das Argument: man stützt nichts ein Vierteljahrhundert lang ab, weil es im Kern gesund ist.

Ich bin zu dem Schluss gekommen, dass IPsec vollständig stillgelegt gehört. Nicht nachjustiert, nicht mit besseren Chiffren neu aufgelegt, nicht für Site-to-Site behalten, weil der Teil ja noch geht. Stillgelegt, mit Terminen, so wie PPTP ein Jahrzehnt früher hätte stillgelegt werden sollen, als sich endlich jemand darum gekümmert hat. Was folgt, sind die Belege, die Diagramme, die Herstellerdokumentation, die all das in den Worten der Hersteller selbst sagt, und — weil die meisten, die das lesen, die Dinger montags trotzdem am Laufen halten müssen — eine brauchbare Methode, IPsec-Fehler in der Zwischenzeit zu diagnostizieren.

Was es dich tatsächlich kostet, in Tickets

Vor den Standards hier die Rechnung, in der Reihenfolge, in der sie dir begegnet.

Der Tunnel fällt im Takt aus. Jede Stunde, oder alle acht, oder nach zwanzig Minuten ohne Verkehr. Er kommt zurück, sobald jemand eine Datei öffnet, also meldet ihn die Hälfte der Leute nie und die andere Hälfte meldet „das VPN ist langsam“. Geändert hat niemand etwas.

Zwei Leute im selben Haus können nicht beide verbinden. Der zweite kommt hoch, der erste geht runter. Sie rufen getrennt beim Service Desk an, also treffen sich die Tickets nie und vierzehn Tage lang fällt das Muster niemandem auf.

Kleines geht, Großes hängt. Anmelden geht. Teams geht. Ping geht. Eine Datei zu kopieren bleibt jedes Mal an derselben Stelle stehen, und eine große Seite in einer internen Anwendung hängt, bis sie in den Timeout läuft.

Der Tunnel steht und es fließt nichts. Beide Seiten sagen „established“. Beide Seiten sind zufrieden mit sich. Es bewegt sich nichts.

Von außen kommt nichts herein. Site-to-Site zur Filiale, die auf einen Glasfaser-Altnet gewechselt ist, baut sich nicht mehr in der Richtung auf, in der es früher ging, und niemand kann sagen warum, nur dass „deren IP sich geändert hat“.

QoS einzuschalten hat die Verschlüsselung kaputtgemacht. Jemand hat Sprache priorisiert, und jetzt verwirft die Gegenstelle Pakete als Replays.

Nichts davon ist eine Fehlkonfiguration im gewöhnlichen Sinn. Jeder einzelne Punkt ist IPsec, das auf das Netz trifft, wie es heute ist. Der Rest dieses Beitrags ist das Warum, der Reihe nach, und wie du nachweist, welchen Fall du hast.

IPsec wird nicht vom Netz getragen. Es ist das Netz.

Fang damit an, was es war, denn der Entwurf ist wirklich gut und die Fehler ergeben nur vor diesem Hintergrund Sinn.

ESP ist kein Protokoll, das über TCP oder UDP läuft. Es ist ein Transportprotokoll, IP-Protokollnummer 50, direkt auf IP, in genau dem Steckplatz, in dem auch TCP und UDP sitzen. AH ist Protokoll 51. Keines hat ein Portfeld, weil keines eines braucht: in dem Internet, für das IPsec entworfen wurde, bezeichnet die Zieladresse bereits genau eine Maschine, und der SPI im ESP-Header bezeichnet, welche Security Association auf dieser Maschine gemeint ist. Adresse plus Protokoll plus SPI. Dieses Tripel ist der Nachschlagevorgang¹.

Schau, was das einbringt. Es gibt keinen Handshake-Port, den man exponieren müsste, keine Sitzungsschicht, die man falsch machen kann, keine Anwendung, die mitmachen muss. Jedes Ende kann anfangen. Die Mitte des Netzes ist dumm, und genau das soll die Mitte eines Netzes sein. Ein Router leitet Protokoll 50 genauso weiter wie Protokoll 6, und dass er die Nutzlast nicht lesen kann, ist der Sinn der Sache und keine Einschränkung.

Ein sauberer Entwurf. Und zugleich, im Jahr 2026, die Beschreibung eines Internets, das die meisten, die das lesen, gar nicht kaufen können.

Dann hat jemand in jeden Pfad einen Übersetzer gestellt

Ein NAT schreibt die Quelladresse um, oft auch den Quellport, damit sich mehrere Maschinen eine Adresse teilen. Mehr macht es nicht. Gegen IPsec ist das beinahe ein vollständiger Abriss, und die IETF war ehrlich genug, dazu ein ganzes Dokument zu veröffentlichen, das die Einzelteile auflistet: RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements⁴. Sechzehn getrennte Unverträglichkeiten. Hier die, auf die es ankommt.

AH ist erledigt, konstruktionsbedingt. In den Worten von RFC 3715: „Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check.“⁴ — der AH-Header nimmt Quell- und Zieladresse in die Integritätsprüfung auf, also macht jede Adressänderung die Prüfung ungültig. Dafür gibt es keine Lösung, und es sollte auch nie eine geben. Ein Protokoll, das den Header signiert, kommt nicht durch eine Box, deren ganze Aufgabe das Umschreiben des Headers ist. AH wurde nicht umgangen. Es wurde aufgegeben.

Es gibt keine Ports zum Übersetzen. Ein NAT, das Portübersetzung macht, braucht einen Port. ESP hat keinen. Cisco schreibt es im Catalyst-Konfigurationshandbuch unverblümt hin: „If PAT found a legislative IP address and port, it would drop the Encapsulating Security Payload (ESP) packet.“⁵ Das Paket wird nicht aus Richtliniengründen abgewiesen. Es wird verworfen, weil die Box nichts hat, wohin sie schreiben könnte, was sie schreiben muss.

Die Identität passt nicht mehr zum Paket. Wieder aus RFC 3715: „Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header.“⁴ — werden Adressen als Bezeichner verwendet, passt nach der Übersetzung der Bezeichner nicht mehr zum Header. Ein Identitätsschema, das Maschinen über Adressen benennt, überlebt kein Gerät, das Maschinen beruflich umbenennt.

Zwei Maschinen können denselben SPI wählen. Der SPI wird vom Empfänger gewählt und muss nur bei ihm eindeutig sein. Setz zwei Hosts hinter eine Adresse, und der Übersetzer hat zwei Associations, die er nicht auseinanderhalten kann.

Von außen kann nichts anfangen. Ein NAT baut seine Tabelle aus ausgehenden Paketen auf. Es gibt kein ausgehendes Paket, bevor jemand anfängt, und auf einer NAT-Leitung kann nur die Innenseite anfangen. Die halbe Symmetrie des Protokolls ist weg.

Die Lösung war echt, und jeder Teil davon hat etwas gekostet

NAT-Traversal funktioniert. Das bestreite ich nicht, und ich tue auch nicht so. Ich habe reichlich Tunnel durch reichlich NATs betrieben. Was ich festhalten will, ist die Rechnung, denn sie wird täglich von allen bezahlt und fast niemand listet sie auf.

Der Mechanismus ist RFC 3948: erkenne beim Schlüsselaustausch einen Übersetzer, und steck dann das ganze ESP-Paket in ein UDP-Datagramm auf Port 4500, damit der Übersetzer etwas hat, das er versteht⁶. Ciscos Beschreibung des Wire-Formats ist präzise: nach der Verschlüsselung werden „a UDP header and a non-IKE marker (which is 8 bytes in length) are inserted between the original IP header and ESP header“⁵ — ein UDP-Header und eine acht Byte lange Nicht-IKE-Markierung zwischen ursprünglichem IP-Header und ESP-Header eingefügt. Junipers Fassung ist kürzer und sagt dasselbe: „NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port.“⁷

Jetzt die aufgeschlüsselte Rechnung.

Der Authentication Header ist weg. Nicht höflich abgekündigt. Unbrauchbar. RFC 8221 sagt inzwischen klar, dass ESP zusammen mit AH NOT RECOMMENDED ist⁸, und der ehrliche Grund ist: das eine, was AH konnte und ESP nicht kann, ist genau das eine, was NAT zerstört.

Die UDP-Prüfsumme wird absichtlich auf null gesetzt. RFC 3948 verlangt es: bei umgeschriebenen Adressen würde eine darüber berechnete Prüfsumme scheitern, also lautet die Antwort des Standards, sie gar nicht erst zu berechnen. „If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header.“⁶ Eine Schicht Fehlererkennung entfernt, damit eine Schicht Adressumschreibung weiter funktioniert.

Du schickst jetzt Pakete, nur um eine Tabelle warm zu halten. RFC 3948 definiert einen Keepalive als ein Byte, 0xFF, gesendet, wenn sonst nichts innerhalb eines konfigurierbaren Intervalls hinausgegangen ist, dessen Vorgabe zwanzig Sekunden beträgt⁶. Juniper nennt den Grund ohne Schnörkel: „Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.“⁷ Ein Laptop im Zug, der gar nichts tut, sendet also alle zwanzig Sekunden, für immer, weil eine Tabelle in einer Box, die keinem der beiden Enden gehört, sonst vergisst, dass es ihn gibt. Multipliziere das mit einer Flotte. Das ist der Funk, der aufwacht, der Akku, der leerer wird, und das Mobilfunknetz, das Verkehr trägt, dessen einziger Zweck es ist, Vergessen zu verhindern.

Du firewallst jetzt zwei Ports statt eines Protokolls, und Ciscos eigene Einschränkungsliste verlangt statische Übersetzungsregeln für 500 und 4500, bevor überhaupt irgendetwas davon funktioniert⁵.

Und lies den Rest dieser Einschränkungsliste, denn da erklärt dir der Hersteller die Form der Sache. Dynamische NAT-Richtlinien: nicht unterstützt. IPv6-Verkehr: mit dem Feature unverträglich. IPsec und NAT auf demselben Gerät: beides zusammen geht nicht⁵. Das ist kein Konfigurationshandbuch. Das ist eine Liste der Stellen, an die das Gerüst nicht reicht.

Elegant ist daran nichts, und schuld ist auch niemand im Besonderen. Es ist, was passiert, wenn man ein Layer-3-Protokoll auf einem Netz am Leben hält, das aufgehört hat, Layer 3 zu achten.

Carrier-Grade NAT hat den Rest weggenommen

Gewöhnliches NAT hat die Adresse von der Maschine genommen und dem Standort gegeben. Der Übersetzer gehörte immer noch dir, du konntest also einen Port weiterleiten, ein Mapping festnageln, einen Timer verlängern oder den Konzentrator davorstellen.

Carrier-Grade NAT nimmt die Adresse dem Standort weg und gibt sie mehreren hundert Fremden, und der Übersetzer gehört deinem Provider. Alles, was du früher dagegen tun konntest, kannst du jetzt nicht mehr.

Und sei dir klar, was tatsächlich im Pfad steht, denn genau das verstehen die Leute falsch. Der Router im Haus macht weiterhin NAT. Er wurde nicht abgeschaltet. Er übersetzt deinen Laptop auf 192.168.1.20 weiterhin auf die Adresse, die die Leitung hält — nur hält die Leitung jetzt 100.64.12.7, geteilten Adressraum, keine öffentliche Adresse. Der Carrier übersetzt das dann noch einmal. Das Paket durchquert also zwei Übersetzer, bevor es das Internet erreicht, und das ist der Normalfall, nicht die Ausnahme.

Du bist doppelt genattet, und nur eine der Tabellen gehört dir. Zwei Übersetzungen heißen zwei Mapping-Tabellen, zwei Alterungstimer und zwei Gelegenheiten, dass das Mapping verschwindet. Dein Keepalive muss den schlagen, der zuerst abläuft, und lesen kannst du genau einen davon. Schlimmer noch, die beiden greifen ineinander: der Router im Haus hat womöglich eigene Vorstellungen von IPsec und versucht mit einem Application Gateway zu helfen, sodass der Quellport, den dein Client zu benutzen glaubt, weder der ist, der das Haus verlässt, noch der, der den Carrier verlässt.

Portweiterleitung funktioniert weiterhin und bewirkt überhaupt nichts. Das ist das Ticket, das am meisten Zeit frisst. Jemand leitet UDP 500 und 4500 am Heimrouter weiter, der Router nimmt es an, die Einstellungsseite sagt, die Regel sei aktiv — und nichts kann sie nutzen, weil sie von einer Adresse weiterleitet, die das Internet nicht erreicht. UPnP und PCP verhalten sich genauso: der Client bittet um ein Mapping, der Router gewährt es, und der Port öffnet sich auf einen Flur. Alles meldet Erfolg und nichts geht. Die Box erzählt dir, was du hören willst.

Am schnellsten klärst du es umsonst. Lies die WAN-Adresse im Router. Fängt sie mit 100.64 an, ist das der in RFC 6598 reservierte geteilte Adressraum, du sitzt hinter Carrier-Grade NAT, und die halbe Einstellungsseite ist Dekoration.

Die Responder-Rolle gibt es nicht mehr. Ein Gerät hinter CGNAT kann nicht das Ende sein, das jemand anwählt. Site-to-Site zwischen zwei Filialen an Consumer-Glasfaser — normal, günstig und genau das, was ein kleines Unternehmen will — verlangt, dass mindestens ein Ende eine echte Adresse hält, oder einen Dritten in der Mitte, der sie einander vorstellt. Dieser Dritte ist eine Firma, von der du jetzt abhängst, weil dein Provider dir keine Adresse geben wollte.

Der Timer gehört jemand anderem. RFC 4787 sagt NAT-Betreibern, ein UDP-Mapping „MUST NOT expire in less than two minutes“, und empfiehlt fünf oder mehr⁹. Das ist die Untergrenze und die Empfehlung, kein Versprechen, und was dein Carrier tatsächlich macht, kannst du nicht nachsehen. Als solches hört der Keepalive auf, eine Stellschraube zu sein. Er ist tragend, auf einem Timer, den du rätst.

Die Identität deines Peers kann nicht seine Adresse sein. Mehrere Anschlüsse erreichen die Gegenstelle als eine Adresse. Was der Konzentrator auch benutzt, um sie auseinanderzuhalten, es ist nicht der IP-Header — und genau den sollte IPsec benutzen.

Es gibt eine harte Obergrenze, und die Hersteller veröffentlichen sie. Juniper hält für SRX5400, SRX5600 und SRX5800 fest: „the total number of tunnels from a given public translated IP cannot exceed 1000 tunnels“⁷. Lies das als Betreiber und nicht als Spezifikationszeile. Dein VPN-Konzentrator hat ein Limit je geteilter Adresse, das Teilen erledigt ein Carrier, mit dem du keinen Vertrag hast, und wie nah du an diesem Limit bist, hängt davon ab, wie viele deiner Nutzer zufällig hinter demselben sitzen. Es gibt keinen Zähler, in den du schauen kannst. Es gibt nur den Tag, an dem es für einige Leute anfängt zu scheitern und für andere nicht.

Alles in diesem Abschnitt ist Folge einer Entscheidung, die dieses Land getroffen und immer wieder getroffen hat. Ich habe das anderswo vollständig ausgeführt und wiederhole es nicht. Der Punkt hier ist enger: die Kernannahme von IPsec wurde vom Zugangsnetz gelöscht, und IPsec lebt seitdem von Behelfslösungen.

Und das IPv6-only-Netz rettet es auch nicht

Hier muss ich gegen mein eigenes Argument ehrlich sein, denn die naheliegende Antwort auf alles oben lautet: gut, dann gib jeder Maschine eine echte IPv6-Adresse und IPsec funktioniert wieder wie spezifiziert.

Tut es, zwischen zwei Enden, die beide eine haben. Das ist nicht das Netz, in dem die meisten sitzen.

Die IPv6-only-Zugangsnetze, die es wirklich gibt, allen voran Mobilfunk, erreichen das IPv4-Internet über NAT64, und das ist im gewöhnlichen Sinn gar kein NAT. Es ist ein Protokollübersetzer, der ein IPv6-Paket in ein IPv4-Paket umschreibt. Und RFC 6146 benennt, was es trägt, und benennt, was es nicht trägt, ganz ohne Mehrdeutigkeit:

„The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification.“¹⁰

IPsec, namentlich, außerhalb des Geltungsbereichs. Und Pakete, die irgendetwas außerhalb dieser Liste tragen, „SHOULD be discarded“¹⁰.

Auf einem IPv6-only-Telefon oder -Laptop, das einen IPv4-Konzentrator erreichen will — und das sind die meisten Konzentratoren —, wird natives ESP also nicht von einer Firewall verworfen oder von einem Übersetzer verstümmelt. Es wird von vornherein nicht transportiert. Der Übersetzer tut genau das, was sein Standard ihm vorschreibt.

Die Antwort der Branche darauf ist zwangsläufig eine weitere Schicht: 464XLAT, das dem Gerät einen lokalen IPv4-Stack gibt und zweimal übersetzt, aus IPv4 heraus und wieder hinein, damit das, was NAT64 nicht tragen kann, trotzdem läuft¹¹. Es steht schon auf der Liste der Anbauten im IPv6-Beitrag und ich argumentiere das nicht neu. Erwähnenswert ist hier die Form: ein Protokoll, das 2004 an NAT zerbrach, zerbricht auch an der Übersetzung, die 2011 für den IPv6-Übergang gebaut wurde, und beides wird damit beantwortet, es in etwas anderes einzupacken.

Das ist die Prüfung, die ein Protokoll bestehen muss, um 2026 hierher zu gehören. Funktioniert es in dem Netz, das die Leute wirklich haben — hinter der geteilten Adresse eines Carriers, in einem IPv6-only-Mobilfunknetz, durch ein Hotel, das nur TCP 443 durchlässt? Alles, was auf einem UDP-Port aufsetzt, besteht alle drei, ohne dass man es ihm sagen müsste. IPsec braucht für jede eine andere Behelfslösung, und für die dritte zusätzlich TCP-Kapselung³.

Keine Ports heißt auch keine zweite Leitung

Hier ein Fehler, der mit NAT nichts zu tun hat, rein modern ist und fast keine Aufmerksamkeit bekommt.

Router und Switches verteilen Verkehr über parallele Pfade. Link Aggregation, Equal-Cost Multipath: beide funktionieren gleich, über einen Hash des Fünf-Tupels. Quelladresse, Zieladresse, Protokoll, Quellport, Zielport. ESP hat keine Ports. Also hasht jedes Paket eines Tunnels zwischen denselben zwei Adressen identisch, und der ganze Tunnel landet auf einer Mitgliedsleitung, egal wie viele du gekauft hast.

Zwei 10G-Leitungen und ein IPsec-Tunnel geben dir 10G. Vier geben dir 10G. Die Hardware arbeitet genau wie entworfen.

Die Behelfslösung hat die gewohnte Form. Manche Silizium kann stattdessen über den SPI hashen, denn jeder SPI benennt eine Association und damit einen Fluss, aber das ist ein Feature, das man gekauft haben muss, und nichts, was man von einem Pfad annehmen kann, der einem nicht gehört. Es gibt einen aktiven IETF-Entwurf, dessen einziger Zweck es ist, ESP in noch einen UDP-Header zu packen, damit gewöhnliche Router es hashen können, und er sagt in einem Satz warum: „Although the ESP SPI field within the IPsec packets can be used as the load-balancing key, but it cannot be used by legacy switches and routers.“¹² Seine Problembeschreibung ist genauso unverblümt darüber, was die Leute stattdessen tun: „Many cloud service providers allow customers to establish multiple IPsec VPN tunnels in parallel to enable ECMP and increase aggregate bandwidth. However, this approach is not ideal, as each tunnel typically requires its own public IP address, leading to higher public IP consumption and increased operational overhead.“¹²

Lass das kurz wirken. Der empfohlene Weg, eine verschlüsselte Strecke schneller zu machen, ist, mehrere davon zu bauen, jede mit einer verbrannten öffentlichen IPv4-Adresse — während einer Adressknappheit —, weil das Protokoll keine Portnummer zum Hashen hat. Ein UDP-basierter Tunnel bekommt Multipath derweil geschenkt, von Hardware, die vor fünfzehn Jahren ausgeliefert wurde, weil er einen Port hat wie alles andere im modernen Internet.

Das ist kein Altlastproblem, das von selbst ausläuft. Das ist eine reale Grenze für Neubauten, heute, bei genau den Geschwindigkeiten, die gerade gekauft werden.

Die MTU-Steuer, und wer sie zahlt

Jeder Tunnel kostet Bytes. IPsec kostet mehr als die meisten, und die Art, wie es scheitert, wenn es knapp wird, ist die schlimmste Sorte Fehler: sporadisch, größenabhängig und unsichtbar für jeden Test, den man zuerst laufen lässt.

Rechne es für eine Konfiguration durch, statt zu wedeln. ESP im Tunnelmodus über IPv4 mit AES-GCM: 20 Byte äußerer IP-Header, 8 ESP-Header, 8 Nonce, mindestens 2 Trailer, 16 Integritätsprüfwert. 54 Byte, bevor irgendetwas von deinem Paket hineingeht. Pack es für NAT-Traversal ein, und der UDP-Header macht 62 daraus. Auf einem 1500-Byte-Pfad bleiben 1438, und sobald irgendwo davor PPPoE mit 1492 läuft, bist du wieder darunter.

Und dann der Teil, der daraus einen Fehler statt einer Rechenaufgabe macht. Ein Sender erfährt nur dadurch, dass ein Paket zu groß war, dass ein ICMP-Fehler zurückkommt — Fragmentation Needed bei IPv4, Packet Too Big bei IPv6. Verwirft irgendetwas im Pfad diese Fehler, erfährt es der Sender nie und schickt weiter Pakete, die weiter sterben. Das ist das klassische schwarze Loch: der Handshake geht durch, weil Handshakes klein sind, und die Übertragung hängt, weil Übertragungen es nicht sind.

Cisco pflegt dazu seit der GRE-und-IPsec-Zeit ein ganzes Dokument, und es ist immer noch eine der besseren Erklärungen dieses Zusammenspiels in irgendjemandes Bibliothek¹³. Es muss gepflegt werden, weil die Leute weiter pauschal ICMP blockieren und sich dann wundern, warum Tunnel sich seltsam benehmen.

Die zwei Hälften dieses Arguments habe ich schon ausgeschrieben und sie gelten hier ohne Wiederholung: welche ICMP-Nachrichten tragend sind und welche nicht, in Ping: das Diagnosewerkzeug, das viel mehr öffnet, und wie du den genauen Hop findest, der deinen Verkehr frisst, in Die Firewall ist elf Hops entfernt. Die Kurzfassung für diesen Beitrag: die Fehler sind der Mechanismus, Echo ist es nicht, und eine Grenzrichtlinie, die ganz ICMP verwirft, hat dein VPN auf eine Weise kaputtgemacht, die dem VPN angelastet wird.

Und deine eigene Dienstgüte kann es kaputtmachen

Noch einer, denn der erwischt gute Ingenieure, die das Richtige tun.

ESP trägt eine Sequenznummer, und der Empfänger führt ein Replay-Fenster von auf Cisco-Plattformen standardmäßig 64 Paketen¹⁴. Priorisiere jetzt Sprache auf dem sendenden Router. Low Latency Queueing tut, worum du gebeten hast, und ordnet Pakete gegenüber der Reihenfolge um, in der sie verschlüsselt wurden. Fällt ein Paket bei der Ankunft aus dem Fenster, verwirft die Gegenstelle es als Replay, und der Zähler, der hochgeht, ist ein Sicherheitszähler.

Ciscos eigene Worte: „Certain QoS features, such as Low Latency Queueing (LLQ), could cause IPsec packet delivery to become out-of-order and dropped by the receiving endpoint due to a replay check failure.“¹⁴ Ihre Antwort lautet, das Fenster auf 1024 zu verbreitern, wo die Plattform das hergibt, oder eine Erweiterung mit mehreren Sequenznummernräumen einzusetzen, die QoS-Klassen auf getrennte Sequenzräume innerhalb einer Association abbildet¹⁴.

Also: ein Standardfeature deines eigenen Netzes einzuschalten macht deinen eigenen Tunnel kaputt, und das Gegenmittel ist noch eine Protokollerweiterung. Dieselbe Form wie alles oben.

L2TP: Einwahl-Framing, verschlüsselt, im Jahr 2026

L2TP ist kein Sicherheitsprotokoll und hat das nie behauptet. RFC 2661 ist ein Tunnelprotokoll zum Transport von PPP-Sitzungen, veröffentlicht 1999, ohne eigene Vertraulichkeit — sein eigener Sicherheitsabschnitt verweist dich für Schutz auf Paketebene auf IPsec¹⁵. Diese Paarung ist RFC 3193, und das Ergebnis ist der Stapel aus dem Diagramm oben: ein äußerer IP-Header, ein UDP-Header für NAT-Traversal, ESP, dann innerhalb der Verschlüsselung noch ein UDP-Header auf Port 1701, ein L2TP-Header und ein PPP-Header.

PPP. Das Framing von Einwahlmodems, getragen in einem verschlüsselten Tunnel, über das Internet, im Jahr 2026, weil L2TP genau dafür geschrieben wurde.

Rechne durch, was das an einem Beispiel kostet — äußeres IP 20, UDP 8, ESP-Header und IV 24, inneres UDP 8, L2TP 6, PPP 4, Trailer und Prüfwert 18 — und du gibst rund 88 Byte pro Paket aus, um Daten zu bewegen, die natives ESP für 54 bewegt. Vierunddreißig Byte, auf jedem Paket, für eine Sitzungsschicht, die nichts hinzufügt, was du wolltest, und eine Verbindungsschicht, die für eine Telefonleitung entworfen wurde.

Der Overhead ist noch das Geringste.

Es multipliziert das NAT-Problem, statt es zu teilen. L2TP/IPsec nutzt üblicherweise ESP im Transportmodus, also den Modus, dem NAT am meisten zusetzt, und das bekannte Ergebnis ist, dass viele Implementierungen zwei Clients hinter einer Adresse überhaupt nicht unterstützen. Zwei Leute in einem Haus, oder vierzig in einem Büro, oder mehrere hundert hinter der geteilten Adresse eines Carriers. Die Gegenstelle sieht eine Adresse und kann die Sitzungen nicht auseinanderhalten, also ersetzt die zweite Verbindung die erste. Das ist das Ticket vom Anfang dieses Beitrags, und es ist kein Fehler in irgendjemandes Produkt — es ist das Identität-über-Adresse-Problem, das genau dort ankommt, wo die meisten Leute ihm begegnen.

Und im Feld wird es meist mit einem gemeinsamen Geheimnis für alle ausgerollt. Weil das Geheimnis im Client-Profil konfiguriert und mit der Einrichtungsanleitung verteilt wird, steht der Pre-Shared Key im Onboarding-Dokument, auf der Wiki-Seite, in der E-Mail an neue Kollegen und auf jedem Laptop, der je das Haus verlassen hat. Das ist kein zweiter Faktor. Das ist ein Passwort, das das Gateway gegenüber niemandem im Besonderen authentifiziert und noch nie gewechselt wurde.

L2TP ist kein Protokoll, das schlecht gealtert ist. Es ist ein Protokoll, das vom ersten Tag an das Falsche transportiert hat und an IPsec geschraubt wurde, um wettzumachen, was es überhaupt nicht konnte.

PPTP war nie sicher und wird immer noch verkauft

PPTP verdient zwei Absätze und keinen Abschnitt, und es bekommt sie nur, weil Leute es immer noch ausliefern.

Es war nie ein Standard. RFC 2637 ist Informational. Ein aufgeschriebenes Herstellerprotokoll, nichts, was die IETF je empfohlen hätte. Es trägt PPP in GRE, IP-Protokoll 47, das wie ESP keine Ports hat, also braucht es in jedem NAT auf dem Weg eine eigene Sonderbehandlung — das Häkchen „PPTP passthrough“, das auf sehr vielen Heimroutern genau eine Sitzung gleichzeitig unterstützt.

Die Sicherheit endete öffentlich 2012. Marlinspike und Hulton zeigten, dass sich die Sicherheit von MS-CHAPv2 unabhängig von der Passwortlänge auf eine einzige DES-Operation reduziert, bauten chapcrack, um den Handshake zu extrahieren, und hängten das an einen Cracking-Dienst, der den Schlüssel binnen eines Tages für zwanzig Dollar zurücklieferte — eine Erfolgsquote von 100 %, keine Wahrscheinlichkeit¹⁶. Ihr Schluss war, PPTP-Verkehr als unverschlüsselt zu betrachten. Apple stimmte mit den Füßen zu und entfernte PPTP 2016 aus dem eingebauten Client in macOS Sierra und iOS 10, und veröffentlicht die Warnung bis heute¹⁷.

Zehn Jahre danach ist PPTP immer noch ein Menüpunkt auf Routern, die dieses Jahr verkauft werden, immer noch in Hersteller-Anleitungen, immer noch das, was jemand einschaltet, weil es auf Anhieb funktioniert. Es funktioniert auf Anhieb, weil es die Aufgabe nicht erledigt.

Alles, was sich IPsec-VPN nennt

„IPsec-VPN“ ist kein Protokoll. Es ist eine Familie, und die Länge der Liste unten ist das Argument, denn keine zwei Produkte implementieren dieselbe Teilmenge davon, und in den Lücken zwischen diesen Teilmengen wohnt jede Interop-Arbeit, die du je gehasst hast.

Jetzt schau auf die zwei fett gesetzten Zeilen, denn die sollten dich aufhalten.

Fast zwei Jahrzehnte lang war der übliche Weg, einen Benutzer an einem Firmen-IPsec-VPN anzumelden, XAUTH — Benutzername und Passwort, dein Token, dein RADIUS-Server — mit Mode-Config, das dem Client Adresse, DNS-Server und Routen gibt. Zusammen sind sie das gesamte Fernzugriffserlebnis. Jeder „Cisco IPsec“-Client, jedes VPN-Symbol in einer Taskleiste, jede Beitrittsanleitung.

Keines von beiden ist ein Standard. XAUTH war ein individueller Internet-Draft, der 2001 ablief und archiviert wurde, ohne je ein RFC zu werden²⁶. Die angegebene Begründung lohnt das Lesen, denn da erklärt ein Gremium, warum es seine Arbeit nicht machen wollte: der Entwurf hält fest, dass die IPSRA-Arbeitsgruppe kein Protokoll akzeptieren würde, das ISAKMP oder IKE erweitert, und die IPsec-Arbeitsgruppe alles ablehnte, was mit Fernzugriff zu tun hatte²⁶. Der am weitesten verbreitete Teil des am weitesten verbreiteten VPN-Protokolls blieb also heimatlos, wurde trotzdem von jedem Hersteller nach eigener Lesart eines abgelaufenen Entwurfs implementiert und an Millionen Nutzer ausgeliefert.

IKEv2 hat am Ende beides in Ordnung gebracht, und das gehört gesagt: die Authentifizierung wanderte zu EAP und die Client-Konfigurationsnutzlasten in die Kernspezifikation²⁰. Aber lies die Jahreszahlen. Das meistgenutzte Feature des meistgenutzten VPN-Protokolls lief rund ein Jahrzehnt auf einem abgelaufenen Entwurf, bevor es überhaupt einen Standard hatte, und die installierte Basis lief danach noch jahrelang auf der Entwurfsfassung weiter. Eine Protokollfamilie bekommt keinen Bonus dafür, den Teil irgendwann zu standardisieren, den ohnehin alle benutzten.

Das ist die Familie, die du betreibst. Ein Teil davon ist Standards Track und aktuell. Ein Teil ist Historic. Ein Teil hat es nie zu irgendetwas gebracht. Und ein Produkt, auf dessen Datenblatt „IPsec-VPN“ steht, hat dir ungefähr nichts darüber gesagt, welche dieser achtzehn Dinge es kann — weshalb zwei davon zu verbinden vierzehn Tage, eine Tabelle voller Proposals und einen Anruf bei jemandem bedeutet, der das schon mal gemacht hat.

Das Fisher-Price OS (Windows) hat nie wirklich zusammengearbeitet

Das ist der Teil, an dem jemand sagt, das Problem sei eigentlich Linux, also machen wir es mit Quellen.

Standardmäßig verbindet sich der Windows-Client überhaupt nicht mit einem IPsec-Server hinter NAT. Nicht „hat Mühe“. Verweigert. Die Lösung ist ein Registry-Wert namens AssumeUDPEncapsulationContextOnSendRule unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent, auf 1 gesetzt, wenn der Server hinter einem Übersetzer sitzt, oder auf 2, wenn beide Enden dahinter sitzen, auf jedem Client und auf dem Server, gefolgt von einem Neustart³¹. Microsofts eigene Worte: „By default, Windows Vista and Windows Server 2008 don’t support Internet Protocol security (IPsec) network address translation (NAT) Traversal (NAT-T) security associations to servers that are located behind a NAT device.“³¹

Zwei Dinge dazu. Erstens hat Microsoft den NAT-Traversal-Standard, den es hier verweigert, mitverfasst. Ihr Name steht auf RFC 3947 und RFC 3948⁶. Zweitens wurde die Seite, die dir sagt, du sollst die Registry bearbeiten, zuletzt im Februar 2026 überarbeitet³¹. Zwanzig Jahre später ist ein Registry-Eingriff auf jedem Endgerät immer noch die Antwort, und sie wird immer noch als Antwort gepflegt.

Und lies den Satz, den Microsoft direkt darüber setzt: „If you must use IPsec for communication, use public IP addresses for all servers that you can connect to from the Internet.“³¹

Das ist dieser ganze Beitrag, in der Dokumentation des Herstellers. Setz IPsec nicht hinter NAT. Gib jeder Maschine eine echte Adresse. Sie haben es aufgeschrieben, und dann hat die Branche zwei Jahrzehnte das Gegenteil getan und die Differenz in Rechnung gestellt.

Bei NAT hört es nicht auf. Lies nach, was ein Open-Source-Gateway dokumentieren muss, um einen Windows-Client anzunehmen.

• Das Gateway-Zertifikat braucht eine Extended Key Usage, die es dafür und für sonst nichts gibt. serverAuth, OID 1.3.6.1.5.5.7.3.1, plus IP Security IKE Intermediate, OID 1.3.6.1.5.5.8.2.2³². Deiner CA muss beigebracht werden, eine OID auszustellen, von der die meisten Werkzeuge nie gehört haben, sonst scheitert die Verbindung mit einem Richtlinienfehler und ohne brauchbare Meldung.
• Ein zweiter Registry-Wert ist nötig, bevor der Client anständige Kryptografie anbietet. strongSwan dokumentiert, NegotiateDH2048_AES256 unter Rasman\Parameters hinzuzufügen, um AES-256-CBC und eine 2048-Bit-Gruppe zu bekommen³³. Lies das andersherum, denn so zählt es: ohne Registry-Eingriff ist das Standardangebot schwächer als das.
• Vom Server angestoßenes Rekeying wird von Clients hinter NAT abgelehnt, und die dokumentierte Behelfslösung ist, Rekeying auf dem Gateway abzuschalten und den Client anfangen zu lassen³³.
• Standard-IKEv2-Erweiterungen fehlen schlicht — keine IKE-Umleitung, keine mehrfachen Authentifizierungsrunden³³.

Nichts davon ist ein Linux-Fehler. Jeder einzelne Punkt ist ein Open-Source-Projekt, das aufschreibt, was es tun muss, um der Lesart eines Herstellers von einem Standard entgegenzukommen, den dieser Hersteller mitgeschrieben hat.

Das ist das Muster, und es ist dreißig Jahre alt. PPTP war Microsofts Protokoll, als Informational aufgeschrieben und nie standardisiert³⁰. MS-CHAPv2 und MPPE waren Microsofts Authentifizierung und Verschlüsselung, und beide wurden öffentlich gebrochen¹⁶. SSTP ist ein Microsoft-Tunnel, den sonst niemand terminiert. DirectAccess war IPsec und war konstruktionsbedingt an beiden Enden Windows — und ist inzwischen abgekündigt und wird entfernt, die Kunden werden auf Always On VPN geschoben³⁴. Keines davon war je ein Protokoll, bei dem der Rest von uns sich in der Mitte hätte treffen können. Es war ein Protokoll, dem man beitrat, und wenn du an beiden Enden nicht das richtige Betriebssystem betrieben hast, bekamst du den Registry-Eingriff, die seltsame OID und die Behelfsseite.

Also sage ich es klar, es ist schließlich mein Blog. Das Fisher-Price OS (Windows) war in einem offenen Protokollstapel nie ein echter Partner auf Augenhöhe, weil es nie dafür gedacht war. Es versteckt die Maschine vor der Person, die sie benutzt, und zwar als Entwurfsziel, und einen Stapel, den man nicht sehen kann, kann man nicht interoperabel machen. Wenn das das einzige Betriebssystem ist, das du je administriert hast, werden die Abschnitte oben über Kernel-Zähler und das Mitlesen auf der Leitung wie eine Fremdsprache geklungen haben, und genau das ist die Lücke — keine Vorliebe, eine Lücke.

Nichts davon muss den Leser etwas kosten. Jede Diagnose in diesem Beitrag läuft von jedem Unix im Netz aus, gerichtet auf das, was kaputt ist, und es ist ihr völlig gleich, was am anderen Ende läuft. Und wenn dieses Betriebssystem das einzige ist, das du hast, dann trägt der Diagnoseteil weiter unten auch die Werkzeuge dafür — die Aufzeichnung, die zwei Cmdlets und die Fehlercodes mit dem, was jeder davon wirklich sagt. Ein kaputter Tunnel muss am Montag trotzdem repariert werden. Und der Ersatz, für den ich am Ende argumentiere, hat dann einen Client, der sich auf jeder Plattform gleich verhält, diese eingeschlossen — zum ersten Mal seit dreißig Jahren gilt das für ein VPN.

Die Abkündigungsbilanz liest sich wie ein Nachruf

Leg die Behelfslösungen beiseite und lies einfach, was die Standardisierungsgremien dieser Familie über die Jahre angetan haben. Keine Meinung. Anforderungsstufen, in veröffentlichten RFCs.

Die vorletzte Zeile ist die, die ich jedem vorlegen würde, der mir erzählt, IPsec sei in Ordnung und das Netz sei das Problem. IPv6 hat IPsec ursprünglich vorgeschrieben — es war die Sicherheitsgeschichte, festgeschrieben in den Node Requirements. 2011 hat die IETF es sich anders überlegt: „Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture a SHOULD for all IPv6 nodes.“³⁶

Sogar die Adressfamilie, die IPsec alles zurückgegeben hätte, was NAT ihm genommen hat, hat vor fünfzehn Jahren aufgehört, es zu verlangen. Das ist nicht das Netz, das IPsec im Stich lässt. Das sind die Leute, die das Netz entworfen haben, und die entschieden haben, dass es sich das Gebot nicht verdient hat.

Die Komplexität wurde 1999 angemerkt, schriftlich

Nichts davon ist Nachsicht im Rückblick, und genau das macht es aufschreibenswert.

1999 wurden Niels Ferguson und Bruce Schneier beauftragt, IPsec zu bewerten. Ihr Bericht ist kurz, klar und lohnt sich ganz. Er beginnt mit „IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result.“³⁷ Er benennt die Ursache: „Our main criticism of IPsec is its complexity. IPsec contains too many options and too much flexibility; there are often several ways of doing the same or similar things. This is a typical committee effect.“³⁷

Und er machte drei Empfehlungen, die sich heute wie eine Liste von Dingen lesen, die ohnehin passiert sind, zwanzig Jahre zu spät und auf die harte Tour:

• Transportmodus abschaffen. „We therefore recommend that transport mode be eliminated.“³⁷ Der Transportmodus ist der Modus, den L2TP/IPsec benutzt, und der Modus, dem NAT am schlimmsten zusetzt.
• AH abschaffen. „We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality.“³⁷ Abgeschafft hat es stattdessen NAT, aus einem schlechteren Grund.
• Niemals Verschlüsselung ohne Authentifizierung zulassen. Sie warnten, Administratoren würden „will be quite likely to configure ESP for only encryption, believing that it provides security“ — ESP sehr wahrscheinlich nur auf Verschlüsselung stellen, im Glauben, das biete Sicherheit³⁷.

Acht Jahre später hörte der letzte Punkt auf, eine Warnung zu sein. Degabriele und Paterson veröffentlichten Angriffe, die „break any RFC-compliant implementation of IPsec making use of encryption-only ESP“ — jede RFC-konforme Implementierung brechen, die ESP nur mit Verschlüsselung nutzt, allein aus dem Chiffretext, und es braucht nicht mehr, als Verkehr mitzulesen und Pakete einzuspeisen³⁵. Die Vorhersage stand acht Jahre lang öffentlich im Raum, und der Standard erlaubte die Konfiguration weiterhin.

Das Urteil aus jenem Bericht von 1999 ist der Satz, zu dem ich immer wieder zurückkomme: „We have found serious security weaknesses in all major components of IPsec. As always in security, there is no prize for getting 90% right; you have to get everything right.“³⁷

Noch zwei Datenpunkte, dann lasse ich es gut sein.

Logjam, 2015. Das Team dahinter scannte eine 1-%-Stichprobe von IPv4 nach IKE und fand, dass 86,1 % der IKEv1- und 91,0 % der IKEv2-Server die 1024-Bit-Oakley-Gruppe 2 unterstützten und dass 66,1 % der profilierten IKEv1-Server sie bevorzugten. Ihr Schluss: eine Vorberechnung gegen eine zweite 1024-Bit-Gruppe „would allow decryption of traffic to 66% of IPsec VPNs“, und die veröffentlichten Geheimdienstunterlagen zur VPN-Ausnutzung seien „consistent with having achieved such a break“³⁸. Kryptografische Agilität, wovon IPsec am meisten hat, ist der Grund, warum fast alle fünfzehn Jahre lang auf derselben schwachen Gruppe saßen.

CVE-2016-1287. Ein Pufferüberlauf im IKEv1- und IKEv2-Code auf Cisco ASA, erreichbar durch das Senden präparierter UDP-Pakete, mit Codeausführung aus der Ferne vor der Authentifizierung³⁹. Denk daran, wo diese Box steht. Es ist das Gerät, das du absichtlich dem ganzen Internet ausgesetzt hast, auf dem das optionsreichste Protokoll im Bestand läuft, mit einem Fragment-Reassembler vor dem Parser, und das die Schlüssel zu allem dahinter hält. Die Komplexität, vor der Ferguson und Schneier gewarnt haben, ist keine Abstraktion. Sie ist Angriffsfläche, auf der einen Maschine, die du hinter nichts stellen kannst.

Diagnose, solange du es noch betreibst

Du kannst das alles nicht heute Nachmittag abschalten, also hier, wie man daran arbeitet. Das ist die Methode, in der Reihenfolge, die am wenigsten kostet, mit dem, was jedes Ergebnis tatsächlich bedeutet.

Schau zuerst auf die Leitung, nicht auf die Konsole

Beide Konsolen sagen dir, was sie glauben. Die Leitung sagt dir, was passiert ist. Eine Aufzeichnung an der Grenze, dreißig Sekunden, beantwortet die ersten drei Fragen auf einmal:

tcpdump -ni eth0 'udp port 500 or udp port 4500 or ip proto 50 or ip6 proto 50'

• Überhaupt nichts ausgehend — das Problem liegt vor IPsec: Routing, Policy oder eine Host-Firewall. Hör auf, bei der Kryptografie zu suchen.
• Nur ausgehend, nichts zurück — deine Pakete gehen raus und ihre Antworten kommen nicht an. Filterung unterwegs, ein toter Peer, oder die Gegenstelle weist stillschweigend ab.
• UDP 500 in beide Richtungen, 4500 taucht nie auf — NAT-Traversal wurde nicht ausgehandelt. Entweder hat es ein Ende abgeschaltet oder die Erkennung ist fehlgeschlagen.
• Protokoll 50 auf der Leitung, während ein Ende hinter NAT sitzt — die Aushandlung hat entschieden, es gäbe keinen Übersetzer, obwohl es einen gibt. Das kommt nie zurück.

Den Fehler beim Schlüsselaustausch lesen

IKEv2 sagt dir, warum es abgelehnt hat, und die Notify-Namen sind spezifisch genug, um allein daraus zu diagnostizieren. Es hilft, vorher die Form des ganzen Austauschs vor Augen zu haben, denn jede Notify unten gehört zu einer bestimmten Sprosse davon.

Junipers Phase-2-Anleitung sagt zum häufigsten davon dasselbe: „no proposal chosen“ heißt „the device did not accept any of the IKE Phase 2 proposals that the peer sent“, und die Lösung ist ein beiderseits akzeptables Proposal und kein wiederholter Neustart⁴⁰.

Auf strongSwan der Zustand von allem in einem Befehl:

swanctl --list-sas                 # what is established, and what it negotiated
swanctl --log                      # the negotiation as it happens

Auf Cisco show crypto ikev2 sa und show crypto ipsec sa, mit debug crypto ikev2, wenn es nicht hochkommt⁴¹. Auf Junos show security ike security-associations und show security ipsec security-associations, mit der Aushandlung in show log kmd-logs⁴².

Wurde NAT-Traversal überhaupt ausgehandelt?

Das ist die Prüfung, die die Leute überspringen, und sie erklärt einen großen Teil von „aus dem Büro geht es, von zu Hause nicht“.

Jedes Ende schickt Hashes der Adressen und Ports, die es für beteiligt hält. Passt der Hash, den die Gegenstelle aus dem empfangenen Paket berechnet, nicht zu dem, den du geschickt hast, liegt ein Übersetzer dazwischen, und beide Enden wechseln auf UDP 4500. Scheitert die Erkennung — eine Seite hat Traversal abgeschaltet, oder etwas in der Mitte verstümmelt den Austausch —, machen beide Enden mit nacktem ESP weiter, das den Übersetzer nicht überlebt.

Also: sieh Port 4500 in der Aufzeichnung, aus beiden Richtungen, oder es findet kein Traversal statt. Verlass dich nicht auf das Wort der Konsole.

Prüf dann, ob der Keepalive tatsächlich läuft und sein Intervall unter dem liegt, bei dem dein Carrier Mappings altern lässt. Die Vorgabe sind zwanzig Sekunden⁶; die Untergrenze des Standards für NAT-Betreiber sind zwei Minuten⁹; was dein konkreter Carrier macht, siehst du nicht. Stirbt der Tunnel nach Leerlauf und lebt bei Verkehr wieder auf, ist das jedes Mal dein Fall.

Die Kernel-Zähler, die fast niemand liest

Unter Linux führt die Transform-Schicht eine vollständige Fehleraufschlüsselung, und das ist der schnellste Weg, aus „es geht nicht“ eine konkrete Ursache zu machen. Die Zähler sind vom Kernel selbst dokumentiert⁴³.

cat /proc/net/xfrm_stat        # error counters, by cause
ip -s xfrm state               # per-SA packet and byte counters
ip xfrm policy                 # what should be protected, and in which direction

Als Weg liest es sich besser denn als Liste. Das Paket durchläuft fünf Stufen, und jede hat ihren eigenen Zähler:

Beobachte, welcher sich bewegt, während der Fehler auftritt:

XfrmInTmplMismatch und XfrmInNoPols sind die zwei, die man vom Sehen kennen sollte, denn beide heißen, dass die Kryptografie stimmt und die Policy nicht — also das Gegenteil von dem, wo alle zuerst suchen.

Es sagt „up“ und nichts bewegt sich

Beide Enden aufgebaut, kein Verkehr. Lies die Zähler je Association in beide Richtungen:

ip -s xfrm state

• Ausgehende Bytes steigen, eingehende flach — du verschlüsselst und sendest, und es kommt nichts zurück. Entweder erreicht dein ESP sie nicht oder ihres erreicht dich nicht. Frag die Gegenstelle nach ihrem Ausgangszähler; steigt der auch, sterben die Pakete unterwegs, und die nächste Frage lautet wo, und das ist eine TTL-Frage und keine Krypto-Frage.
• Beide flach — dem Tunnel wird nichts angeboten. Routing oder Policy, nicht IPsec. Bei route-based prüf, ob die Route wirklich auf das Tunnelinterface zeigt; bei policy-based prüf die Selectors.
• Beide steigen, Anwendungen weiter kaputt — es ist nicht der Tunnel. Geh und schau, was auf der anderen Seite steht.

Junipers Hinweis für diesen Fall folgt demselben Instinkt in ihrer Sprache: steigt nur der ausgehende Paketzähler der Sitzung, kläre mit dem Peer, ob der Verkehr überhaupt ankommt⁴⁴.

Kleines geht, Großes hängt

MTU. Es ist immer die MTU. Der Test dauert zehn Sekunden:

ping -M do -s 1400 10.0.0.1      # inside the tunnel, do-not-fragment set
ping -M do -s 1300 10.0.0.1      # step down until it succeeds

Wo es anfängt zu klappen, sagt dir die tatsächlich nutzbare Größe. Lass TCP es dann selbst herausfinden, indem du die angekündigte Segmentgröße auf den Pfad klemmst, statt zu hoffen, dass jeder ICMP-Fehler die Reise übersteht:

nft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu

Und beheb auch die Ursache, und das ist fast immer eine zu breite ICMP-Regel an irgendeiner Grenze. Verwirf Echo, wenn du willst. Ich habe anderswo dafür argumentiert, dass es das verdient. Aber behalte Fragmentation Needed und Packet Too Big. Sie sind der Mechanismus, keine Nettigkeit.

Es fällt im Takt aus

Nimm die Zeit zwischen den Ausfällen. Das Intervall benennt die Ursache von allein.

• Ein fester Zeitraum, der zu einer konfigurierten Lifetime passt — Rekeying. Die Association läuft ab und die Ersatzaushandlung scheitert oder läuft in ein Rennen. Prüf die Lifetimes beider Enden; abweichende Werte sind normal und in Ordnung, aber eine harte Lifetime auf einem Ende, die kürzer ist als die weiche des anderen, erzeugt genau das.
• Nach einer Weile ohne Verkehr, zurück bei der ersten Nutzung — ein NAT-Mapping ist abgelaufen. Keepalive-Intervall, oder das Fehlen eines solchen.
• Dead Peer Detection reißt ihn ab, während die Strecke in Ordnung ist — die Proben gehen verloren, statt dass der Peer tot wäre, oft weil die Proben der einzige Verkehr sind und das Mapping längst weg ist.

Der zweite Benutzer wirft den ersten raus

Zwei Peers erreichen den Konzentrator von einer Adresse und authentifizieren sich als dieselbe Identität. Das Gateway hat die Wahl zwischen der alten Association festhalten und ersetzen, und eine verbreitete Vorgabe ist ersetzen. Also gewinnt die zweite Verbindung und die erste stirbt stillschweigend.

Gib jedem Peer eine wirklich eindeutige Identität statt einer Adresse oder eines gemeinsamen Namens, und stell das Gateway so ein, dass es mehrere Associations von einer Adresse behält, statt eine je Peer anzunehmen. Und dann teste es auf die einzige Weise, die zählt: zwei Clients, eine Adresse, gleichzeitig. Wenn in deinem Abnahmetest nie zwei Nutzer hinter einem NAT saßen, hast du genau den Fall nicht getestet, in dem die meisten deiner Nutzer sind.

Dieselben Fehler, auf dem Fisher-Price OS (Windows)

Jede Prüfung oben läuft von einer Unix-Kiste aus, und wenn du eine in dem Netz hast, dann nimm sie, weil sie dir die Wahrheit schneller sagt und es ihr egal ist, was am anderen Ende läuft. Aber viele Leser haben einen Client, der sich nicht verbindet, ein Betriebssystem, das ihnen die Maschine absichtlich verbirgt, und sonst nichts zum Hinschauen. Also hier dieselbe Methode noch einmal, in derselben Reihenfolge, mit den Werkzeugen, die dieses Betriebssystem tatsächlich mitbringt.

Schau auf die Leitung. Es gibt kein tcpdump, aber es gibt eine Aufzeichnung. Erhöht starten, den Fehler nachstellen, stoppen:

netsh wfp capture start cab=on file=ipsec
netsh wfp capture stop

Das schreibt eine .cab. Darin steckt die Spur davon, was die Filterplattform und der Schlüsselaustausch währenddessen wirklich getan haben, und das ist mehr, als dir beide Konsolen zugeben. Für den Blick in Echtzeit statt eines Archivs schreibt dieselbe Befehlsfamilie mit file=- auf die Konsole: netsh wfp show state „Displays the current state of WFP and IPsec“, und netsh wfp show ikeevents „Displays recent Internet Key Exchange (IKE) epoch events matching the specified parameters“, gefiltert auf einen Peer⁴⁵.

netsh wfp show state file=-
netsh wfp show ikeevents remoteaddr=203.0.113.5 file=-

show ikeevents ist hier das Nächste an dem Austauschprotokoll, das jeder andere Stack ungefragt schreibt. Gut zu wissen, dass es das gibt. Sonst reicht dir die Oberfläche eine dreistellige Zahl und sonst nichts, und du diagnostizierst einen Schlüsselaustausch durch Raten.

Lies die Associations, und zwar beide. Die Entsprechungen von ip -s xfrm state und swanctl --list-sas sind zwei Cmdlets, und die Trennung dazwischen ist die ganze Diagnose:

Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

Main Mode ist der Schlüsselaustausch. Quick Mode trägt die Pakete. Microsoft sagt das Verhältnis deutlich: „There is only one main mode SA between a pair of computers, but there can be many quick mode SAs“⁴⁶. Main Mode vorhanden und Quick Mode leer ist also derselbe Fehler wie eine stehende IKE_SA ohne CHILD_SA darunter, und er bedeutet dasselbe: Die beiden Enden haben sich geeinigt, wie geredet wird, und sich dann nicht geeinigt, was geschützt wird. Schau auf die Traffic Selectors, nicht auf die Verfahren.

Lies die Protokolle, an den zwei Stellen, wo sie sich verstecken. Verbindungsfehler landen im Anwendungsprotokoll unter der Quelle RasClient, und Microsofts eigener Hinweis dazu ist der nützliche Teil: „All error messages return the error code at the end of the message“⁴⁷. Diese Zahl ist die Diagnose, und der nächste Abschnitt sagt dir, was die Zahlen bedeuten. Richtlinien- und Filterentscheidungen landen ganz woanders, unter Anwendungs- und Dienstprotokolle, in den Kanälen von Windows-Firewall mit erweiterter Sicherheit. Zwei Protokolle, zwei Teams, ein Fehler.

Sammle es richtig, wenn du eskalieren musst. Das unterstützte Bündel ist TSS — TSS.ps1 -Scenario NET_VPN auf dem Client, TSS.ps1 -Scenario NET_RAS auf dem Server, gestartet bevor du den Fehler nachstellst, und danach gestoppt⁴⁸. Lern es, bevor jemand danach fragt.

Wenn es auf Verbinden stehen bleibt und dann abläuft

Das ist der Fehler, der die Tickets füllt, und das Wort in der Meldung ist gelogen. Fang mit dem Code an. Der Code ist genau, auch wenn die Meldung nichts taugt.

Jeder davon stammt aus Microsofts eigener Fehlerliste⁴⁹. Jetzt lies 809 noch einmal. Er heißt ERROR_VPN_TIMEOUT, und die dokumentierte Ursache ist ein blockierter Port. Der Client läuft nicht ab, weil die Gegenstelle langsam ist. Er läuft ab, weil die Gegenstelle stumm ist, und Stille ist die einzige Fehlerart, die ein Protokoll ohne Ports und ohne sichtbaren Handshake melden kann.

Sei mit dem Wort blocked aber vorsichtig, denn es trägt mehr, als es kann. Drei verschiedene Dinge tragen es, und nur eines davon ist eine Verbotsregel.

Es hat nie jemand 4500 gesendet. NAT-Traversal wurde nicht ausgehandelt, also hat der Client weiter ESP gesprochen, und ESP gibt einem Übersetzer nichts zum Umschreiben. Die Voreinstellung auf dieser Plattform reicht dafür schon allein: Ohne den Registry-Wert bildet sie überhaupt keine NAT-T-Association zu einem Server hinter einem Übersetzer³¹. 4500 ist also nicht blockiert. Es wurde nie versucht.

Der Helfer, der das früher übertüncht hat, ist abgeschaltet. Firewalls und Heimrouter tragen protokollweise Helfer — IPsec-Passthrough auf Endkundengeräten und die ganze Familie der Application-Layer-Gateways dahinter —, die ein Protokoll lesen, das NAT nicht behandeln kann, und den Rückweg dafür öffnen. Unter Linux wurde die automatische Form davon ab Kernel 4.7 standardmäßig „for security reasons“ abgeschaltet, und die Empfehlung seither lautet, einen Helfer bewusst per Regel anzuhängen oder gar nicht; zu den abgedeckten Helfern gehört der für PPTP⁵⁰.

Und sie abzuschalten war richtig. Ein Helfer ist ein Stück deiner Firewall, das eine Nutzlast liest und dann anhand des Gelesenen ein Loch schlägt. NAT Slipstreaming ist die Rechnung dafür: ein Browser, der eine Seite aufruft, Verkehr so geformt, dass der SIP- oder H.323-Helfer des Routers ihn als Anruf liest, und ein Loch durch das NAT — in der Fassung von 2021 auf jede interne Adresse, nicht nur auf die Maschine, die die Seite geladen hat⁵¹. Helfer abzuschalten schließt das. Es bringt auch dein IPsec zum Erliegen. Beides stimmt gleichzeitig, und das Zweite ist kein Argument dafür, das Erste rückgängig zu machen.

Und das ist wieder dieser Beitrag im Kleinen. Das Protokoll hat nur funktioniert, weil Kästen in der Mitte Verkehr gelesen haben, der sie nichts anging, und in seinem Namen Löcher geöffnet haben, und die Branche hat im letzten Jahrzehnt völlig zu Recht beschlossen, damit aufzuhören.

Arbeite die Ursachen also in dieser Reihenfolge ab, das Billigste zuerst.

Erstens: Es kommt nichts zurück. Zeichne am Client auf, oder frag das Gateway. Wenn UDP 500 rausgeht und nichts zurückkommt, ist es Filterung oder Erreichbarkeit, und kein Timer der Welt behebt das. Wenn 500 in beide Richtungen durchgeht und 4500 nie auftaucht, wurde NAT-Traversal nicht ausgehandelt. Und wenn eines der beiden Enden hinter einem Übersetzer sitzt, bist du wieder bei dem Registry-Wert von weiter oben: AssumeUDPEncapsulationContextOnSendRule, 1 oder 2, auf beiden Maschinen, dann ein Neustart³¹. Ohne ihn verweigert der Client planmäßig und meldet es als Timeout.

Zweitens: Die Antwort ist zu groß, um anzukommen. Das hier kostet ganze Nachmittage. Zertifikatsanmeldung macht den zweiten Austausch groß, weil er eine Kette trägt, und ein großer Austausch fragmentiert. Die Fragmente werden von denselben Mittelkästen verworfen wie alles andere in diesem Beitrag, der Client sendet in dasselbe Loch nach, und dann gibt er auf und sagt Timeout. Das Anzeichen ist für sich genommen schon die Diagnose: ein Pre-Shared Key verbindet sich und ein Zertifikat nicht. Das ist kein Zertifikatsfehler. Das ist ein Größenfehler, weil der Austausch mit Pre-Shared Key klein genug ist, um zu passen. Genau dafür gibt es die standardisierte IKEv2-Fragmentierung²³, und strongSwan hält fest, wann diese Plattform sie bekommen hat: „IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server“³³. Alles Ältere, oder ein Gateway mit abgeschalteter Fragmentierung, und du verlässt dich auf einen Pfad, der ein fragmentiertes UDP-Datagramm trägt. Viele tun das nicht.

Drittens: Es verbindet sich und fällt dann im Takt aus. Nimm die Zeit. Stirbt es nach einer festen Leerlaufzeit, ist das 828 und es ist Konfiguration, kein Fehler — -IdleDisconnectSeconds auf dem Server, dazu -SALifeTimeSeconds, -MMSALifeTimeSeconds und -SADataSizeForRenegotiationKilobytes als die drei weiteren Uhren, die eine Sitzung beenden können⁵². Die letzte beendet sie nach Menge statt nach Zeit, und deshalb kann eine Sitzung bei einer großen Dateikopie zuverlässig sterben und an einem ganzen Tag E-Mail nie. Und stirbt sie beim Rekeying mit dem Client hinter NAT, ist das der dokumentierte Interop-Fehler von weiter oben: Der Client lehnt ein vom Server begonnenes Rekeying mit dem Microsoft-Fehler 13863 ab, und die Antwort auf der Gateway-Seite ist, es nicht mehr selbst zu beginnen und den Client machen zu lassen³³.

Viertens: Es ist gar nicht der Tunnel. 930 ist RADIUS. 812 ist ein Authentifizierungsverfahren, das der Server nicht akzeptiert hat⁴⁷. 13801 und 13806 sind Zertifikate — falsche erweiterte Schlüsselverwendung, abgelaufen, fehlende Wurzel, oder ein Servername, der nicht zum Antragsteller des Zertifikats passt⁴⁷. Die Tunnelaushandlung war in allen vier Fällen in Ordnung, und wenn du den Nachmittag mit Verfahren verbringst, findest du keinen davon.

Und das ist das Mitnehmbare an dieser Tabelle. Sechs Fehlercodes, fünf davon mit dem Wort timeout im Namen, und kein einziger ist tatsächlich ein Timeout. Es sind ein blockierter Port, ein verlorenes Fragment, eine Richtlinienentscheidung und ein RADIUS-Server, die alle dasselbe Wort tragen, weil die Schicht, die den Fehler meldet, zu wenig von dem sieht, was passiert ist, um etwas Nützlicheres zu sagen. Den Timer zu verlängern behebt keinen davon, und den Timer zu verlängern ist das, wozu die Oberfläche dich einlädt.

Was du stattdessen betreiben solltest

Ich tue nicht so, als wäre der Ersatz exotisch. Er steckt im Kernel und tut das seit Jahren.

WireGuard ist ein UDP-Port, ein Schlüssel je Peer, keine Chiffrenaushandlung und überhaupt keine Protokollagilität. Die Haltung des Autors dazu ist bewusst und ausgesprochen: „It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.“⁵³ Diese eine Entscheidung löscht NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD, Downgrade-Angriffe und den Logjam-Befund in einem Zug, weil es nichts auszuhandeln und nichts herabzustufen gibt.

Es ist auch ehrlich zum Preis, und ich bin es auch: keine Agilität heißt, dass du beim Fall eines Primitivs die ganze Flotte aktualisierst, statt eine Konfigurationszeile umzulegen. Das ist ein echter Betriebsaufwand und der richtige, den man zahlt.

Der Rest passt fast Punkt für Punkt auf die Liste oben. Einen UDP-Port zu haben heißt, dass NAT und CGNAT ihn wie jeden anderen Fluss behandeln und ECMP und LAG ihn wie jeden anderen Fluss hashen. Roaming ist eingebaut statt angeschraubt — ein authentifiziertes Paket von einer neuen Adresse verschiebt den Endpunkt des Peers, ein Telefon, das von WLAN auf Mobilfunk wechselt, handelt also nichts neu aus. Auf ein nicht authentifiziertes Paket antwortet es gar nicht, ein Scanner findet also einen geschlossenen Port, wo er bei IPsec einen Konzentrator zum Reden fände. Und es sind unter 4.000 Zeilen Code⁵³, gegen einen Stapel, für dessen sechzehn Unverträglichkeiten mit einer einzigen Middlebox es ein eigenes Dokument braucht.

Bei der Leistung war es in den Messungen schlicht schneller als beide IPsec-Konfigurationen, gegen die es getestet wurde: 1.011 Mbit/s gegen 881 und 825, bei geringerer Latenz⁵³. Ich würde ein Protokoll nicht wegen eines Benchmarks stilllegen. Ich erwähne es, weil das letzte verbliebene Argument für IPsec meist die Leistung ist, und das stimmt auch nicht.

Um eine Person an eine Anwendung zu bringen — und nicht ein Netz an ein Netz — ist die Antwort gar kein Tunnel. Identität an der Haustür, die Anwendung darüber veröffentlicht, nichts geroutet. Das habe ich mit Proxmox und Cloudflare Access in Zero-Trust-VDI ohne Cloud-Rechnung ausgebaut, und der für diesen Beitrag relevante Punkt ist: wer drei interne Anwendungen braucht, braucht keine Route in deinen gesamten Bestand.

Und sag den stillen Teil laut, was Hardware angeht. Ja, es gibt NICs und ASICs mit ESP-Offload, und das ist ein echtes Argument für IPsec auf bestimmter Hardware bei bestimmten Geschwindigkeiten. Es ist ein Argument über Silizium, das dir jemand schon verkauft hat, und keines darüber, dass das Protokoll richtig wäre. Als solches altert es, und zwar schnell. PPTP hat genau so überlebt, genau so lange, wie es das Häkchen gab.

Es richtig stilllegen

Stilllegung ist ein Plan mit Terminen, kein Gefühl. Hier der, für den ich meinen Namen hergeben würde.

Keine neuen IPsec-Ausrollungen mehr, ab jetzt. Nicht „Alternativen bevorzugen“. Schluss. Jeder neue Tunnel ist ein Tunnel, den später jemand migrieren muss, und die, die heute gebaut werden, laufen 2035 immer noch, wenn nicht diese Woche jemand Nein sagt.

Fernzugriff zuerst, denn dort schlägt jeder Fehler aus diesem Beitrag am härtesten ein: das CGNAT, die geteilte Adresse, die Keepalives, der zweite Nutzer im selben Haus, das MTU-Loch in irgendeinem Hotelnetz. Er ist außerdem am leichtesten zu bewegen, weil die Endgeräte verwaltet werden und die Änderung ein Client ist.

Dann Site-to-Site über das öffentliche Internet, dieselben Probleme mit weniger Endpunkten und einem Wartungsfenster.

Zum Schluss die Tunnel, bei denen dir nicht beide Enden gehören: ein Partner, eine Aufsichtsbehörde, der Managed Service eines Carriers. Die bewegen sich, wenn der Vertrag sich bewegt, und wie man sie in Bewegung bringt, steht im nächsten Punkt.

Kauf keine Hardware mehr, deren einziger Tunnel IPsec ist. Schreib es in die Ausschreibung. Eine Zeile, die einen modernen, portbasierten, roamingfähigen Tunnel verlangt, ist eine Zeile, die ein Hersteller beantwortet oder eben nicht, und so verliert das Argument der installierten Basis am Ende. Dieses Argument hält das alles als Einziges am Leben, und geschlagen wird es nur durch Einkauf.

Schreib auf, welche Tunnel übrig sind und warum, und setz auf jeden ein Datum. Ein Protokoll, für das sich zehn Jahre niemand zuständig fühlte, ist der Weg, auf dem PPTP bis 2026 gekommen ist. Eine Inventur mit Terminen ist der Unterschied zwischen etwas stilllegen und es bloß nicht mögen.

Wenn du es immer noch ausrollst, darfst du dich dann IT-Profi nennen?

Das ist eine echte Frage, und ich werde sie ehrlich beantworten, weil der Rest dieses Beitrags darauf zuläuft.

Es hängt davon ab, ob du es weißt. Und Wissen passiert dir nicht einfach. Dafür zu sorgen, dass du es weißt, ist die Arbeit.

Wenn du dieses Jahr einen neuen IPsec-Fernzugriff aufbaust und nicht aus dem Kopf sagen kannst, warum ESP keine Ports hat, was eine Hausanschlussleitung hinter Carrier-Grade NAT damit macht, warum ein NAT64-Netz es überhaupt nicht trägt, oder wofür dieses eine Byte alle zwanzig Sekunden eigentlich da ist — dann nein. Hierbei nicht, noch nicht. Du wählst kein Protokoll. Du wiederholst eine Form, weil die letzte so aussah und niemand im Raum gefragt hat, warum — du eingeschlossen. Das Versagen ist nicht die Lücke. Lücken hat jeder. Das Versagen ist, über eine zu bauen, die du nie geschlossen hast. Als solches bekommt die Person, die das 2035 erbt, ein Jahrzehnt Tickets, die alle vermeidbar waren an dem Tag, an dem du es gezeichnet hast.

Und ich gebe dem den richtigen Namen, denn die höfliche Fassung ist seit zwanzig Jahren im Umlauf und hat nichts geändert. Wer ein Protokoll ausrollt, das er nicht erklären kann, ist kein Ingenieur. Er ist ein Mitläufer. Er liest Karteikarten vor — die Referenzarchitektur des Herstellers, den letzten Change-Antrag, eine Zeichnung, die jemand 2014 gemacht und seither niemand mehr geöffnet hat —, und er liest sie mit echter Überzeugung vor, und hinter der Vorstellung steckt kein Verständnis. Von außen sieht das genau wie Kompetenz aus. Es sieht auch weiter genau wie Kompetenz aus, bis zum ersten Fehler, den die Karten nicht abdecken, und ab dem Moment ist es das Einzige im Raum, worauf es ankommt.

Die Karteikarten sind auch der Grund, warum dieses Protokoll noch da ist. Niemand hat 2026 am Whiteboard gestanden und IPsec sachlich verteidigt. Es wurde wieder ausgerollt, weil es auf der Karte stand, und die Karte hat ein Hersteller geschrieben, dessen Interesse darin besteht, dass du weiter die Kiste kaufst, die es terminiert. So überlebt etwas seinen eigenen Nachruf um zwanzig Jahre — nicht indem es verteidigt wird, sondern indem es kein einziges Mal in einem Raum Rechenschaft ablegen musste, in dem jemand den Unterschied bemerkt hätte.

Und das wird angesprochen. Laut, im Raum, in dem Moment — nicht hinterher auf dem Flur gemurmelt. Wer das Wort Profi neben seinen Namen stellt, bekommt mit dem Wort die Einladung, gefragt zu werden, und Fragen ist nicht unhöflich. Gefragt zu werden und eine Antwort zu haben ist der ganze Unterschied zwischen dem Wort und einer Visitenkarte.

Am meisten zählt das, wenn du dafür bezahlst. Eine Beratung, ein MSP, die Professional-Services-Abteilung eines Herstellers, der Integrator im Rahmenvertrag — was du kaufst, ist Urteilsvermögen, und Urteilsvermögen ist das Einzige, was du bei der Lieferung nicht prüfen kannst. Also prüfe es vorher. Frag, warum dieses Protokoll und nicht ein anderes. Frag, was mit ihm auf einer Leitung hinter Carrier-Grade NAT passiert, in einem reinen IPv6-Mobilfunknetz, auf einem Pfad, der stillschweigend Fragmente verwirft. Frag, welches davon sie selbst erlebt haben und was sie dann getan haben. Du weißt binnen zwei Minuten, ob dir etwas gesagt oder etwas vorgelesen wird, und zwei Minuten sind ein deutlich billigerer Test als vier Jahre Tickets. Und wenn die Antwort aus Karteikarten besteht und du trotzdem unterschreibst, ist das auch eine Entscheidung — sie ist nur gerade deine geworden und nicht mehr ihre.

Wenn du das alles sagen kannst und es trotzdem ausrollst, weil eine Aufsicht es namentlich vorschreibt, weil die Kiste des Partners nichts anderes terminiert, oder weil der Ersatz im Budget des nächsten Jahres steht und das hier im März laufen muss — dann ja, selbstverständlich, und du machst deine Arbeit richtig. Zwänge sind real, und ich habe um Schlimmeres herumgebaut. Was die beiden trennt, ist nicht das Protokoll auf der Zeichnung. Es ist, ob du aufgeschrieben hast, warum, und ob ein Datum daneben steht.

Nicht zu verteidigen ist die Mitte. Genug zu wissen, um ein ungutes Gefühl zu haben, und es trotzdem zu bauen, weil niemand dich zur Begründung gezwungen hat. Keine Ingenieurarbeit. Gewohnheit mit einer Änderungsnummer dran — und genau so ist L2TP auf ein Datenblatt geraten, das dieses Jahr gedruckt wurde.

Stell dir die Frage also vor der Ausschreibung und nicht danach. Profi ist kein Wort darüber, welche Protokolle du kennst. Es ist ein Wort darüber, ob du das gewählte laut verteidigen kannst, vor jemandem, der die Fehlerarten kennt. Wenn du das kannst, roll aus, was die Zwänge verlangen, und schlaf gut. Wenn nicht, hast du gerade gefunden, was du heute Abend lesen solltest, und das ist keine Beleidigung. Jeder war mal Mitläufer, ausnahmslos, ich eingeschlossen. Nicht zu verteidigen ist, es freiwillig zu bleiben und das eine Laufbahn zu nennen.

Eine gute Idee darf auch vorbei sein

Ich will IPsec gerecht werden, denn das hat es verdient.

Es war der richtige Instinkt. Sicherheit gehört tief in den Stapel, wo alles sie erbt und keiner Anwendung zugetraut werden muss, sie richtig zu machen. Die Association an die Adresse zu binden war 1995 kein Fehler — die Adresse war die Maschine, und darauf zu bauen war richtig. Die Leute, die es geschrieben haben, waren ernsthafte Leute mit einem echten Problem, und ausgerechnet das WireGuard-Papier bringt es am besten auf den Punkt: die Schichtung von IPsec ist stimmig, alles sitzt an seinem Platz, bis zur akademischen Perfektion⁵³.

Und dann hat sich der Boden bewegt. Nicht weil IPsec etwas falsch gemacht hätte, sondern weil diese Branche entschieden hat, Adressen seien ein zu verwaltender Kostenpunkt und nicht etwas, das jede Maschine bekommt, und fünfundzwanzig Jahre Übersetzung gebaut hat, um der Alternative auszuweichen. IPsec wurde still das Fundament entzogen, und statt das zuzugeben, haben wir unterlegt. UDP-Kapselung. Dann Keepalives. Dann TCP-Kapselung für die Netze, die UDP blockieren. Dann noch ein UDP-Header, damit ein Router etwas zum Hashen findet. Jede Lösung für sich vernünftig; der Stapel daraus ist ein Protokoll, das von Leuten aufrecht gehalten wird, die dafür bezahlt werden, es aufrecht zu halten.

Das ist der Teil, über den es sich zu ärgern lohnt, und er handelt eigentlich gar nicht von IPsec. Unsere Branche ist sehr gut darin, Dinge zu warten, und sehr schlecht darin, sie zu beenden. Wartung ist abrechenbar, budgetiert, besetzt und sicher. Stilllegung ist eine Entscheidung, die jemand unterschreiben muss, mit seinem Namen darunter, und ohne unmittelbaren Lohn. Also lebte PPTP vierzehn Jahre über den Beweis seiner Wertlosigkeit hinaus, L2TP wird immer noch auf Geräten ausgeliefert, die dieses Jahr verkauft werden, und IKEv1 handelte noch ein Jahrzehnt nach seiner Historic-Einstufung Tunnel aus. Nicht weil sie jemand verteidigt hätte. Sondern weil nie jemand verpflichtet war, sie zu beenden.

Es gibt keinen Preis dafür, 90 % richtig zu machen. Ferguson und Schneier schrieben das 1999 über IPsec, und was seitdem passiert ist, sind dreißig Jahre, in denen die Branche die letzten 10 % jedes Mal auf neue Weise falsch gemacht und das Pflaster eine Lösung genannt hat.

Eine gute Idee darf auch vorbei sein. Zu wissen, wann man aufhört, etwas zu warten, ist eine Fähigkeit, und es ist die, in der dieses Gewerbe am schlechtesten ist. Irgendjemand muss derjenige sein, der sagt, ein Protokoll hat sein Leben gehabt, der das Datum aufschreibt und die Folgen dafür trägt, derjenige gewesen zu sein, der es gesagt hat. Sonst schicken wir 2040 immer noch alle zwanzig Sekunden ein Ein-Byte-Paket, um eine Tabelle in einer Box warm zu halten, die uns nicht gehört, in einem Netz, das uns unsere Adressen weggenommen und uns dafür zur Kasse gebeten hat.