L2TP debug log empty? The error is probably in the journal

You start the L2TP helper with debugging, watch the terminal, and it stops with nothing useful on screen. That is not a broken debug flag. A NetworkManager L2TP connection is four cooperating processes, and only some of them write to the terminal you are watching. The rest of the evidence is in the journal, one filter away.

Four processes, two log destinations

The connection starts with IPsec, which is either libreswan or strongSwan depending on the installation. Then the L2TP daemon, traditionally xl2tpd and in some builds kl2tpd, runs the tunnel. Finally pppd handles authentication and addressing inside it.

The helper service coordinates those pieces and prints its own progress. The IPsec daemon and pppd generally report through the system journal, which is why the terminal shows a connection failing while the reason sits in a file you have not opened.

That split also explains why a PSK error and a password error look alike from the desktop: both produce a generic disconnect, and the stage that failed is only visible in the per-process output. That is the whole reason the journal matters here. One generic message on the desktop, four possible authors behind it.

Collect one attempt, then read the order

Reproduce once, with a known profile and a known time, then read a narrow window rather than the whole boot. Repeating attempts while changing settings turns the log into a mixture that cannot be interpreted.

These commands select the participating processes for the current boot, and the plugin path is worth confirming on your distribution:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Repeated fields in one invocation select the union of those processes, which keeps the sequence in time order. On a Debian-based system the equivalent query is dpkg -L; the point is to find where the helper actually lives before trying to run it by hand.

Three conditions that decide the next move

Read the first failing stage, then choose accordingly. If IPsec reports a proposal or peer-authentication failure, the tunnel never formed, and changing the PPP password cannot help.

If the tunnel formed and pppd rejected the login, the shared secret was already fine and the credential problem is one layer up. If pppd negotiated an address and the failure appears later, both of those are working and the remaining problem is routing, DNS or the server's own policy.

Those three branches cover nearly every generic disconnect, and they are decided by which process logged the last error rather than by which error message looks most alarming.

It is also worth confirming which IPsec backend is installed before touching a debug setting. A logging option written for strongSwan does nothing when libreswan is running, and the connection will keep failing in the same place while you edit a file nothing reads.

Debug mode leaves files behind

The upstream debugging workflow runs the service manually with a debug flag, and that mode can leave generated runtime configuration files in place when the connection ends.

Those files contain authentication material: the pre-shared key, credentials or both. A generated configuration copied into a chat window is a credential disclosure, not a log excerpt. Strip the secret lines before you share anything, and delete the directory when the investigation ends. Treat them as secrets, extract the specific lines you need for a report, and delete them afterwards rather than pasting a directory into a ticket.

The manual instance also has to be coordinated with the normal one. Launching a debug copy while the service already owns the plugin produces two owners and a log that mixes both, which is worse than no debug output at all.

Restore the normal helper afterwards

When the investigation ends, stop the manual instance, remove the retained runtime files and reconnect through the normal path so the next person sees a configuration that matches reality.

Then verify the result at the layer that failed, not at the desktop icon:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

A session that authenticates, receives an address and routes to the intended destination is the outcome you were debugging. A silent terminal during a failed attempt only tells you where the output was not written.