FortiGate Remote Access IPsec VPN Configuration and Verification

Modern enterprise networks require secure, high-performance remote access solutions for distributed workforces. While SSL VPNs are popular, a FortiGate remote access IPsec VPN provides superior throughput, robust encryption, and seamless integration with native operating system clients and FortiClient. This comprehensive guide details the design, configuration, traffic flow, and troubleshooting of an enterprise-grade dialup IPsec VPN using FortiOS.

Real-Life Scenario

An enterprise organization requires secure remote connectivity for off-site employees. Remote users connect from varying external IP addresses using FortiClient. They must access corporate resources hosted on the internal LAN network (10.10.10.0/24) without routing their general internet browsing through the corporate firewall. The solution requires split tunneling, strong IKEv2 encryption, local user group authentication, and precise firewall access controls.

Lab Topology

The network topology consists of a remote user running FortiClient on the internet, connecting to the primary WAN interface of the enterprise FortiGate firewall. The FortiGate inspects the encrypted traffic and routes authorized traffic to the internal LAN.

+---------------------+
| Remote User Client  |
| FortiClient (Dynamic|
| Public IP Address)  |
+----------+----------+
           |
           | Encrypted IPsec Tunnel (IKEv2)
           v
+----------+----------+
|  Internet / WAN     |
+----------+----------+
           |
           | Public IP: 198.51.100.10/24 (LAB EXAMPLE)
    [wan1 Interface]
+----------+----------+
|  FortiGate Firewall |
|   (FG-100F Target)  |
    [port1 Interface]
           | Internal LAN IP: 10.10.10.1/24 (LAB EXAMPLE)
           v
+----------+----------+
| Internal Enterprise |
| Network (10.10.10.0)|
+---------------------+

Example Addressing and Objects

All IP addresses, hostnames, and credentials used in this tutorial are simulated lab values. Production environments must adapt these objects to match their designated IP schemes and security standards.

Prerequisites

Before configuring the IPsec tunnel, ensure the following prerequisites are met in your environment:

• A valid FortiOS image running on your hardware or VM platform. Menu options and syntax remain consistent across modern FortiOS releases, though subtle layout differences exist between major versions.
• A reachable static public IPv4 address assigned to the FortiGate WAN interface.
• Administrative access to the FortiGate GUI and CLI.
• FortiClient software installed on the remote workstation.

Step-by-Step GUI Configuration

Step 1: Create the User and User Group

First, define the local user credentials and group that will be allowed to authenticate to the VPN tunnel.

1. Navigate to User & Authentication > User Definition.
2. Click Create New, select Local User, and click Next.
3. Specify a username (e.g., vpnuser1) and set a secure password. Click Next.
4. Enter an optional email address and click Submit.
5. Navigate to User & Authentication > User Groups.
6. Click Create New. Name the group Remote-VPN-Users.
7. Under Members, select vpnuser1 and click OK.

Step 2: Create Firewall Address Objects

Next, define the internal subnet and client VPN pool address objects used for policies and split tunneling.

1. Navigate to Policy & Objects > Addresses.
2. Click Create New > Address.
3. Configure the LAN Subnet object:
   • Name: LAN-Subnet
   • Type: Subnet
   • IP/Netmask: 10.10.10.0/255.255.255.0
   • Interface: port1 (or Any)
4. Click OK.
5. Click Create New > Address again to define the VPN Client range:
   • Name: VPN-Client-Subnet
   • Type: Subnet
   • IP/Netmask: 10.200.10.0/255.255.255.0
   • Interface: Any
6. Click OK.

Step 3: Configure the IPsec VPN Tunnel Wizard or Custom Setup

You can create the tunnel using the built-in wizard or custom mode. For maximum precision and insight, use the Custom path.

1. Navigate to VPN > IPsec Tunnels.
2. Click Create New > IPsec Tunnel.
3. Enter the Name: RA-IPSEC-VPN.
4. Select Custom and click Create.
5. In the Network section:
   • IP Version: IPv4
   • Remote Gateway: Dialup User
   • Interface: wan1
   • Mode Configuration: Enable
   • Assign IP Settings: Range
   • Start IP: 10.200.10.100
   • End IP: 10.200.10.200
   • Subnet Mask: 255.255.255.0
   • DNS Server: Specify an internal DNS server (e.g., 10.10.10.2)
6. In the Authentication section:
   • Method: Pre-shared Key
   • Pre-shared Key: Set a strong, secure pre-shared key (e.g., LAB_EXAMPLE_SECRET_KEY)
   • IKE Version: 2
   • User Group: Enable and select Remote-VPN-Users
7. In the Phase 1 Proposal section:
   • Select cryptographic suites matching organizational policy (e.g., Encryption: AES256, Authentication: SHA256, Diffie-Hellman Group: 14).
8. In the Advanced section:
   • Enable IPv4 Split Tunnel: Enable
   • Accessibility networks: Select LAN-Subnet
9. In the Phase 2 Selectors section:
   • Expand Phase 2 Selectors.
   • Local Address: Select LAN-Subnet (or leave empty 0.0.0.0/0 if split-include handles routing).
   • Remote Address: Leave empty (0.0.0.0/0).
   • Under Advanced, ensure Phase 2 proposals match client standards.
10. Click OK to save the tunnel configuration.

Step 4: Create the Firewall Security Policy

Traffic arriving from an IPsec virtual interface is blocked by default until explicit permission is configured in the firewall policy table.

1. Navigate to Policy & Objects > Firewall Policy.
2. Click Create New.
3. Configure the policy settings:
   • Name: Allow-RA-VPN-to-LAN
   • Incoming Interface: RA-IPSEC-VPN
   • Outgoing Interface: port1
   • Source: VPN-Client-Subnet
   • Destination: LAN-Subnet
   • Schedule: always
   • Service: Select specific required services (e.g., HTTPS, RDP, SSH) or ALL for testing.
   • Action: ACCEPT
   • NAT: Disabled (unnecessary when routing directly to internal ranges).
4. Click OK to activate the firewall policy.

CLI Configuration

Engineers often prefer configuring IPsec parameters via the CLI for efficiency and consistency. Below is the exact production-ready CLI structure for this implementation.

config user local
    edit "vpnuser1"
        set type password
        set passwd "LAB_EXAMPLE_PASSWORD"
    next
end

config user group
    edit "Remote-VPN-Users"
        set member "vpnuser1"
    next
end

config firewall address
    edit "LAN-Subnet"
        set subnet 10.10.10.0 255.255.255.0
    next
    edit "VPN-Client-Subnet"
        set subnet 10.200.10.0 255.255.255.0
    next
end

config vpn ipsec phase1-interface
    edit "RA-IPSEC-VPN"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set ipv4-start-ip 10.200.10.100
        set ipv4-end-ip 10.200.10.200
        set ipv4-netmask 255.255.255.0
        set ipv4-dns-server1 10.10.10.2
        set ipv4-split-include "LAN-Subnet"
        set proposal aes256-sha256 aes128-sha256
        set dpd-retryinterval 10
        set dhgrp 14 5
        set psksecret "LAB_EXAMPLE_SECRET_KEY"
        set authusrgrp "Remote-VPN-Users"
    next
end

config vpn ipsec phase2-interface
    edit "RA-IPSEC-VPN"
        set phase1name "RA-IPSEC-VPN"
        set proposal aes256-sha256 aes128-sha256
        set dhgrp 14 5
    next
end

config firewall policy
    edit 10
        set name "Allow-RA-VPN-to-LAN"
        set srcintf "RA-IPSEC-VPN"
        set dstintf "port1"
        set srcaddr "VPN-Client-Subnet"
        set dstaddr "LAN-Subnet"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end

How the Traffic Flows

Understanding the internal FortiOS packet handling process helps engineers design better security policies and diagnose connection issues effectively.

1. IKE Phase 1 Negotiation: The remote client initiates an IKEv2 connection to the public IP on interface wan1 (UDP port 500/4500). FortiGate matches the request against dynamic Phase 1 definitions using the Pre-Shared Key.
2. Authentication & Mode Configuration: FortiGate authenticates the user credentials against the specified user group (Remote-VPN-Users). Upon successful authentication, FortiGate pushes an IPv4 address from the pool (10.200.10.100-200), DNS servers, and split-tunnel routing rules (10.10.10.0/24) to the client.
3. Phase 2 Security Association (SA): Cryptographic keys are agreed upon to form the ESP tunnel. FortiGate dynamically generates a point-to-point interface association for the connected client.
4. Ingress Packet Evaluation: When the client sends traffic to 10.10.10.15, the encrypted ESP packet enters wan1, gets decrypted by the hardware/software crypto engine, and emerges inside the virtual interface RA-IPSEC-VPN.
5. Route Lookup & Policy Match: FortiGate evaluates its routing table to reach 10.10.10.15, identifying port1 as the outbound egress interface. Next, FortiGate queries the firewall policy table matching incoming interface (RA-IPSEC-VPN), outgoing interface (port1), source IP (10.200.10.100), and destination IP (10.10.10.15).
6. Stateful Session Handling: Once Policy ID 10 grants access, FortiGate creates a stateful session entry in its kernel session table, forwarding decrypted packets to internal destinations and tracking return flows.

Verification

To verify proper operation of your FortiGate remote access IPsec VPN, run these state checks on the FortiGate CLI after connecting from FortiClient.

Check Active IPsec Tunnel Status

get vpn ipsec tunnel summary

This command provides a rapid overview of active tunnels, Phase 1 status, Phase 2 security associations, and packet counters.

Inspect Phase 1 Gateway Details

diagnose vpn ike gateway list name RA-IPSEC-VPN

This check validates the assigned client IP, connected remote peer public IP, negotiated algorithms, and active user identity.

Review Active Phase 2 Selectors

diagnose vpn tunnel list name RA-IPSEC-VPN

This command displays exact SPI numbers, active dynamic selectors, encapsulated packet counts, and encryption/decryption byte totals.

Verify Kernel Routing Table

get router info routing-table all

Confirm that dynamic interface routes exist pointing connected client addresses back through the virtual IPsec interface.

Troubleshooting

When troubleshooting remote access VPN connectivity, follow a systematic diagnostic approach: link/interface check -> IKE Phase 1 negotiation -> Phase 2 negotiation -> firewall policy -> packet capture.

Symptom 1: Phase 1 Fails to Establish (Authentication or Proposal Mismatch)

If Phase 1 fails, the client cannot negotiate cryptographic keys or fails local user authentication.

Safe Troubleshooting Steps: Execute an IKE process debug to view detailed negotiation messages in real time.

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

Attempt a connection from FortiClient. Look for common error strings in the CLI output:

• PSK mismatch: Verify the pre-shared keys configured on both ends match exactly.
• no proposal chosen: Encryption, hash, or Diffie-Hellman groups between FortiGate and FortiClient do not match.
• user password error / group mismatch: Credentials failed validation or the user is not in the assigned group.

Cleanup Step: Turn off active debug outputs immediately after testing.

diagnose debug disable
diagnose debug reset

Symptom 2: Tunnel Establishes, but Internal Resources are Unreachable

If Phase 1 and Phase 2 establish successfully, but traffic fails to reach internal destinations, the issue usually involves firewall policy or routing.

1. Check Firewall Logs: Verify that traffic is not being dropped by implicit deny policies.

   execute log filter category 0
   execute log filter field subtype forward
   execute log display
   

2. Verify Split Tunnel Settings: Check FortiClient routing tables to ensure routes for internal networks are added upon connection.
3. Check End-Host Gateways: Ensure internal servers (e.g., 10.10.10.15) have a default gateway pointing back to FortiGate (10.10.10.1) or local host firewalls (Windows Defender) are not dropping off-subnet traffic.

Common Mistakes

• Overlapping Subnets: Client home networks often use common subnets like 192.168.1.0/24 or 192.168.0.0/24. If your enterprise LAN uses these identical spaces, client routing breaks. Use non-standard internal space (e.g., 10.10.10.0/24).
• Missing Policy for Remote IPsec Interface: Creating the IPsec tunnel creates the virtual interface, but traffic will not pass until explicit Firewall Policies map `RA-IPSEC-VPN` to destination internal zones.
• Forgotten Central NAT / SNAT Conflict: Enabling Source NAT on the internal policy unnecessarily rewrites remote client IP addresses, causing tracking issues on internal servers.
• Mismatched Split-Tunnel Objects: The network address object selected in `ipv4-split-include` must strictly match the network definitions intended for client routing.

Production Considerations

• Strong Authentication: In production environments, replace local user password authentication with centralized identity providers using RADIUS, LDAPS, or SAML-based Multi-Factor Authentication (MFA).
• Certificate-Based Authentication: Implement Machine Certificates (PKI) in Phase 1 to guarantee only corporate-managed devices can initiate dynamic IPsec tunnels.
• Redundancy and High Availability: For high-availability environments, terminate IPsec tunnels on Loopback interfaces associated with SD-WAN or Dual WAN link configurations to preserve connectivity during ISP failures.
• Hardware Acceleration: Modern FortiGate units utilize NP6/NP7 network processors to offload IPsec ESP encryption and decryption in hardware, offering minimal CPU impact even under maximum throughput loads.

Related FortiGate Guides

• FortiGate site-to-site IPsec VPN
• FortiGate IPsec VPN troubleshooting
• FortiGate SSL VPN
• FortiGate session troubleshooting

Summary

Deploying a FortiGate remote access IPsec VPN provides enterprise networks with robust performance, rigid encryption standards, and granular firewall control. By carefully defining Phase 1 parameters, Mode-CFG dynamic pools, split-tunnel rules, and explicit firewall policies, administrators can build a scalable, highly secure remote access architecture. Utilizing FortiGate diagnostic utilities allows engineers to maintain optimal uptime and resolve connection issues efficiently.