FortiClient IKEv2 EAP and Local-User Authentication Checks

For a FortiClient remote-access migration, changing ike-version is not enough: the client profile, EAP exchange and intended user-group policy must agree. A sent EAP identity request with no response narrows the failure to that exchange; it does not automatically implicate a RADIUS server.

Applies to: FortiClient for Windows 7.4.4 product notice and FortiOS 7.4.4 SSL-VPN-to-IPsec migration documentation. The bounded authentication path is a PSK-authenticated IKEv2 dial-up tunnel plus documented local username/password EAP, using user groups in the firewall policy as described in that migration workflow. LDAP/EAP-TTLS, SAML, certificate authentication, macOS, Linux and the free VPN-only release are separate scopes.

Validation: documentation-checked on 12 September 2026. No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.

Identify the client product before planning the migration

The Windows 7.4.4 special notices remove IKEv1 support from that FortiClient product release. They also state that 7.4.4 did not ship a new free VPN-only agent. Do not turn those statements into a claim that FortiGate itself has dropped IKEv1, or that every platform and distribution changed on the same date.

Record the exact installed client product/build, Windows platform, EMS management status if applicable and FortiOS build. Keep those separate from the name assigned to the VPN profile. Plan a supported current deployment independently; the versions here identify the documentation, not a recommendation to downgrade.

Keep gateway authentication and user authentication separate

Layer	This guide’s chosen path	Do not substitute
IKE peer authentication	An agreed protected PSK	A certificate/EAP-TLS recipe with different trust prerequisites
Remote user authentication	Local user credentials through the documented IKEv2 EAP path	IKEv1 XAuth commands
User authorization	Intended local group in the relevant VPN firewall policies	An unrestricted policy that happens to pass traffic
Client addressing and reachability	Mode/address pool, permitted networks, routes and DNS	A successful credential check as proof of data access

The authentication-method matrix and local-user section distinguish these choices. LDAP requires its documented EAP-TTLS prerequisites and must not be inserted into this local-user example. Preserve any required MFA design; do not turn it off to make a diagnostic test pass.

Review the converted tunnel and group placement

The FortiOS 7.4.4 wizard migration procedure converts the remote-access tunnel to IKEv2, enables EAP and requests the client identity. It notes that the wizard’s IKEv1 user-group association is removed during conversion and, in its policy-group design, must be added to the corresponding firewall policies.

Configuration change • incomplete migration template, review prerequisites first

config vpn ipsec phase1-interface
    edit "<existing-dialup-tunnel>"
        set ike-version 2
        set eap enable
        set eap-identity send-request
    next
end

This snippet changes only the existing named dial-up tunnel. It deliberately omits the PSK and does not create the client pool, proposals, policies or a complete working VPN. Coordinate the client profile and group placement before applying it. Do not mix this policy-group design with a different authusrgrp design without reviewing that design’s official instructions.

Interpret the last completed authentication step

Observation	Next check
No IKE SA negotiation	Gateway, transport, version and proposal path
EAP identity request sent, no response	Correct client/profile, selected tunnel, supported EAP behavior and the exchange return path
Identity returned; credential/group rejection follows	Local account, group membership and the chosen policy-group configuration
Authentication succeeds; internal service fails	Assigned address, policy, client routes, DNS and host return path

Compare one client attempt with the gateway’s scoped debug. The endpoint configuration reference lists the client-side IKE version, phase settings and local ID that must match the gateway. In an EMS-managed deployment, verify the delivered profile rather than assuming a local edit remains effective.

Verify the user’s task and keep a coordinated rollback

Use an authorized test account to connect, obtain the intended address and access one permitted application by name. Confirm the user cannot reach a disallowed network. An EAP success message alone does not verify split routing, DNS or authorization.

Keep the previous client profile and exact affected tunnel/policy values privately. If migration fails, restore the coordinated supported profile and gateway settings through independent management. A Windows client that no longer supports IKEv1 cannot use an IKEv1 rollback tunnel; plan that contingency before the window. Do not store passwords in XML, publish debug secrets, remove MFA or recommend a vulnerable client downgrade. Stop the diagnostic output after the attempt.

Version-specific debug and cleanup · Separate gateway-to-gateway migration checklist

Technical references

Found an issue? Send a correction with a reproducible example.