L2TP Fatal Signal 15: NO_PROPOSAL_CHOSEN and Missing modp1024

Your connection hangs, the client exits, and the last line on screen is death_handler: Fatal signal 15 received. That line reports an abort, not a cause. One line earlier in the IPsec log there is almost always NO_PROPOSAL_CHOSEN, and the pair points at phase 2 of the exchange, where the peers compare encryption and hash choices and stop when they share none. Credentials have not been sent at that stage, so retyping the password cannot change the result.

Two things usually empty that intersection on a Linux client. The local daemon may no longer implement the Diffie-Hellman group the profile requests, or the profile may carry a phase 1 proposal in a phase 2 field. Both leave evidence in the log, and neither is an account problem.

What the two messages actually say

IKE negotiates in passes. Phase 1 builds a protected channel and picks its own algorithms; phase 2, the child SA, carries traffic under a separate set. NO_PROPOSAL_CHOSEN is the notify a responder returns when none of the offered combinations is acceptable, and it appears as [ HASH N(NO_PROP) ] inside an INFORMATIONAL exchange.

Signal 15 is a different event: something told the local process to stop and the handler logged it. When both lines appear together the order is causal, rejection first and shutdown second.

Read the negotiation before touching credentials

Raise the log level where the daemon writes, then reconnect while watching the output. On a NetworkManager host the L2TP plugin passes that level to the backend, and messages land in the journal or in the classic syslog file depending on the distribution. Either of these will show the exchange: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' or tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

A line naming pluto comes from libreswan, charon from strongSwan, and the two describe the same condition in different words. The form worth hunting for is the one that names the missing group, such as algorithm 'modp1024' is not supported, because it turns a vague failure into a specific one.

Where modp1024 went

Diffie-Hellman group 2 is weak enough that several distributions stopped compiling it into libreswan from 3.30 onward. A profile written years ago, or lifted from a gateway guide that only lists aes128-sha1-modp1024, then asks the local daemon for something it cannot perform at all. Newer NetworkManager-l2tp builds make that outcome more likely: from 1.2.16 they substitute a Windows 10 and iOS style proposal set and drop modp1024 once libreswan is detected. The head end is often innocent and still offers exactly the group you configured.

That asymmetry is what makes the failure feel random. An older client connects, the same profile on an updated laptop does not, and the server configuration never moved. Version drift is doing the damage.

Two repairs with different blast radius

The cheap repair is to stop hard-coding algorithms. Clear both proposal fields in the editor and let the plugin choose a set the far end accepts; if the gateway supports modern groups, negotiation completes without further work.

The second repair keeps an old gateway reachable by installing strongSwan, whose packages still implement group 2 on most distributions. That is a daemon swap, so it costs something: confirm whether other tunnels on the host depend on libreswan configuration before removing it, and expect SELinux denials between NetworkManager and the strongSwan plugin on Fedora. Those denials surface in the audit log rather than in the IKE trace, which is why a tunnel can look broken right after a successful install. The order that works is dnf install strongswan first, then rpm -e libreswan.

Proposal strings that match, and the traps around them

When the fields have to be filled by hand, phase 1 and phase 2 take different values. A pair known to work against a Meraki-style head end offers aes128-sha1-modp1024 in phase 1 with 3des-sha1-modp1024 behind it, both closed by an exclamation mark that makes the set strict, so only those proposals are ever sent.

Phase 2 then narrows to aes128-sha1 and 3des-sha1 with the same strict marker and no Diffie-Hellman suffix at all. A phase 2 line carrying -modp1024 is a phase 1 value in the wrong field, and the responder rejects it on every retry. Copy that line into a second profile and the second profile fails the same way, which is how one typo becomes a fleet-wide incident.

Other faults wear the same popup without being proposal mismatches. On KDE the L2TP type can be listed with the plugin installed while each connection dies at once, because the connection editor and the runtime helpers ship as separate packages. Headless hosts can reuse a profile from a working desktop: copy it from /etc/NetworkManager/system-connections/, set the mode to 600, then run nmcli con reload. Bring it up with nmcli con up id work-l2tp, since the bare form wants a UUID, and remove any stale ifname entry or the manager replies Could not find source connection while everything else is correct.

A pre-shared key may be stored as clear text or as 0s followed by base64; either form works, but the value must match the gateway byte for byte, including trailing whitespace you copied along with it.