Ubuntu 22.04 L2TP Timeout: The xl2tpd Tunnel Bug

The desktop shows a connection in progress, IPsec reports success, and the PPP interface never appears. In syslog the same tunnel number repeats until the attempt times out on UDP 1701. Before editing the pre-shared key or the server configuration, recognize this shape: on Ubuntu 22.04 it is usually a packaging regression in xl2tpd, and the server was correct the whole time.

What the repeating syslog pair is telling you

A failing session prints a pair of lines at regular intervals: the daemon cannot find a tunnel for an incoming control message, then dumps the call and tunnel identifiers it was handed. Later the retry counter reaches its limit and the connection closes with a port 1701 timeout. Addresses and identifiers are incidental; the shape is what matters. IKE completed, L2TP control traffic arrived, and the daemon failed to associate it with a tunnel it had already created.

The fault therefore sits between L2TP control and PPP. Nothing about the secret, the PPP options or the remote subnet has been exercised yet.

Confirm IPsec really succeeded

Two checks separate this from a credentials problem, and both belong before any package change.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

The status output lists the connection and its state, and an established tunnel means phase one and phase two completed. A log line about a missing shared key points at the secret and nothing else, so stop and fix that first. When IPsec is established and the L2TP timeout still appears, the daemon is the remaining suspect. Keep the exact lines from one attempt rather than a whole day of retries.

Check the xl2tpd build, not the release name

Ubuntu's jammy build of xl2tpd 1.3.16 enabled link-time optimization, which broke parsing of the tunnel identifier in the server's SCCRP reply. The daemon then discards control packets for a tunnel it created itself. The version string matters more than the distribution name.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

The corrected package is 1.3.16-1ubuntu0.1, so a build without that suffix predates the fix. The policy output shows which candidate an upgrade would install, and the hold list explains why a fix has not arrived. Where the package is available, upgrade it and reconnect through the normal profile instead of editing files by hand. Do not rebuild modules or change the secret while the old build is still installed.

Verify PPP after the change

A successful upgrade is proven at the layer that was broken. Check that PPP came up rather than only that the icon changed.

ip -4 addr show ppp0
ip route | grep ppp

The interface listing should show a local and peer address, and the route table should carry the tunnel's prefixes. Syslog should show the tunnel accepted and pppd reporting both addresses, with no repeated tunnel-not-found lines. If PPP is up and traffic still fails, look at routing or MTU next, because the L2TP stage has finished its job. Record the working package version in the machine notes, so a future reinstall does not restore the broken build.

Where the fixed package is unavailable, a local source build of 1.3.16 or 1.3.17, a switch to kl2tpd, or a pinned downgrade are the documented alternatives. Each carries a maintenance cost worth writing down.