NO_PROPOSAL_CHOSEN bei L2TP? Prüfen Sie zuerst das Gateway

Die Benutzernamenabfrage erscheint nie, und der Client meldet NO_PROPOSAL_CHOSEN. Anmeldedaten und der vorab geteilte Schlüssel sind zu diesem Zeitpunkt irrelevant, weil sich beide Seiten nicht darauf geeinigt haben, wie Phase 1 geschützt werden soll. Die meisten Menschen reagieren, indem sie eine Cipher-Zeichenfolge einfügen, die sie online gefunden haben. Ein Scan des Gateways beantwortet dieselbe Frage mit Belegen und dauert ungefähr genauso lange.

Was die Meldung ausschließt

Die Ablehnung erfolgt im Hauptmodus, vor jedem L2TP- oder PPP-Austausch, sodass weder der Tunnel noch die Benutzerdatenbank befragt wurden. Phase 1 verhandelt Verschlüsselung, Integrität und eine Diffie-Hellman-Gruppe. Phase 2 verhandelt den ESP-Vorschlag für die Daten. Ein Fehler in Phase 1 lässt sich nicht durch Ändern einer PFS-Einstellung in Phase 2 beheben, und eine abgeschlossene IKE-Assoziation beweist nicht, dass der ESP-Vorschlag passt.

Notieren Sie das Backend, bevor Sie die Syntax bearbeiten: ipsec --version. libreswan und strongSwan akzeptieren für dieselben Algorithmen unterschiedliche Schreibweisen des Vorschlags.

Lesen Sie die Ablehnung dann im Zusammenhang mit journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Scannen Sie das Gateway auf sein Transform-Set

Ein Scanner fragt das Gateway direkt, welche Transformationen es verhandeln wird. Stoppen Sie zuerst den lokalen IPsec-Dienst, damit die Probe nicht mit Ihrem eigenen Client konkurriert, und lesen Sie dann die SA-Zeilen. Behandeln Sie die Liste als Beleg über den Peer, nicht als Menü zum vollständigen Aktivieren.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Ältere Geräte bieten häufig 3DES, SHA1 und MODP1024 an, weil das die Standardwerte waren, als das Produkt ausgeliefert wurde, und niemand sie überprüft hat. Bewahren Sie die rohe Scan-Ausgabe auf, denn sie ist der einzige Nachweis, was der Peer an diesem Tag angeboten hat. Wenn das die stärkste verfügbare Überschneidung ist, gehört die Eskalation an den Gateway-Betreiber, nicht an eine Client-Konfiguration, die schwache Kryptografie für alle wieder aktiviert.

Treffen Sie die Überschneidung, ohne die Sicherheit abzuschalten

Geben Sie nur die Transformationen ein, die sowohl im Scan als auch in Ihrer Richtlinie vorkommen. Das folgende Beispiel bildet ein Gateway ab, das in Phase 1 3DES, SHA1 und MODP1024 anbietet. Beachten Sie den Backend-Vorbehalt: libreswan 4.x kompiliert die modp1024-Gruppe nicht, daher gilt dies für strongSwan oder einen libreswan-Build mit DH2-Unterstützung. Prüfen Sie die Version, bevor Sie schließen, dass der Client defekt ist.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Ein Ausrufezeichen am Ende fixiert einen einzelnen Vorschlag. Nutzen Sie es, um einen Test zu isolieren, und entfernen Sie es danach, damit das Gateway später etwas Stärkeres verhandeln kann.

Prüfen Sie Daemon und Port, bevor Sie es erneut versuchen

NetworkManager-l2tp startet eine eigene xl2tpd-Instanz. Wenn der Systemdienst bereits UDP 1701 besitzt, weicht der Client auf einen kurzlebigen Quellport aus, was RFC 3193 erlaubt und manche Server stillschweigend verwerfen. Prüfen Sie den Socket-Eigentümer vor dem nächsten Versuch.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Veraltete generierte Secrets sind eine weitere stille Ursache. Dateien unter /etc/ipsec.d/, die nach einer alten Verbindung benannt sind, können das Profil überleben, das sie erzeugt hat; entfernen Sie daher die, auf die nichts verweist, und versuchen Sie es erneut.

Prüfen Sie schließlich, woher der Rat stammt. Eine ipsec.conf, die für IKEv1 XAuth geschrieben wurde, beschreibt einen anderen VPN-Typ, und ihr Vorschlag ist nicht die einzige Zeile, die in einem L2TP-Profil falsch sein wird. Notieren Sie das eingegebene Transform-Set neben dem Profil, damit die nächste Person die Probe nicht wiederholt.