L2TP/IPsec PSK rejected: walk the dialog, then the files

You paste the pre-shared key from the administrator's message into the NetworkManager dialog, tick the box to show it, and it matches character for character. Connect still ends at an authentication failure before the tunnel is up. Watching that happen the first time, I assumed the key was wrong; it was not. Two other things decide what the daemon actually reads: the secret file the plugin writes for that connection, and whether the value survived the dialog unchanged.

The walk below follows the key from the field to the file, which is the order that tells you where it was lost. Do it on the machine that fails, not on the one that works, because the difference between those two machines is usually the file layout rather than the key.

Start at the dialog, but do not trust the field

Open the connection's IPsec tab and type the key again instead of pasting it. A key copied out of a chat message, a PDF, or a password manager can arrive with a trailing line break that the field does not display, and the shown characters still look correct.

Click the show-password control and look at the end of the string, not the middle. If the cursor leaves an empty line below the text, delete it and retype the final character. That single edit fixes a surprising share of these reports, and it costs less than reading any log.

If the key came from a ticket system that wraps long lines, ask for it through a channel that does not wrap. Compare lengths with the administrator rather than eyeballing two strings side by side; a lost character at a wrap point is invisible in a proportional font.

Follow the key into /etc/ipsec.d

The plugin never hands the PSK to the IPsec daemon as an argument on a command line. Instead it stores the value in a secrets file and arranges for the daemon to pull that file in, adding an include line to /etc/ipsec.secrets if one is absent. What the dialog holds is an input to that generated file, not the value in use.

List what exists before you change anything:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Older plugin releases wrote one file per connection, named after the connection UUID, for example /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Deleting a profile in the applet does not reliably delete that file. If an old file from a previous server is still on disk and still included, the daemon can pick a secret belonging to a profile you no longer use, and the connection fails while the visible field is right.

Understand what the 1.2.12 change did to upgrades

Plugin version 1.2.12 replaced the per-connection secret files with a single shared file, /etc/ipsec.d/ipsec.nm-l2tp.secrets. An upgrade does not clean up the older per-UUID files, and an existing include /etc/ipsec.d/*.secrets line still pulls them in. Version 1.2.16 changed default proposal handling, not the secret layout.

That history explains why two machines with what looks like the same profile behave differently. The key is identical; the set of files the daemon includes is not. When you remove an orphaned file, move it aside rather than deleting it, confirm the connection, then delete it once the working state is recorded. Renaming it keeps the old value recoverable if the failure turns out to live somewhere else.

Separate the characters the storage format cannot hold

The strongSwan documentation for the shared-secret string states that the value cannot contain a newline or a double-quote character. A key pasted from a document can carry either without any visual difference in a normal dialog.

Since 1.2.12 the stored value has not been plain text. The plugin base64-encodes the PSK before it reaches the file, and the release notes present that encoding as the reason a double quotation mark is now acceptable in a key. A quote typed into the field is therefore representable; the same is not true of every control character.

Length is a different constraint. No universal minimum applies across L2TP/IPsec software: some clients accept keys shorter than twenty characters and some gateways enforce a minimum. If a short key is refused, the rule belongs to the server policy or to that client's validation, and raising something locally will not change it.

Read which authentication layer failed

Run ipsec --version first, because strongSwan and Libreswan use different file names and syntax, and advice for one can damage the other. Then read the failure stage from the client's message or the daemon log: a complaint about the pre-shared key is a different event from a rejected username and password.

The PSK authenticates the tunnel endpoints. The username and password authenticate the person inside L2TP, and PPP handles them after the IPsec association is up. A correct PSK with a wrong account still fails, and changing the account will not repair a key that the daemon never read correctly.

When you close the ticket, write down all four: plugin version, the secrets file in use, whether the key was retyped or pasted, and the layer named in the error. Anyone repeating this walk later can then skip straight to the difference between the working and failing machine.