FortiClient IKEv2 VPN fails after partial XML import: missing PSK

Symptom

A working FortiGate IKEv2 + LDAP/EAP-TTLS VPN profile was exported and converted to a partial FortiClient XML import so that endpoints would retain their existing VPN connections.

After importing the sanitized profile, the new VPN failed to connect on two Windows endpoints. FortiClient reported Failed Unknown. Other FortiClient VPN connections remained present.

Confirmed root cause in this case: the partial XML file intentionally omitted the pre-shared key (PSK), and the PSK had not been re-entered after import. Entering the correct PSK in the imported VPN profile resolved the connection failure.

Do not assume every Failed Unknown or IKE/EAP timeout means a missing PSK; verify the endpoint profile and evidence first.

Environment

• FortiClient VPN-only 7.4.3 for Windows
• FortiGate dial-up IKEv2 remote-access VPN with PSK and LDAP-backed EAP-TTLS
• A connection distributed by XML import
• Additional, pre-existing VPNs that must not be overwritten

Full restore versus partial import

These are different operations, with different effects on existing profiles:

The latter was tested on the affected client version: existing VPN profiles remained and the newly imported tunnel worked after the PSK was entered. Do not assume the same behavior for all future FortiClient versions.

Reproduce and diagnose safely

Step 1 — Check the new connection's PSK

Open FortiClient → Remote Access → Edit the imported IPsec VPN.

Verify:

1. Remote gateway name matches the configured FortiGate.
2. IKE version is 2.
3. Authentication is Pre-shared Key.
4. The real PSK has been entered after importing the sanitized XML.
5. User credential prompts are enabled for the intended EAP workflow.

Never put the real PSK in a public article, screenshot, repository or shared plaintext file.

Step 2 — Confirm EAP-TTLS mode

On the tested version, <eap_method>2</eap_method> under <ike_settings> enables the intended EAP-TTLS/PAP client mode. This setting is independent of the PSK: EAP-TTLS correctly selected does not compensate for a missing PSK.

Example fragment:

<ike_settings>
    <version>2</version>
    <eap_method>2</eap_method>
</ike_settings>

The fragment is not a complete import file. On the tested Windows client, this command read the effective setting:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Fortinet\FortiClient\IPSEC\Tunnels\Corporate VPN\P1' -Name eap_method |
    Select-Object eap_method

Expected: 2. Replace Corporate VPN with the installed profile's real display name. A later FortiClient XML re-export may omit this field even when the registry shows it is active.

Step 3 — Review the observed FortiGate IKE sequence

In the affected case, FortiGate debug showed:

matched proposal id 1
SA proposal chosen, matched gateway VPN-IKEV2
NAT detected: PEER
gw validation OK
responder preparing EAP identity request
sent IKE msg (AUTH_RESPONSE)
...
negotiation timeout, deleting

This output does not prove that the PSK succeeded, nor does it prove an LDAP failure. IKE SA_INIT proposals were accepted, and FortiGate waited for the next expected exchange.

A narrow packet capture showed exactly the initial bidirectional UDP/500 and UDP/4500 packets, with no observed subsequent client response within the capture:

client:500   -> gateway:500   (IKE_SA_INIT)
gateway:500  -> client:500
client:4500  -> gateway:4500  (IKE_AUTH)
gateway:4500 -> client:4500  (EAP identity request)

Example capture command, replacing the interface and documentation address:

diagnose sniffer packet <wan-interface> 'host 198.51.100.22 and (udp port 500 or udp port 4500)' 4 0 a

Step 4 — Check client symptoms

The FortiClient GUI/service log showed:

vpn connection failed (reason: "Failed Unknown")
disconnection reason: 13, ("Failed Unknown")

Those are general errors, not proof of an incorrect user password or LDAP group.

If the PSK is already present, continue investigating FortiIKE client logs, EAP-TTLS certificate trust and gateway identity, and packet capture on both endpoints. Do not change AD groups or firewall policies without authentication evidence.

Resolution confirmed

1. Open the imported VPN's settings.
2. Enter the correct pre-shared key that matches the FortiGate dial-up gateway.
3. Save the profile.
4. Retry the connection with the user's AD credentials.
5. Confirm the new tunnel connects.
6. Confirm the pre-existing VPN entries were preserved.

This action resolved the observed failure. No FortiGate LDAP, group policy or Phase 1 crypto change was required.

Prevention: distribute profiles without secrets

• Export a backup of the user's existing FortiClient configuration before making changes.
• Clearly label a partial XML package as "PSK intentionally omitted — enter after import."
• Document the two import modes for support staff.
• Supply the PSK separately through an approved secure channel.
• Test imported profiles on a clean endpoint and one endpoint with existing VPNs.
• Avoid assuming that encrypted PSK values exported from one machine can be reused across other clients.

Security and collection of evidence

FortiGate diagnose debug application ike -1 can expose sensitive session-key material and endpoint identifiers. Avoid distributing raw traces. Remove SK_ei, SK_er, SK_ai, SK_ar, packet hex, usernames, serial numbers and MAC addresses before sharing diagnostic evidence.

Rollback

If an imported VPN profile behaves incorrectly, revert that newly created profile or restore the endpoint's previously exported full FortiClient configuration backup. Do not run a full restore from a one-VPN XML file on endpoints that already contain other required VPN profiles.

Sources

See the Fortinet references in frontmatter.