Configure FortiGate IKEv2 remote-access VPN with LDAP and EAP-TTLS

Objective

Provide remote users with an IPsec IKEv2 VPN using a pre-shared key (PSK) for IKE authentication, EAP-TTLS/PAP for LDAP-backed Active Directory credentials, and least-privilege access defined by AD group membership and FortiGate firewall policies.

This article is based on a working FortiGate/FortiClient implementation, with the topology, endpoints, accounts and keys deliberately generalized. Exact GUI paths and availability depend on firmware and client versions.

Security note: PSK + password is not automatically multi-factor authentication. Treat MFA, gateway certificate verification, user lifecycle and PSK rotation as separate security requirements.

Reference topology

Remote Windows endpoint
  FortiClient VPN 7.4.3
       | IKEv2 UDP/500, NAT-T UDP/4500
       v
FortiGate dial-up IPsec interface
       | EAP-TTLS user authentication
       v
LDAP / Active Directory
       |
       +-- VPN-App-Users   -> selected application servers/ports
       +-- VPN-CCTV-Users  -> selected surveillance hosts/ports

Assigned VPN address pool (example): 10.253.200.10–10.253.200.254
Internal DNS: example-only, replace with the real resolver

Do not copy production IP addresses, public hostnames, LDAP bind credentials or PSKs into published configuration files.

Prerequisites

• Configured FortiGate dial-up IPsec IKEv2 gateway and reachable UDP/500 and UDP/4500.
• Working LDAP/LDAPS connectivity to an Active Directory server, with certificate trust where LDAPS is used.
• FortiGate LDAP groups mapped to appropriate AD security groups.
• Defined address objects, VPN client pool, split-tunnel destinations and firewall services.
• FortiClient version with EAP-TTLS support: verify the exact edition and supported features before deploying.
• A certificate identity that clients can authenticate for the EAP-TTLS server; do not disable certificate validation simply to make the connection work.
• A tested rollback path and exported FortiClient configurations if endpoints already contain other VPN profiles.

1. Configure the FortiGate tunnel

Create a dial-up IPsec VPN, selecting:

Cryptographic values above describe the observed setup, not a universal recommendation. Review the current Fortinet hardening guidance and supported stronger proposals for new deployments.

Representative settings (adapt to your interface and existing configuration):

config vpn ipsec phase1-interface
    edit "VPN-IKEV2-USERS"
        set ike-version 2
        set eap enable
        set eap-identity send-request
        set mode-cfg enable
        set proposal aes256-sha256
        set dhgrp 14
        set keylife 86400
        set psksecret <SET-SECURELY-IN-DEVICE>
    next
end

The snippet is illustrative, not a complete paste-ready tunnel definition: interface binding, mode-config pool, selectors, NAT-T, split include group and other settings must be configured and validated for the actual network. Use the supported GUI/wizard or version-matched CLI reference, and never place the PSK in scripts committed to version control. When assigning user groups via individual firewall policies, validate that the phase-1 user group is left to policy inheritance rather than bound to a different broad group.

2. Apply LDAP group-based access policies

Create a FortiGate firewall user group for each AD role and map its remote LDAP group appropriately. Example:

Policy: Allow_VPN_App
Source interface: VPN-IKEV2-USERS
Source address:   VPN_CLIENT_POOL
Source user group: VPN-App-Users
Destination:      APP-SERVER
Service:          APP-REQUIRED-PORTS
Action:           ACCEPT
NAT:              Disabled unless explicitly required
Logging:          All sessions

Repeat separately for surveillance or administrative roles. Do not grant all authenticated VPN users broad LAN access. Check the reverse route to the assigned VPN address pool and test each role with both allowed and denied destinations.

3. Configure FortiClient EAP-TTLS

Fortinet documents <eap_method>2</eap_method> for EAP-TTLS/PAP. The default/other value 1 represents EAP-MSCHAPv2 and is not equivalent for direct LDAP authentication.

Inside the intended FortiClient connection's <ike_settings> block, use:

<ike_settings>
    <version>2</version>
    <eap_method>2</eap_method>
    <!-- Retain the rest of this connection's validated IKE settings. -->
</ike_settings>

This is an XML fragment, not an importable full configuration. Edit an exported, validated configuration and preserve its surrounding structure. FortiClient XML import behavior and schema depend on client version/edition.

On a tested Windows endpoint, the effective setting was confirmed in:

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

Use your own connection name in the registry path. Expected value: 2. Back up the registry first; checking the value does not require changing it. Some exports omit the EAP tag even when the setting remains effective.

4. Validate the VPN configuration

1. Connect with a user who belongs to the intended AD group and confirm an IKEv2 tunnel is established.
2. Verify the client receives an address from the configured VPN pool and the intended split-tunnel routes.
3. Test only the application/service ports allowed by that group's firewall policy.
4. Verify that a user outside the group does not gain the same access.
5. Confirm the firewall logs show the expected VPN interface, policy and authorized destination.

The setup was validated with working IKEv2/LDAP authentication in the described environment. Do not interpret it as evidence that every user group, split network or service was exhaustively tested.

Rollback and recovery

Export/backup the FortiGate configuration before changes. If the new VPN configuration causes an outage, revert the associated Phase 1/Phase 2 and policy changes during an approved maintenance window. Preserve existing tunnels and use least-privilege firewall rules.

Separate troubleshooting article: See FortiClient partial XML import fails when the PSK is missing (related troubleshooting) for full versus partial XML restore and interpreting failed IKE/EAP negotiation.

Security considerations and future MFA

This working PSK + LDAP/EAP-TTLS design does not provide FortiToken MFA by itself. FortiToken support depends on specific FortiOS, FortiClient edition/version and authentication flow; confirm the supported matrix before purchasing or activating tokens. Do not infer MFA capability merely from successful EAP-TTLS password authentication.

Sources

See the vendor references in the frontmatter.