L2TP: fataal signaal 15, NO_PROPOSAL_CHOSEN en ontbrekende modp1024

Je verbinding hangt, de client sluit af, en de laatste regel op het scherm is death_handler: Fatal signal 15 received. Die regel meldt een afbreking, geen oorzaak. Een regel eerder in het IPsec-log staat bijna altijd NO_PROPOSAL_CHOSEN, en het paar wijst naar fase 2 van de uitwisseling, waar beide kanten coderings- en hashkeuzes vergelijken en stoppen wanneer ze niets gemeenschappelijks hebben. Inloggegevens zijn in die fase nog niet verzonden, dus het wachtwoord opnieuw intypen kan het resultaat niet veranderen.

Meestal leegt twee dingen dat snijvlak op een Linux-client. De lokale daemon implementeert misschien niet meer de Diffie-Hellman-groep die het profiel vraagt, of het profiel draagt een fase 1-voorstel in een fase 2-veld. Beide laten sporen in het log achter, en geen van beide is een accountprobleem.

Wat de twee berichten werkelijk zeggen

IKE onderhandelt in rondes. Fase 1 bouwt een beschermd kanaal en kiest eigen algoritmen; fase 2, de child-SA, draagt verkeer onder een aparte set. NO_PROPOSAL_CHOSEN is de melding die een responder terugstuurt wanneer geen van de aangeboden combinaties aanvaardbaar is, en verschijnt als [ HASH N(NO_PROP) ] binnen een INFORMATIONAL-uitwisseling.

Signaal 15 is een andere gebeurtenis: iets zei het lokale proces te stoppen en de handler logde dat. Wanneer beide regels samen verschijnen, is de volgorde causaal, eerst de afwijzing en dan het afsluiten.

Lees de onderhandeling voordat je aan inloggegevens komt

Verhoog het logniveau waar de daemon schrijft, en verbind daarna opnieuw terwijl je de uitvoer bekijkt. Op een NetworkManager-host geeft de L2TP-plugin dat niveau door aan de backend, en berichten belanden in het journal of in het klassieke syslog-bestand, afhankelijk van de distributie. Elk van deze toont de uitwisseling: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' of tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Een regel die pluto noemt komt van libreswan, charon van strongSwan, en beide beschrijven dezelfde toestand met andere woorden. De vorm die het zoeken waard is, is degene die de ontbrekende groep noemt, bijvoorbeeld algorithm 'modp1024' is not supported, omdat die een vage fout concreet maakt.

Waar modp1024 heen ging

Diffie-Hellman-groep 2 is zwak genoeg dat verschillende distributies hem vanaf 3.30 niet meer in libreswan compileerden. Dan vraagt een profiel dat jaren geleden is geschreven, of uit een gateway-handleiding is overgenomen die alleen aes128-sha1-modp1024 vermeldt, de lokale daemon iets wat hij helemaal niet kan uitvoeren. Nieuwere NetworkManager-l2tp-builds maken dat resultaat waarschijnlijker: vanaf 1.2.16 vervangen ze de set door voorstellen in Windows 10- en iOS-stijl en laten modp1024 vallen zodra libreswan wordt gedetecteerd. De andere kant is vaak onschuldig en biedt nog steeds precies de groep aan die je hebt geconfigureerd.

Die asymmetrie is wat de fout willekeurig laat voelen. Een oudere client verbindt, hetzelfde profiel op een bijgewerkte laptop niet, en de serverconfiguratie is nooit verschoven. De schade komt van versieverschuiving.

Twee reparaties met verschillende impact

De goedkope reparatie is algoritmen niet meer hard te coderen. Maak beide voorstelvelden in de editor leeg en laat de plugin een set kiezen die de verre kant accepteert; ondersteunt de gateway moderne groepen, dan rondt de onderhandeling af zonder extra werk.

De tweede reparatie houdt een oude gateway bereikbaar door strongSwan te installeren, waarvan de pakketten op de meeste distributies nog steeds groep 2 implementeren. Dat is een daemonwissel, dus het kost iets: controleer of andere tunnels op de host van de libreswan-configuratie afhangen voordat je die verwijdert, en verwacht SELinux-weigeringen tussen NetworkManager en de strongSwan-plugin op Fedora. Die weigeringen verschijnen in het auditlog en niet in het IKE-spoor, waardoor een tunnel direct na een geslaagde installatie kapot kan lijken. De volgorde die werkt is eerst dnf install strongswan, dan rpm -e libreswan.

Voorstelstrings die passen, en de valkuilen eromheen

Wanneer de velden met de hand moeten worden ingevuld, nemen fase 1 en fase 2 verschillende waarden aan. Een paar dat bekendstaat als werkend tegen een tegenpartij in Meraki-stijl biedt in fase 1 aes128-sha1-modp1024 met 3des-sha1-modp1024 erachter, beide afgesloten met een uitroepteken dat de set strikt maakt, zodat alleen die voorstellen ooit worden verzonden.

Fase 2 vernauwt dan tot aes128-sha1 en 3des-sha1 met dezelfde strikte markering en zonder enige Diffie-Hellman-achtervoegsel. Een fase 2-regel met -modp1024 is een fase 1-waarde in het verkeerde veld, en de responder weigert die bij elke poging. Kopieer die regel naar een tweede profiel en het tweede profiel faalt op dezelfde manier, en zo wordt één typefout een incident voor de hele vloot.

Andere fouten dragen dezelfde popup zonder voorstelmismatches te zijn. Op KDE kan het L2TP-type vermeld staan met de plugin geïnstalleerd terwijl elke verbinding meteen sterft, omdat de verbindingseditor en de runtime-hulpprogramma's als aparte pakketten worden geleverd. Headless hosts kunnen een profiel van een werkende desktop hergebruiken: kopieer het uit /etc/NetworkManager/system-connections/, zet de modus op 600 en voer daarna nmcli con reload uit. Breng het omhoog met nmcli con up id work-l2tp, omdat de kale vorm een UUID wil, en verwijder elke verouderde ifname-vermelding, anders antwoordt de beheerder Could not find source connection terwijl al het andere klopt.

Een vooraf gedeelde sleutel kan als platte tekst of als 0s gevolgd door base64 worden opgeslagen; beide vormen werken, maar de waarde moet byte voor byte met de gateway overeenkomen, inclusief de spaties aan het eind die je ermee hebt gekopieerd.