NO_PROPOSAL_CHOSEN på L2TP? Skann gatewayen først

En L2TP/IPsec-klient som feiler før brukernavnforespørselen, har aldri blitt enige om fase 1. Skann gatewayens forslagssett i stedet for å lime inn chifferstrenger.

Brukernavnforespørselen vises aldri, og klienten rapporterer NO_PROPOSAL_CHOSEN. På det tidspunktet er påloggingsinformasjon og den forhåndsdelte nøkkelen irrelevante, fordi partene ikke har blitt enige om hvordan fase 1 skal beskyttes. De fleste reagerer med å lime inn en chifferstreng de fant på nettet. En skanning av gatewayen svarer på det samme spørsmålet med bevis og tar omtrent like lang tid.

Hva meldingen utelukker

Avvisningen skjer i hovedmodus, før noen L2TP- eller PPP-utveksling, så tunnelen og brukerdatabasen er ikke blitt spurt. Fase 1 forhandler kryptering, integritet og en Diffie-Hellman-gruppe. Fase 2 forhandler ESP-forslaget for data. En feil i fase 1 kan ikke rettes ved å endre en PFS-innstilling i fase 2, og en fullført IKE-assosiasjon beviser ikke at ESP-forslaget passer.

Noter backend før du redigerer syntaksen: ipsec --version. libreswan og strongSwan godtar ulike stavemåter av forslaget for de samme algoritmene.

Les deretter avvisningen i sammenheng med journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Skann gatewayen for transformasjonssettet

En skanner spør gatewayen direkte hvilke transformasjoner den vil forhandle om. Stopp først den lokale IPsec-tjenesten slik at sonden ikke konkurrerer med din egen klient, og les deretter SA-linjene. Behandle listen som bevis om motparten, ikke som en meny som skal slås på i sin helhet.

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

Eldre enheter tilbyr ofte 3DES, SHA1 og MODP1024, fordi det var standardverdiene da produktet ble sendt, og ingen har gjennomgått dem på nytt. Ta vare på den rå skanneutskriften, fordi den er den eneste registreringen av hva motparten tilbød den dagen. Hvis det er den sterkeste overlappingen som finnes, hører eskaleringen hjemme hos gatewayens eier, ikke hos en klientkonfigurasjon som slår på svak kryptografi for alle igjen.

Tilpass overlappingen uten å slå av sikkerheten

Skriv bare inn transformasjonene som finnes både i skanningen og i policyen din. Eksempelet nedenfor gjenspeiler en gateway som tilbyr 3DES, SHA1 og MODP1024 i fase 1. Legg merke til forbeholdet om backend: libreswan 4.x kompilerer ikke modp1024-gruppen, så dette gjelder strongSwan eller en libreswan-build med DH2-støtte. Verifiser versjonen før du konkluderer med at klienten er ødelagt.

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

Et utropstegn til slutt låser ett enkelt forslag. Bruk det til å isolere en test, og fjern det deretter slik at gatewayen senere kan forhandle om noe sterkere.

Kontroller daemonen og porten før du prøver igjen

NetworkManager-l2tp starter sin egen xl2tpd-instans. Hvis systemtjenesten allerede eier UDP 1701, faller klienten tilbake til en efemær kildeport, noe RFC 3193 tillater og noen servere dropper i stillhet. Kontroller socket-eieren før neste forsøk.

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

Utdaterte genererte hemmeligheter er en annen stille årsak. Filer under /etc/ipsec.d/ oppkalt etter en gammel tilkobling kan overleve profilen som opprettet dem, så fjern dem ingenting refererer til, og prøv igjen.

Til slutt, kontroller hvor rådet kom fra. En ipsec.conf skrevet for IKEv1 XAuth beskriver en annen VPN-type, og forslaget er ikke den eneste linjen som vil være feil i en L2TP-profil. Noter transformasjonssettet du skrev inn, ved siden av profilen, slik at neste person ikke gjentar sonden.

Relaterte artikler