FortiGate IPsec IKEv2 VPN with FortiToken MFA and local users

Tested outcome and scope

Lab tested: A FortiGate 40F running FortiOS 7.6.8 accepted an IKEv2 dial-up connection from a Windows FortiClient VPN-only installation, prompted for FortiToken Mobile, and ultimately established the VPN. The account was local to the FortiGate, not an Active Directory or LDAP account.

Not established by the lab: Connectivity to an internal test host, production policy behavior, LDAP/RADIUS interoperability, or universal compatibility with every FortiClient release. This guide documents the working local-user approach only.

Topology and prerequisites

• FortiGate 40F with FortiOS 7.6.8.
• Windows computer with FortiClient VPN-only; version 7.4.3 was used during the lab work.
• FortiToken Mobile available and activated for a FortiGate local user.
• An individual FortiGate user group containing that user.
• A unique dial-up VPN client address pool that does not overlap with LANs.
• If the FortiGate WAN is behind an ISP router, forward UDP/500 and UDP/4500 to its WAN address; confirm that the operator provides reachable public IPv4 (not unhandled CGNAT). UDP/1701 is not required for IKEv2.
• Administrator access and a configuration backup, plus a separate management path in case VPN settings need rollback.

1. Create the user and FortiToken

In User & Authentication → User Definition, create a Local User with a strong password and enable Two-factor Authentication → FortiToken. Complete token activation on the approved phone. Create a FortiGate user group (example: VPN_IKEV2_MFA_LAB) and add this user.

Security: Do not publish enrollment QR codes, token serials, passwords, recovery codes, or activation email addresses.

2. Create the IPsec Phase 1 in the GUI

Navigate to VPN → IPsec Tunnels → Create New → Custom. Values used in this lab:

The tunnel's underlying interface name has a 15-character limit in the tested interface. An attempt to create VPN_IKEV2_MFA_LAB failed with string value is too long ... limit is 15, causing subsequent set commands to fail with Unknown action 0. The shorter VPN_IKEV2_MFA was used instead. This is not a firmware or FortiToken failure.

Set split routing to only the intended internal test prefix. Do not route unrelated production traffic into a lab tunnel. Do not expose the FortiGate management GUI to arbitrary VPN users.

3. Configure Phase 2

Create a Phase 2 selector with:

Broad selectors are not access control. Restrict reachability using least-privilege firewall policies, mode-config split routing, and local-in controls for any management-plane access.

4. Configure FortiClient

Create an IPsec VPN profile in FortiClient:

1. Remote Gateway = public IPv4 or DNS name of the ISP router / exposed FortiGate.
2. Authentication = the exact PSK defined in Phase 1.
3. IKE = Version 2.
4. User authentication = Prompt on login.
5. Phase 1 = AES256/SHA256, DH14; Phase 2 = AES256/SHA256, PFS DH14.
6. Use the EAP-MSCHAPv2 client flow (the default eap_method=1 in the tested setup). Do not change to eap_method=2 merely because MFA is enabled; EAP-TTLS is a different method and was not used for this local-user lab.

Test from an external network (for example, a mobile hotspot), not only from the ISP router's internal network, to avoid NAT loopback confusion.

5. Validate MFA separately from tunnel access

The tested sequence was: enter the FortiGate local username and password → receive a FortiToken Mobile prompt → complete the token challenge → VPN connects.

A token prompt alone is not proof that MFA succeeded. Confirm the tunnel reaches an established state in the FortiClient and the FortiGate VPN events. Only then test approved data-plane or management-plane destinations.

To investigate a failure, start with Log & Report → Events → VPN Events. Use a short IKE debug when required:

diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application ike -1
diagnose debug enable

Make one test and stop promptly:

diagnose debug disable
diagnose debug reset

Redact all secrets, public IP addresses tied to a private organization, usernames, token codes and device identifiers from exported evidence.

Common failure patterns

Security and operational notes

• Bind a named group to the dial-up tunnel; do not accidentally authorize every local account.
• Keep PSKs and FortiToken assignment under controlled administrative access.
• Limit policies by source group, destination address and service; enable logs.
• FortiGate local users and Active Directory users authenticated through LDAP or RADIUS are different architectures. This lab does not demonstrate AD-backed FortiToken.
• Capture a backup and document rollback before applying to production.

Rollback

Disable the test tunnel or remove its dedicated policies, group and local user after validating they have no other dependencies. Retain administrative access outside the test VPN.