NO_PROPOSAL_CHOSEN på L2TP? Skanna gatewayen först

En L2TP/IPsec-klient som misslyckas före användarnamnsprompten har aldrig kommit överens om fas 1. Skanna gatewayens förslagsuppsättning i stället för att klistra in chiffersträngar.

Användarnamnsprompten visas aldrig, och klienten rapporterar NO_PROPOSAL_CHOSEN. Vid det laget är inloggningsuppgifterna och den fördelade nyckeln irrelevanta, eftersom de två ändarna inte har kommit överens om hur fas 1 ska skyddas. De flesta reagerar genom att klistra in en chiffersträng de hittat online. En skanning av gatewayen besvarar samma fråga med bevis och tar ungefär lika lång tid.

Vad meddelandet utesluter

Avvisningen sker i huvudläget, före något L2TP- eller PPP-utbyte, så tunneln och användardatabasen har inte tillfrågats. Fas 1 förhandlar om kryptering, integritet och en Diffie-Hellman-grupp. Fas 2 förhandlar om ESP-förslaget för data. Ett fel i fas 1 kan inte åtgärdas genom att ändra en PFS-inställning i fas 2, och en slutförd IKE-association bevisar inte att ESP-förslaget passar.

Notera backend innan du redigerar syntaxen: ipsec --version. libreswan och strongSwan accepterar olika stavningar av förslaget för samma algoritmer.

Läs sedan avvisningen i sammanhang med journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Skanna gatewayen för dess transformuppsättning

En skanner frågar gatewayen direkt vilka transformationer den kommer att förhandla. Stoppa först den lokala IPsec-tjänsten så att sonden inte konkurrerar med din egen klient, och läs sedan SA-raderna. Behandla listan som bevis om motparten, inte som en meny som ska slås på i sin helhet.

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

Äldre enheter erbjuder ofta 3DES, SHA1 och MODP1024, eftersom det var standardvärdena när produkten skeppades och ingen har granskat dem igen. Spara den råa skanningsutskriften, eftersom den är den enda registreringen av vad motparten erbjöd den dagen. Om det är den starkaste överlappning som finns bör eskaleringen gå till gatewayens ägare, inte till en klientkonfiguration som slår på svag kryptering för alla igen.

Matcha överlappningen utan att stänga av säkerheten

Ange bara de transformationer som finns både i skanningen och i din policy. Exemplet nedan speglar en gateway som erbjuder 3DES, SHA1 och MODP1024 i fas 1. Notera förbehållet om backend: libreswan 4.x kompilerar inte modp1024-gruppen, så detta gäller strongSwan eller en libreswan-build med DH2-stöd. Verifiera versionen innan du drar slutsatsen att klienten är trasig.

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

Ett utropstecken i slutet fäster ett enda förslag. Använd det för att isolera ett test och ta sedan bort det så att gatewayen senare kan förhandla fram något starkare.

Kontrollera daemonen och porten innan du försöker igen

NetworkManager-l2tp startar sin egen xl2tpd-instans. Om systemtjänsten redan äger UDP 1701 faller klienten tillbaka på en efemär källport, vilket RFC 3193 tillåter och vissa servrar tyst släpper. Kontrollera socketägaren före nästa försök.

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

Föråldrade genererade hemligheter är en annan tyst orsak. Filer under /etc/ipsec.d/ namngivna efter en gammal anslutning kan överleva profilen som skapade dem, så ta bort dem som inget refererar till och försök igen.

Kontrollera slutligen var rådet kom ifrån. En ipsec.conf skriven för IKEv1 XAuth beskriver en annan typ av VPN, och dess förslag är inte den enda raden som blir fel i en L2TP-profil. Notera transformuppsättningen du angav bredvid profilen, så att nästa person inte upprepar sonden.

Relaterade artiklar