NO_PROPOSAL_CHOSEN bij L2TP? Scan eerst de gateway

De gebruikersnaamprompt verschijnt nooit en de client meldt NO_PROPOSAL_CHOSEN. Inloggegevens en de vooraf gedeelde sleutel zijn op dat moment irrelevant, omdat beide uiteinden het niet eens zijn geworden over hoe fase 1 moet worden beschermd. De meeste mensen reageren door een cipherstring te plakken die ze online hebben gevonden. Een scan van de gateway beantwoordt dezelfde vraag met bewijs en kost ongeveer evenveel tijd.

Wat het bericht uitsluit

De afwijzing gebeurt in de hoofdmodus, vóór enige L2TP- of PPP-uitwisseling, dus de tunnel en de gebruikersdatabase zijn niet geraadpleegd. Fase 1 onderhandelt over versleuteling, integriteit en een Diffie-Hellman-groep. Fase 2 onderhandelt over het ESP-voorstel voor gegevens. Een fout in fase 1 is niet op te lossen door een PFS-instelling in fase 2 te wijzigen, en een voltooide IKE-associatie bewijst niet dat het ESP-voorstel past.

Noteer de backend voordat u de syntaxis bewerkt: ipsec --version. libreswan en strongSwan accepteren verschillende spellingen van het voorstel voor dezelfde algoritmen.

Lees de afwijzing daarna in context met journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Scan de gateway op zijn transformatieset

Een scanner vraagt de gateway rechtstreeks welke transformaties hij gaat onderhandelen. Stop eerst de lokale IPsec-service zodat de probe niet concurreert met uw eigen client, en lees dan de SA-regels. Behandel de lijst als bewijs over de tegenpartij, niet als een menu dat in zijn geheel moet worden aangezet.

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

Oudere apparaten bieden vaak 3DES, SHA1 en MODP1024 aan, omdat dat de standaardwaarden waren toen het product werd verzonden en niemand ze opnieuw heeft bekeken. Bewaar de ruwe scanuitvoer, want dat is de enige registratie van wat de tegenpartij die dag bood. Als dat de sterkste beschikbare overlap is, hoort de escalatie bij de eigenaar van de gateway, niet bij een clientconfiguratie die zwakke cryptografie voor iedereen weer aanzet.

Pas de overlap toe zonder de veiligheid uit te schakelen

Voer alleen de transformaties in die zowel in de scan als in uw beleid voorkomen. Het voorbeeld hieronder weerspiegelt een gateway die in fase 1 3DES, SHA1 en MODP1024 aanbiedt. Let op het voorbehoud over de backend: libreswan 4.x compileert de modp1024-groep niet, dus dit geldt voor strongSwan of een libreswan-build met DH2-ondersteuning. Controleer de versie voordat u concludeert dat de client stuk is.

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

Een uitroepteken aan het eind pint één voorstel vast. Gebruik het om een test te isoleren en verwijder het daarna, zodat de gateway later iets sterkers kan onderhandelen.

Controleer de daemon en de poort voordat u het opnieuw probeert

NetworkManager-l2tp start zijn eigen xl2tpd-instantie. Als de systeemservice al UDP 1701 bezit, valt de client terug op een efemere bronpoort, wat RFC 3193 toestaat en sommige servers stilzwijgend laten vallen. Controleer de socket-eigenaar vóór de volgende poging.

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

Verouderde gegenereerde geheimen zijn een andere stille oorzaak. Bestanden onder /etc/ipsec.d/ die naar een oude verbinding zijn vernoemd, kunnen het profiel overleven dat ze heeft gemaakt, dus verwijder de bestanden waar niets naar verwijst en probeer het opnieuw.

Controleer ten slotte waar het advies vandaan komt. Een ipsec.conf die voor IKEv1 XAuth is geschreven, beschrijft een ander type VPN, en het voorstel ervan is niet de enige regel die in een L2TP-profiel fout zal zijn. Noteer de transformatieset die u hebt ingevoerd naast het profiel, zodat de volgende persoon de probe niet herhaalt.