Die Verbindung hängt, der Client beendet sich, und die letzte Zeile auf dem Bildschirm ist death_handler: Fatal signal 15 received. Diese Zeile meldet einen Abbruch, keine Ursache. Eine Zeile darüber steht im IPsec-Protokoll fast immer NO_PROPOSAL_CHOSEN, und das Paar deutet auf Phase 2 des Austauschs, in der beide Seiten Verschlüsselungs- und Hash-Verfahren vergleichen und aufhören, wenn sie keines gemeinsam haben. Anmeldedaten sind zu diesem Zeitpunkt noch nicht gesendet worden, ein erneutes Eintippen des Passworts kann das Ergebnis also nicht ändern.

Zwei Dinge leeren diese Schnittmenge auf einem Linux-Client meist. Der lokale Daemon implementiert die vom Profil angeforderte Diffie-Hellman-Gruppe womöglich nicht mehr, oder das Profil trägt einen Phase-1-Vorschlag im Feld für Phase 2. Beides hinterlässt Spuren im Protokoll, und keines davon ist ein Kontoproblem.

Was die beiden Meldungen tatsächlich aussagen

IKE verhandelt in Durchgängen. Phase 1 baut einen geschützten Kanal auf und wählt eigene Algorithmen; Phase 2, die Child-SA, überträgt Verkehr unter einem getrennten Satz. NO_PROPOSAL_CHOSEN ist die Benachrichtigung, die eine Gegenstelle zurückschickt, wenn keine der angebotenen Kombinationen akzeptabel ist, und erscheint als [ HASH N(NO_PROP) ] innerhalb eines INFORMATIONAL-Austauschs.

Signal 15 ist ein anderes Ereignis: Etwas hat den lokalen Prozess zum Anhalten aufgefordert, und der Handler hat es protokolliert. Treten beide Zeilen zusammen auf, ist die Reihenfolge kausal, zuerst die Ablehnung, dann das Herunterfahren.

Lesen Sie die Verhandlung, bevor Sie Anmeldedaten anfassen

Erhöhen Sie die Protokollstufe dort, wo der Daemon schreibt, und verbinden Sie sich dann erneut, während Sie die Ausgabe beobachten. Auf einem NetworkManager-Host reicht das L2TP-Plugin diese Stufe an das Backend weiter, und die Meldungen landen je nach Distribution im Journal oder in der klassischen syslog-Datei. Beides zeigt den Austausch: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' oder tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Eine Zeile mit pluto stammt von libreswan, charon von strongSwan, und beide beschreiben denselben Zustand mit anderen Worten. Die Form, nach der sich die Suche lohnt, ist die, die die fehlende Gruppe benennt, etwa algorithm 'modp1024' is not supported, weil sie aus einem vagen Fehler einen konkreten macht.

Wohin modp1024 verschwunden ist

Diffie-Hellman-Gruppe 2 ist so schwach, dass mehrere Distributionen sie ab 3.30 nicht mehr in libreswan kompilierten. Ein vor Jahren geschriebenes Profil, oder eines aus einer Gateway-Anleitung, die nur aes128-sha1-modp1024 auflistet, verlangt dann vom lokalen Daemon etwas, was dieser gar nicht leisten kann. Neuere NetworkManager-l2tp-Builds machen dieses Ergebnis wahrscheinlicher: Ab 1.2.16 ersetzen sie den Satz durch Vorschläge im Stil von Windows 10 und iOS und lassen modp1024 fallen, sobald libreswan erkannt wird. Die Gegenseite ist oft unschuldig und bietet weiterhin genau die Gruppe an, die Sie konfiguriert haben.

Diese Asymmetrie lässt den Fehler zufällig wirken. Ein älterer Client verbindet sich, dasselbe Profil auf einem aktualisierten Laptop nicht, und die Serverkonfiguration hat sich nie bewegt. Den Schaden verursacht die Versionsdrift.

Zwei Reparaturen mit unterschiedlicher Reichweite

Die billige Reparatur ist, Algorithmen nicht mehr fest zu verdrahten. Leeren Sie beide Vorschlagsfelder im Editor und lassen Sie das Plugin einen Satz wählen, den die Gegenstelle akzeptiert; unterstützt das Gateway moderne Gruppen, schließt die Verhandlung ohne weitere Arbeit ab.

Die zweite Reparatur hält ein altes Gateway erreichbar, indem strongSwan installiert wird, dessen Pakete Gruppe 2 auf den meisten Distributionen noch implementieren. Das ist ein Daemontausch und kostet etwas: Prüfen Sie, ob andere Tunnel auf dem Host von der libreswan-Konfiguration abhängen, bevor Sie sie entfernen, und rechnen Sie unter Fedora mit SELinux-Verweigerungen zwischen NetworkManager und dem strongSwan-Plugin. Diese Verweigerungen tauchen im Audit-Log auf, nicht in der IKE-Spur, weshalb ein Tunnel direkt nach einer erfolgreichen Installation kaputt aussehen kann. Die Reihenfolge, die funktioniert, ist zuerst dnf install strongswan, dann rpm -e libreswan.

Passende Vorschlagsreihen und die Fallen darum herum

Müssen die Felder von Hand gefüllt werden, nehmen Phase 1 und Phase 2 unterschiedliche Werte an. Ein Paar, das gegen eine Gegenstelle im Meraki-Stil nachweislich funktioniert, bietet in Phase 1 aes128-sha1-modp1024 mit 3des-sha1-modp1024 dahinter, beide abgeschlossen durch ein Ausrufezeichen, das den Satz strikt macht, sodass nur diese Vorschläge gesendet werden.

Phase 2 verengt sich dann auf aes128-sha1 und 3des-sha1 mit derselben strikten Markierung und ganz ohne Diffie-Hellman-Suffix. Eine Phase-2-Zeile mit -modp1024 ist ein Phase-1-Wert im falschen Feld, und die Gegenstelle weist sie bei jedem Versuch zurück. Kopieren Sie diese Zeile in ein zweites Profil, scheitert das zweite Profil genauso, und so wird aus einem Tippfehler ein flottenweiter Vorfall.

Andere Fehler tragen dasselbe Popup, ohne Vorschlagsunstimmigkeiten zu sein. Unter KDE kann der L2TP-Typ bei installiertem Plugin gelistet sein, während jede Verbindung sofort stirbt, weil der Verbindungseditor und die Laufzeithelfer als getrennte Pakete ausgeliefert werden. Headless-Hosts können ein Profil von einem funktionierenden Desktop übernehmen: Kopieren Sie es aus /etc/NetworkManager/system-connections/, setzen Sie den Modus auf 600 und führen Sie dann nmcli con reload aus. Bringen Sie es mit nmcli con up id work-l2tp hoch, da die nackte Form eine UUID verlangt, und entfernen Sie jeden veralteten ifname-Eintrag, sonst antwortet der Manager Could not find source connection, während sonst alles stimmt.

Ein vorab geteilter Schlüssel kann als Klartext oder als 0s gefolgt von base64 gespeichert werden; beide Formen funktionieren, aber der Wert muss Byte für Byte zum Gateway passen, einschließlich der Leerzeichen am Ende, die Sie mitkopiert haben.

Ähnliche Artikel