Ubuntu 24.04 L2TP Broken: xl2tpd or go-l2tp Daemon?

Ubuntu 24.04 quietly swapped the daemon behind NetworkManager's L2TP plugin. The older path used xl2tpd; the newer packaging pulls in a Go implementation producing a daemon named kl2tpd. The plugin starts whichever is installed, so the upgrade can replace the daemon without touching your profile or credentials. That is the entire failure: a control message the new daemon does not recognise.

The plugin coordinates IPsec, L2TP and PPP, then hands the resulting interface to NetworkManager. It does not implement L2TP itself.

The Plugin Is a Coordinator, Not a Daemon

network-manager-l2tp runs the IPsec helper, an L2TP daemon and PPP, and wires the interface into the desktop's connection management. For years the daemon was xl2tpd, and every tutorial mentioning its configuration inherited that assumption. Debian packaging later accepted either implementation, and 24.04 installs the Go one, which provides kl2tpd. No field in the profile records which daemon ran previously, so the swap stays invisible until a message is refused.

A machine with both packages present may still not run the one you expect. Selection is the plugin's decision rather than the guide you followed.

Read the Stage Before Choosing a Repair

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd _COMM=charon _COMM=pluto

Correlate a single attempt across the helpers rather than trusting the desktop notification. That query shows where the sequence halted, and dpkg -l shows which implementation is installed. A failure that appears after the IPsec peer is established, and that mentions a control message or an unrecognised attribute, points at the daemon. A failure before the tunnel exists means the daemon was never reached.

A pre-shared-key mismatch ends at the IPsec stage and names the peer. PPP credential trouble appears once the tunnel is up and normally carries a readable CHAP or MS-CHAP rejection. Both are visible in the same query, and they are different problems.

Two Routes, and They Do Not Mix

sudo apt install xl2tpd
sudo apt purge go-l2tp

That pair puts xl2tpd in place and then removes the Go daemon, leaving the plugin to pick the implementation whose dialect the gateway speaks. Order matters: the plugin depends on one implementation or the other, so purging the Go package first takes the plugin down with it. The second route keeps the Go daemon and moves to a newer build that understands the message, which usually means a maintainer PPA rather than the archive version. Across a managed fleet, pinning a PPA is easier to justify than teaching users to purge packages.

Do not combine the two in one change. A later failure then leaves you unable to say which half helped, and a future upgrade may restore the package you just removed.

Put the daemon binary, its version and the exact message in the ticket. Nobody can reproduce a report that says only that L2TP broke after the release, while a named attribute plus a package version gives them somewhere to start.

Three Things It Is Not

It is not a profile problem, since the same profile worked on 22.04 against the same gateway. It is not a missing route or a firewall change, because those fail elsewhere with different evidence. Reinstalling the plugin does not repair it either, since the same daemon gets selected again. The useful description names the daemon and the message it rejected.

A gateway-side fix is the other legitimate outcome. Firmware that stops sending the attribute survives every client upgrade, whereas pinning a package survives the next distribution release only if someone remembers why it is pinned.

Compare the two routes on maintenance cost rather than speed. Both can work; only one removes the dialect mismatch.