Ubuntu upgrade broke L2TP/IPsec? Compare the IKEv1 proposals

The connection worked on Thursday, the upgrade ran on Friday, and on Monday the client spins at "connecting" and gives up. Same laptop, same server, same account, same pre-shared key. Nothing in the profile was edited, which is why the obvious suspects, the password and the firewall, waste your time.

What changed is the list of transforms your machine is willing to offer. Both IPsec stacks used on Ubuntu, strongSwan and Libreswan, prune algorithms they no longer consider safe, and the NetworkManager plugin that fronts them has its own list that moves on a different schedule. A server pinned to 3DES, SHA1 and a 1024-bit Diffie-Hellman group can end up hearing nothing it accepts.

What the upgrade actually changed

Two layers feed the IKEv1 offer. The daemon ships a compiled-in default proposal set, and the L2TP plugin either defers to it or supplies its own list. Before NetworkManager-l2tp 1.2.16 the plugin deferred, so your offer was whatever the installed daemon considered reasonable. From 1.2.16 onward the plugin sends a documented list modelled on Windows and Apple clients, and that list is broader than the old default but no longer contains every legacy combination at the front of the queue.

That split explains a failure mode people find confusing: two machines on the same Ubuntu release can behave differently because one has the distribution package and the other has a backport, and the daemon version on both looks identical in a bug report. Check the plugin version, not just the daemon version, before you conclude that the upgrade changed nothing relevant.

There is a smaller trap in the same area. The two daemons spell the elliptic-curve Diffie-Hellman groups differently, one writing ecp384 and the other ecp_384. Paste the wrong spelling into the Advanced dialog and the daemon rejects the setting as unparsable, which surfaces in the log as a negotiation problem rather than a configuration typo.

Read the failure before changing anything

Start with which backend you are running, because the answer decides both the syntax and the log location.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Then read the exchange itself. On strongSwan the daemon logs to the journal on a current release and to /var/log/syslog on an older one, and the interesting part is the proposal it sends, not the final line. You are looking for wording about no matching proposal, which is an algorithm problem; an authentication failure, which points at the key or the account; or a plain timeout, which points at reachability.

Those three outcomes get treated as one symptom far too often. A timeout with an empty daemon log means the packets are not arriving. A proposal rejection means they arrived and were refused. If your log is silent, raise the plugin's debug level for one attempt and lower it afterwards, because the verbose output fills a journal quickly.

Phase 1 and phase 2 are separate bets

IKEv1 negotiates twice. Main mode builds the IKE security association from an encryption algorithm, an integrity algorithm, a Diffie-Hellman group and an authentication method. Quick mode then builds the ESP association that will carry L2TP. A server is free to accept the first and reject the second, so a half-correct profile fails later than you expect and looks like a different bug.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

The exclamation mark is strongSwan syntax for a strict entry: offer this one combination and nothing else. Without it the entry joins a fallback list, which is fine when the peer is modern and counterproductive when it is an appliance with a single hard-coded policy. Treat the pair above as an illustration of the form, not as a recommendation for anything you are building today.

Change one field, then repeat the test

On a current plugin, the fastest first test is to clear both proposal fields entirely and reconnect, because the shipped default list already includes the common Windows and Apple combinations. On an older plugin, clearing them hands control back to a daemon that may have dropped the algorithm your server insists on, and the failure gets worse.

If clearing does not help, set the strict pair your server documents, one phase at a time. Change phase 1, reconnect, and read the log before touching phase 2. When a combination finally works, write it down next to the server model and the plugin version, because the defaults will move again and that note is what turns the next upgrade into a five-minute check.