NO_PROPOSAL_CHOSEN on L2TP? Scan the Gateway First

The username prompt never appears, and the client reports NO_PROPOSAL_CHOSEN. Credentials and the pre-shared key are irrelevant at that point, because the two ends have not agreed on how to protect phase 1. Most people respond by pasting a cipher string they found online. A scan of the gateway answers the same question with evidence and takes about as long.

What the message rules out

The rejection happens in main mode, before any L2TP or PPP exchange, so the tunnel and the user database have not been consulted. Phase 1 negotiates encryption, integrity, and a Diffie-Hellman group. Phase 2 negotiates the ESP proposal for data. A phase-1 failure cannot be fixed by changing a phase-2 PFS setting, and a completed IKE association does not prove the ESP proposal fits.

Record the backend before editing syntax: ipsec --version. libreswan and strongSwan accept different proposal spellings for the same algorithms.

Then read the rejection in context with journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Scan the gateway for its transform set

A scanner asks the gateway directly which transforms it will negotiate. Stop the local IPsec service first so the probe is not competing with your own client, then read the SA lines. Treat the list as evidence about the peer, not as a menu to enable wholesale.

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

Older appliances frequently offer 3DES, SHA1, and MODP1024, because those were the defaults when the product shipped and nobody revisited them. Keep the raw scan output, since it is the only record of what the peer offered on the day. If that is the strongest overlap available, the right escalation is to the gateway owner, not to a client configuration that re-enables weak cryptography for everyone.

Match the overlap without disabling safety

Enter only the transforms that appear in both the scan and your policy. The example below mirrors a gateway offering 3DES, SHA1, and MODP1024 in phase 1. Note the backend caveat: libreswan 4.x does not compile the modp1024 group, so this applies to strongSwan or a libreswan build with DH2 support. Verify the version before concluding the client is broken.

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

A trailing exclamation mark pins a single proposal. Use it to isolate a test, then remove it so the gateway can negotiate something stronger later.

Check the daemon and the port before retrying

NetworkManager-l2tp starts its own xl2tpd instance. If the system service already owns UDP 1701, the client falls back to an ephemeral source port, which RFC 3193 permits and some servers silently drop. Check the socket owner before the next attempt.

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

Stale generated secrets are another quiet cause. Files under /etc/ipsec.d/ named for an old connection can outlive the profile that created them, so remove the ones nothing references and retry.

Finally, check where the advice came from. An ipsec.conf written for IKEv1 XAuth describes a different VPN type, and its proposal is not the only line that will be wrong in an L2TP profile. Record the transform set you entered beside the profile, so the next person does not repeat the probe.