Scope: FortiOS 7.6.5, IPv4 dial-up IPsec, IKEv2, PSK plus local-user EAP, and split tunneling. The Windows example uses an approved FortiClient Standalone 7.4.7 VPN profile. Commands and addresses are illustrative and have not been run on a firewall in this guide.
All FortiGate configuration and verification below use the CLI. Windows profile deployment also uses the CLI, but requires a compatible, known-good XML profile. Fortinet documents the Windows connection CLI for existing GUI-configured tunnels. It cannot create a tunnel, and the import-to-connect sequence should be validated on the exact client build before rollout.
0. Plan the change and take a backup
In the correct VDOM, verify that wan1 faces the Internet and lan reaches 10.40.10.0/24. The client range is 10.250.40.10–10.250.40.50 and the test destination is 10.40.10.20:443. Use a non-overlapping range, verify that the existing policy ID 4100 is unused, and replace every example object name and secret as appropriate. Check existing dial-up profiles on the WAN for ambiguous peer matching. Back up the config to an approved destination and verify the backup before proceeding.
get system status
show system interface wan1
show system interface lan
show vpn ipsec phase1-interface
show firewall policy 4100
Keep configuration output private. Use execute backup config ? to select a supported backup destination for your appliance. If the gateway is behind upstream NAT, verify that UDP 500 and 4500 reach the correct FortiGate WAN address. A TCP/443 connection test does not test these UDP ports.
1. Create the pilot account and address objects
config user local
edit "ra-pilot"
set type password
set passwd "REPLACE_WITH_UNIQUE_USER_PASSWORD"
next
end
config user group
edit "RA-IPSEC-USERS"
set member "ra-pilot"
next
end
config firewall address
edit "RA-CORP-LAN"
set subnet 10.40.10.0 255.255.255.0
next
edit "RA-CLIENT-POOL"
set type iprange
set start-ip 10.250.40.10
set end-ip 10.250.40.50
next
edit "RA-HTTPS-TEST"
set subnet 10.40.10.20 255.255.255.255
next
end
2. Configure the dial-up Phase 1 and Phase 2
config vpn ipsec phase1-interface
edit "RA-IKEv2"
set type dynamic
set interface "wan1"
set ike-version 2
set authmethod psk
set peertype any
set net-device disable
set proposal aes256-sha256
set dhgrp 19
set nattraversal enable
set eap enable
set eap-identity send-request
set authusrgrp "RA-IPSEC-USERS"
set mode-cfg enable
set ipv4-start-ip 10.250.40.10
set ipv4-end-ip 10.250.40.50
set ipv4-netmask 255.255.255.0
set ipv4-split-include "RA-CORP-LAN"
set psksecret "REPLACE_WITH_UNIQUE_STRONG_PSK"
next
end
config vpn ipsec phase2-interface
edit "RA-IKEv2-P2"
set phase1name "RA-IKEv2"
set proposal aes256-sha256
set pfs enable
set dhgrp 19
next
end
The PSK and EAP user password are separate. Keep both out of shared transcripts and scripts. The split include advertises which destination uses the VPN. The firewall policy controls what the authenticated client may access. Match the IKE and ESP proposals and DH/PFS settings in the client profile. This example leaves Phase 2 selectors at the defaults for the dial-up profile. Check compatibility with your client and design before narrowing them.
3. Add the VPN-to-LAN policy and verify the return path
config firewall policy
edit 4100
set name "RA-IKEv2-Pilot-HTTPS"
set srcintf "RA-IKEv2"
set dstintf "lan"
set srcaddr "RA-CLIENT-POOL"
set dstaddr "RA-HTTPS-TEST"
set action accept
set schedule "always"
set service "HTTPS"
set nat disable
set logtraffic all
next
end
Use this NAT example where per-policy NAT is configured. If Central SNAT is enabled, omit the policy NAT setting and check the Central SNAT rules for this flow. Verify policy order. If another Layer 3 device is the server’s gateway, it must route the VPN pool back through the FortiGate. Check the actual gateway before adding a route. Do not add a broad policy to work around a missing return path.
4. Import a Windows FortiClient profile from PowerShell
Obtain an approved FortiClient VPN XML profile from a working pilot configuration or your deployment team. Its profile name should be RA-IKEv2, its gateway your real FQDN, and its settings should match IKEv2, Mode Config, EAP credential prompts, PSK, and the Phase 1/Phase 2 proposals above. Fortinet documents the PSK field as encrypted in the profile schema. Use a supported export and import workflow and do not paste a plaintext PSK into that field. Back up the existing client configuration and test the import on one endpoint. Run the import from an elevated PowerShell session and adjust paths for the installation.
$configTool = @("$env:ProgramFiles\Fortinet\FortiClient\FCConfig.exe", "${env:ProgramFiles(x86)}\Fortinet\FortiClient\FCConfig.exe") | Where-Object { Test-Path $_ } | Select-Object -First 1
if (-not $configTool) { throw "FCConfig.exe not found" }
& $configTool -m vpn -f "C:\Secure\RA-IKEv2.xml" -o importvpn -i 1
if ($LASTEXITCODE -ne 0) { throw "FortiClient VPN profile import failed: $LASTEXITCODE" }
Use the documented encrypted-file import option if required by your approved profile. Do not put a real decryption password in a shared script or terminal transcript. EMS-managed or locked endpoints may require the deployment team to assign the profile.
5. Connect and verify from the command line
On a Windows Standalone build that provides FortiVPN.exe, run the following as the intended interactive user. Verify that the imported tunnel appears in the list before trying to connect. The example omits a password argument to avoid exposing it in the command line. If your build or profile requires an unsupported interaction or does not prompt for credentials, record that as a client limitation and validate the supported sign-in path before rollout.
$vpn = "$env:ProgramFiles\Fortinet\FortiClient\FortiVPN.exe"
if (-not (Test-Path $vpn)) { throw "FortiVPN.exe not found at the expected path" }
& $vpn --cli --list
& $vpn --cli --connect --tunnel "RA-IKEv2" --username "ra-pilot"
& $vpn --cli --status --tunnel "RA-IKEv2"
ipconfig
route print -4
Test-NetConnection 10.40.10.20 -Port 443
get vpn ipsec tunnel summary
diagnose vpn ike gateway list
diagnose vpn tunnel list
Confirm that the client IP is within the pool, that the route to the test server uses the VPN, and that TcpTestSucceeded is true. Then verify the application itself and review the matched policy log. Restrict access to detailed VPN diagnostic output because it can include sensitive key material.
6. Troubleshoot one connection attempt
If IKE traffic never arrives, check public DNS and upstream UDP forwarding. If negotiation starts but authentication fails, compare the PSK, proposals, EAP settings, and group membership. For a short IKE debug, use the actual public IP of the test client as seen by the FortiGate. Coordinate with other administrators before resetting or enabling shared debug state.
diagnose debug reset
diagnose vpn ike log filter clear
diagnose vpn ike log filter rem-addr4 198.51.100.25
diagnose debug application ike -1
diagnose debug enable
Reproduce once, then stop debug immediately.
diagnose debug disable
diagnose vpn ike log filter clear
diagnose debug reset
If the tunnel is up but traffic fails, check the assigned IP, Windows route, subnet overlap, VPN-to-LAN policy hit and server return path. If an IP test succeeds but a hostname fails, check DNS separately.
7. Disconnect or roll back the pilot
& $vpn --cli --disconnect --tunnel "RA-IKEv2"
For a failed pilot, first disable only the newly created policy after confirming its ID and name. Remove the pilot profile from test endpoints. If you need to remove the FortiGate configuration, remove the dedicated policy and other references before Phase 2, Phase 1, and the pilot objects. Leave shared objects in place. Use the validated backup and the approved change procedure if a restore is required.
References and GUI companion
FortiGate dial-up example · FortiOS Phase 1 CLI reference · FCConfig import syntax · Windows Standalone CLI · IPsec diagnostics
For the same topology with a visual walkthrough, see FortiGate Remote Access IPsec VPN with FortiClient.