pjhtech Tools
FortiGate

FortiClient IKEv2 Migration: Enable EAP and Restore User Groups

Fix the PSK/local-user migration settings: enable EAP, restore policy groups and remove the conflicting tunnel-level group binding.

For a FortiClient PSK/local-user tunnel migrated to IKEv2, enable EAP and put the local user group on the VPN-to-LAN policy. With that policy-group method, remove the old tunnel-level authusrgrp binding. The commands below apply to this migration case, not certificate or SAML authentication.

Scope: FortiClient Windows to FortiGate dial-up IPsec, PSK plus local-user EAP with groups in firewall policies. Certificate, SAML and LDAP/EAP-TTLS designs differ.

Check the delivered client profile

Open the connection’s edit view under FortiClient → Remote Access. Check Remote Gateway and Authentication Method (Pre-shared key). In Advanced Settings → VPN Settings, check IKE version; in Phase 1, compare Local ID, proposal and DH Group with the gateway. On an EMS-managed client, inspect the delivered profile; a local edit may not be the effective configuration. Use the endpoint settings as the comparison points.

IKEv1 XAuth settings do not configure IKEv2 EAP.

Enable EAP and restore the group association

In the documented wizard conversion, the IKEv1 group association is removed and the group must be applied to the relevant firewall policies. Check this before interpreting an authentication success as authorization to the LAN. Wizard conversion procedure.

Run the change in the existing dial-up tunnel’s VDOM. A global administrator on a multi-VDOM unit enters config vdom and edit "<tunnel-vdom>" first; after the tunnel and group checks, use next and end to leave that context.

Configuration change • existing PSK dial-up tunnel in its owning VDOM
config vpn ipsec phase1-interface
    edit "<existing-dialup-tunnel>"
        set ike-version 2
        set eap enable
        set eap-identity send-request
    next
end

Keep the existing address pool and agreed proposals. Complete the policy-group association below before reconnecting the client; this method requires authusrgrp to be unset on the tunnel.

Put the local group on the VPN policy

In the tunnel’s VDOM, open User & Authentication → User Groups, edit the expected local group and check its Members. Add the intended existing local user if missing. Under Policy & Objects → Firewall Policy, edit each VPN-to-LAN policy that should authorize that group and add it to Source, keeping the VPN client-pool address object already there. The documented wizard policy names begin with vpn_.

Read-only • run in the tunnel’s VDOM
show full-configuration vpn ipsec phase1-interface "<existing-dialup-tunnel>"
show user group
show firewall policy

Confirm ike-version 2, eap enable and eap-identity send-request. In the group find member; in the intended policy check srcintf is the VPN, srcaddr is the client pool, groups includes the local group and dstaddr/service limit access to the intended LAN service. Check earlier policies for a broader VPN permit that would bypass the intended restriction.

For the policy-group method, phase 1 authusrgrp must be unset, even if it names the same group. If a group is still configured there, after adding the intended policy groups remove that tunnel-level binding with unset authusrgrp inside the existing phase 1 object. This changes authorization for new connections; coordinate it with the policy edits. Single and multiple group configuration.

EAP identity request has no client response

If debug stops at EAP identity request sent, no response, the client has not answered the identity request. Check the delivered client profile and its supported authentication method before changing group membership. This message alone does not establish a RADIUS fault. Use filtered IKE debug for one reconnect and stop it afterward.

Keep client and gateway changes paired

When reverting, restore the profile and the matching tunnel/policy settings together. Stop debug after the test; it can expose authentication material.

References