FortiClient (Linux) never decrypts the IPsec preshared key from an SAML XML profile — IKE_AUTH fails with "failed to decrypt pre-shared key"

SUMMARY

On FortiClient for Linux, an IPsec IKEv2 + SAML tunnel imported from an exported XML configuration always fails at IKE_AUTH, even though SAML authentication completes successfully and the encrypted PSK field, password, and profile are all correct. Root-cause analysis shows the client never decrypts the field-level encrypted preshared key (EncX... format) before handing it to iked - it passes the raw encrypted blob through as if it were the plaintext key.

ENVIRONMENT

FortiClient (Linux), tested and reproduced identically on:

- 7.4.3.5411

- 7.4.4.1796 (includes the fix for Bug ID 1035496, connection problems with SAML, multifactor authentication, and Linux CLI options)

- 7.4.8.1904

OS: Debian 13 (Trixie), amd64 - same .deb package family as the supported Ubuntu builds.

Connection type: IPsec IKEv2, Preshared Key + SAML/SSO (sso_enabled=1, ike_saml_port=9443), imported via Configure VPN > XML > Import XML Configuration from a profile exported on a Windows FortiClient install.

STEPS TO REPRODUCE

1. On a Windows FortiClient install, export a configuration containing an IPsec IKEv2 connection with authentication_method = Preshared Key and SAML/SSO enabled. The exported XML stores the PSK as <preshared_key>EncX <hex>...</preshared_key>.

2. On FortiClient (Linux), import this XML via Configure VPN > XML > Import XML Configuration, entering the correct decryption password (verified: the import succeeds and the resulting profile shows PROTOCOL: IPSEC with SSO: Enabled).

3. Click Connect. The embedded SAML browser opens, the user authenticates against the IdP (Microsoft/Entra ID in our case), and the client receives a valid token_id. The SAML flow closes with outcome=SUCCESS.

4. iked proceeds to IKE_SA_INIT, negotiates proposals successfully with the peer, then attempts IKE_AUTH and fails every time.

EXPECTED BEHAVIOR

IKE_AUTH completes using the (decrypted) preshared key, and the IPsec SA is established.

ACTUAL BEHAVIOR

/var/log/forticlient/ipsecvpn.log (debug level) shows, on every attempt:

ikev2_msg_auth: initiator auth data length 643

ikev2_init_auth: failed to decrypt pre-shared key

sa_state: SA_INIT -> CLOSED

sa_free: failed to initiate IKE_AUTH exchange

ROOT CAUSE (isolated and confirmed)

Decoding the exact PSK value that confighandler writes into the generated iked.conf for this connection (the psk 0x<hex> field) shows that it is NOT a decrypted key at all - it is the literal ASCII text of the still-encrypted EncX <hex> field exactly as it appears in the source XML, byte-for-byte, hex-encoded. In other words, the per-field encryption applied to preshared_key in the exported XML is never decrypted anywhere in the Linux client's import -> storage -> iked-config-generation pipeline.

This was confirmed two ways:

- The same undecrypted value appears whether the profile was imported once and carried across an in-place version upgrade, or freshly re-imported from scratch on each of the three tested versions above.

- Re-exporting the already-imported profile via Backup or restore configuration, choosing our own new (correct, verified) backup password, produced a file whose preshared_key field was identical, byte-for-byte, to the field in the original source XML. This rules out an incorrect import password as the cause - the client never attempts the decryption at all, on any code path we could exercise.

This appears distinct from the previously reported and partially-fixed "/opt/forticlient/iked: invalid option -- 'P'" issue (see the thread "forticlient for linux - invalid option -- 'P'" in this forum), which prevented iked from starting at all on 7.4.0.x and was fixed by Bug ID 1035496. We hit that issue too on 7.4.3.5411, confirmed it fixed on 7.4.4.1796 and 7.4.8.1904 (iked starts fine, full parent/ca/control/ikev2 process tree), but the PSK-decryption failure described here persists on both of those later builds.

SECONDARY FINDING (environment-related, may be worth documenting)

Separately, on a systemd-managed install, confighandler (running as root via forticlient.service) has no XDG_RUNTIME_DIR in its environment, so it cannot reach the logged-in user's session to open the embedded SAML browser window at all (Failed to send message to fortitray: runtime directory not found). We worked around this locally with a systemd drop-in (Environment=XDG_RUNTIME_DIR=/run/user/<uid>) on forticlient.service. This may be worth a documentation note or a service-unit fix for the SAML-over-IPsec flow on Linux distros using systemd + XDG session directories.

IMPACT

Any FortiClient (Linux) user with an IPsec IKEv2 + SAML profile whose PSK was delivered via an XML export (the standard distribution method when EMS is not in use) cannot connect at all, on any 7.4.x build we tested. SAML/MFA and the network path all work correctly - only the final PSK-based IKE_AUTH step fails.

Happy to provide full debug logs, the systemd drop-in, or any other detail that would help reproduce/fix this.