L2TP NO_PROPOSAL_CHOSEN: which phase actually failed?

NO_PROPOSAL_CHOSEN arrives before any PPP username is examined, which is a useful fact and also the reason the message misleads. It reports that one side rejected a proposal; it does not report which parameter disagreed, and it says nothing about whether the rejection happened while building the IKE association or later while negotiating the traffic protection. Two different fixes live behind those two possibilities, and only one of them involves the PFS checkbox people reach for first.

One message, two proposal sets

The IKEv1 L2TP/IPsec arrangement has two negotiations in sequence. Phase 1 builds the IKE security association from an encryption algorithm, an integrity algorithm and a Diffie-Hellman group. Phase 2 then negotiates how traffic gets protected, and the PFS requirement belongs to that second conversation.

Because the phases are sequential, the failure position tells you which list to compare. That is the entire diagnostic value in the message, and it is worth extracting before touching a setting.

Why a PFS checkbox cannot repair phase 1

Disabling PFS changes a phase-2 property. If the peers never agreed on phase 1, the ESP conversation never takes place, so the checkbox has no effect on the rejection at all, which is why toggling it produces the same error with a different timestamp.

The reverse mistake is equally common. A successful IKE association does not prove the ESP proposal is acceptable, and it definitely does not prove the phase-2 group matches. Treat an established management tunnel as evidence about phase 1 only. People read the green line as "the tunnel is up", then spend an hour on the wrong phase because nothing told them the second negotiation had not started.

Read the log before choosing algorithms

Collect the messages immediately preceding the rejection from the backend that is actually handling the connection, correlated with the same attempt. Without that correlation you are reading a different connection's history and drawing conclusions from it.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

From those lines, answer two questions: did a phase-1 association establish, and which exchange failed. Those two answers narrow the search to one list of attributes. A bare notification with no surrounding context cannot do that, however tempting it is to try a proposal from a forum thread. Copying a working string from a machine with a different backend usually replaces one rejection with another, slightly later.

Backend syntax does not travel

Record the NetworkManager-l2tp version and the IPsec backend version before comparing anything. Libreswan and strongSwan do not share proposal syntax or identical algorithm sets, so a string that works in one is a syntax error in the other. The installed backend may also refuse IKEv1 by policy, in which case no proposal will ever be accepted.

The upstream README documents those backend differences and keeps the phase-1 and phase-2 fields separate. Read it as documentation of structure, not as an invitation to enable every historical cipher and a weak group, because a connection that only succeeds by doing that is not the connection you were asked to build.

Agree the suite, then verify the stages

Ask the gateway operator which IKE and ESP suites are supported and approved, then compare that answer with the client's effective proposals rather than with its configuration file. If the disagreement is specifically about phase-2 PFS, settle on a supported group or on an explicitly approved no-PFS policy. Do not infer the policy from the error name.

When the only overlap requires cryptography the organisation no longer accepts, the decision belongs to the gateway or to a protocol migration. Widening the client string until something negotiates is a way of shipping a known weakness with a green checkmark next to it.

After correcting the real mismatch, confirm IPsec establishment before investigating L2TP and PPP, and treat any later authentication rejection as belonging to the next stage. Then exercise renewal in the approved test process, because establishing the first association says nothing about the rest of its lifetime.