IPsec Pre-Shared Key: The Bytes Behind the String You Typed

Two administrators compare the secret on screen, agree it matches, and the tunnel still fails authentication. The string they compared is not the value either end feeds into the key derivation. Between the characters you see and the bytes the protocol hashes there is a field type, a text encoding, an editor and a clipboard, and any of the four can change the input without changing how it looks. Compare the bytes and the disagreement usually appears in seconds.

What the gateway does with the string

A pre-shared key is not sent across the wire and compared. Each end feeds its local copy into the key derivation for the IKE exchange, and the resulting authentication payloads either verify or do not. That design means the two copies have to be byte-identical rather than visually similar, and it also means the failure is reported at the authentication stage rather than as a wrong-password message.

So the useful question is never "do these look the same" but "what exact sequence of bytes does each implementation hash".

Where extra bytes come from

A trailing newline is the classic culprit, and it hides in plain sight because most editors add one invisibly when a file is saved. A leading or trailing space pasted from a chat window does the same thing, and so does a smart quote substituted for a straight one by a word processor. None of those changes the visual comparison that a human performs.

Compare with a tool that shows bytes rather than glyphs. printf '%s' "$PSK" | xxd | tail -2 prints the tail of the value in hex, where a stray 0a or 20 is obvious. Do it on both ends and compare the two dumps side by side. Do this on generated test material, not on a production secret that you then leave in a shell history.

Encoded is not encrypted

Configuration exports frequently carry the secret in a base encoding, sometimes with line breaks every sixty or seventy-six characters and sometimes with padding. If one end expects the decoded bytes and you paste the encoded text, you have not sent a different password, you have sent a much longer one made of printable characters. Base64 provides no confidentiality at all, which is also why an encoded secret must never be pasted into a forum for a second opinion.

Apple's IPSec dictionary is a useful example of type mattering: it documents SharedSecret as data for the shared-secret authentication method in the L2TP and Cisco IPsec payloads. That is a specific property in a specific payload, not a general text field you can reuse for another protocol that happens to ask for a secret.

A claimed limit belongs to one combination

Old reports of a thirty-two character ceiling on one Apple client are real reports about one client version, protocol and profile shape. They are not a universal limit for every Apple platform, every provider and every protocol. Check the version, the payload type and the gateway requirement together, then test on an approved arrangement rather than inferring from a thread. Write the tested combination into the change record, because the next person will otherwise cite the same thread with more confidence than it deserves.

If a limit genuinely applies, the answer is a supported credential design that fits it, not a shortened version of a strong secret. Truncating a production key to satisfy a guessed limit reduces its strength permanently and produces a system whose documentation no longer matches its security.

Fix the representation, not the strength

When authentication fails after the representation is confirmed, read the effective policy at the authentication stage: which method is being negotiated, which peer identity is expected, and whether the gateway is matching the connection you think it is. Progressively weaker guesses are not diagnosis, they are a slow downgrade with a support ticket attached.

If the required credential cannot meet the organisation's standard, change the design to one that can. A shared secret with enough entropy, generated once, stored in a managed field and never published, is a perfectly good answer; a shorter version of it is not.