FortiGate IPsec Remote Access VPN Setup Guide | FortiOS 7.x

FortiGate IPsec Remote Access VPN

I set this up whenever remote employees need encrypted access into a corporate LAN without a fixed site-to-site link on the other end. Unlike a site-to-site tunnel, a remote access (dial-up) VPN accepts connections from client devices on unknown, changing public IPs — laptops on home Wi-Fi, hotel networks, mobile hotspots — and still gets them a secure tunnel back to internal resources.

Below is the full workflow I use to deploy an IPsec Remote Access VPN on a FortiGate running FortiOS 7.x, paired with the FortiClient VPN app on the user’s machine.

The Network Blueprint & Parameters

To keep this walkthrough consistent, I’ll use these parameters throughout — swap in your own values as you follow along:

Phase 1: Identity & Authentication

I never let remote access authenticate against anything other than a named user group — it makes revoking one person’s access a one-click action later instead of a tunnel-wide password rotation. Before touching the tunnel itself, create the user group and the local account it will contain.

Step 1.1: Create the VPN User Group

Open your FortiGate dashboard, expand User & Authentication in the left-hand menu, then select User Groups.

Click Create New.

Set Name to IPSec VPN Group.

Leave Type on its default: Firewall.

Click OK.

Step 1.2: Create the Local User Account

Inside User & Authentication, go to User Definition.

Click Create New to open the new user wizard.

Select Local User as the source, then click Next.

Enter a Username (e.g., test1) and a strong Password, then click Next.

Skip the optional contact-info screen by clicking Next.

On the last page, enable the User Group toggle.

Click +, pick the IPSec VPN Group you just created from the dropdown, then click Submit.

Phase 2: IPsec Tunnel Configuration

Because remote clients connect from unknown, changing public IPs, the tunnel has to be built as a Dialup User gateway rather than a fixed peer.

Step 2.1: Create a Custom IPsec Gateway

Go to VPN > IPsec Tunnels.

Click Create New > IPsec Tunnel.

Give it a clear Name (e.g., Remote Access).

Under Template type, select Custom — I always skip the templates here since they don’t give full control over the cryptographic settings.

Click Next to reach the advanced settings screen.

Step 2.2: Interface & IP Pool Settings

Fill in the top section of the advanced screen:

Remote Gateway: change it from Static IP Address to Dialup User.

Interface: your public-facing WAN interface (e.g., wan1).

Mode Config: turn this on — it’s what lets the FortiGate hand out a virtual IP and DNS server to each connecting client.

Assign IP From: Range.

IP Range: 192.168.41.1 to 192.168.41.254.

DNS Server: select custom and enter 8.8.8.8.

Enable IPv4 Split Tunnel: turn this on. With split tunneling, only traffic bound for your internal network goes through the VPN — everything else (Netflix, general browsing) stays on the client’s own internet connection instead of eating your office bandwidth.

Accessible Networks: click the lookup field and select your internal subnet (e.g., your lan object: 192.168.26.0/24).

Step 2.3: Phase 1 Proposal

Scroll to the Authentication and Phase 1 Proposal sections and set these exactly:

Method: Pre-shared Key Pre-shared Key: [your own secure key] IKE Version: 1 Mode: Aggressive (required for dial-up setups using XAUTH) Peer Options: Any peer ID Encryption / Auth: AES256 / SHA256 (delete the other default proposal rows so only this one is left) Diffie-Hellman Group: 14 (a 2048-bit group — uncheck group 5) Key Lifetime: 86400 seconds

Step 2.4: XAUTH

Find the XAUTH section in the advanced settings.

Change Type from Disabled to Auto Server.

Under User Group, click Choose.

Select the IPSec VPN Group from Phase 1. This ties the username/password check directly to the Phase 1 key exchange, so an unauthenticated client can’t even negotiate a tunnel.

Step 2.5: Phase 2 Proposal

Expand the Phase 2 Selectors section.

Delete the auto-populated proposal rows (x) until only one remains.

Set Encryption to AES256 and Authentication to SHA256.

Uncheck DH Group 5, leaving only Diffie-Hellman Group 14 selected.

Make sure Autokey Keep Alive is enabled.

Click OK at the bottom of the page to save the tunnel.

Phase 3: Firewall Policy (Allowing the Traffic)

Creating the tunnel doesn’t move any traffic by itself — FortiGate still needs an explicit policy allowing decrypted VPN traffic into the LAN, same as any other inter-zone traffic.

Go to Policy & Objects > Firewall Policy.

Click Create New.

Set the policy up like this:

⚠️ A note on NAT

Leave NAT disabled on this policy. Preserving the client’s real internal IP end-to-end keeps your logs meaningful and avoids session issues that NAT can introduce on VPN traffic.

Phase 4: FortiClient Setup (User Side)

With the FortiGate side done, the client app needs a matching profile.

Step 4.1: Create the IPsec Profile

Open FortiClient VPN on the client machine.

Click Configure VPN to add a new connection profile.

Select the IPsec VPN tab at the top of the window.

Fill in these fields:

Connection Name: a label you’ll recognize (e.g., Mumbai Office VPN).

Remote Gateway: your FortiGate’s public WAN IP (e.g., 122.161.198.190).

Authentication Method: Pre-shared Key — enter the same key you used in Phase 2.

Click Advanced Settings (+) to expand it.

Step 4.2: Match the Cryptographic Settings

VPN Settings: IKE Version 1, Mode Aggressive, and enable Mode Config.

Phase 1: Encryption AES256, Authentication SHA256, DH Group 14, Key Life 86400.

Phase 2: Encryption AES256, Authentication SHA256, Key Life 43200, DH Group 14.

Click Save.

Phase 5: Testing the Connection

Last step — confirm the tunnel actually comes up and traffic actually flows.

Step 5.1: Connect

In FortiClient, select the Mumbai Office VPN profile you just saved.

Enter your credentials:

Username: test1

Password: [your configured password]

Click Connect. FortiClient will negotiate the tunnel and minimize to the system tray once it’s up.

Step 5.2: Verify Connectivity

Open a Command Prompt on the client and ping the firewall’s internal gateway IP:

ping 192.168.26.1

If that replies, you’re routing through the tunnel correctly. If it times out, double-check the firewall policy from Phase 3 first — a missing or misconfigured policy is the most common reason a tunnel comes up but no traffic passes.

If you don’t have a device on the far side of the tunnel to ping from, our free Ping Test tool is a quick way to confirm basic reachability to a public host while you troubleshoot.

FortiGate CLI commands mapped to each phase

Phase 1: Identity & Authentication

Same as the GUI steps above — a dedicated user and group for authorization.

#Step 1.1: Create the local user account
config user local
 edit "test1"
 set type password
 set passwd "YourSecurePasswordHere!"
 next
end

# Step 1.2: Create the VPN user group and add the user
config user group
 edit "IPSec VPN Group"
 set member "test1"
 next
end

Phase 2: IPsec Tunnel (Phase 1 & Phase 2)

The tunnel uses a dynamic dial-up config plus Mode Config to hand out virtual IPs to clients.

# Steps 2.1-2.4: Phase 1 gateway

config vpn ipsec phase1-interface
edit "Remote Access"
set type dynamic
set interface "wan1"
set ike-version 1
set mode aggressive
set peertype any
set net-device disable
set proposal aes256-sha256
set dhgrp 14
set psksecret "YourPreSharedKeyMatch!"
set mode-cfg enable
set ipv4-start-ip 10.10.10.100 # Replace with your desired VPN IP pool start
set ipv4-end-ip 10.10.10.200 # Replace with your desired VPN IP pool end
set ipv4-netmask 255.255.255.0
set xauthtype auto
set authusrgrp "IPSec VPN Group"
next
end

# Step 2.5: Phase 2 proposal

config vpn ipsec phase2-interface
edit "Remote Access"
set phase1name "Remote Access"
set proposal aes256-sha256
set pfs disable
next
end

# Allow VPN traffic into the internal network
config firewall policy
edit 0
set name "VPN-to-Internal"
set srcintf "Remote Access"
set dstintf "internal" # Change to match your LAN interface name
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set nat enable # NAT is often required if internal routing lacks a return route to the VPN pool
next
end

FAQ

What is a FortiGate Dial-Up VPN?

A VPN designed for remote users connecting from dynamic, unknown public IP addresses — as opposed to a site-to-site tunnel, which expects a fixed peer.

What port does IPsec use?

UDP 500 and UDP 4500.

Why use Split Tunneling?

It keeps only corporate-bound traffic on the VPN, so a remote user’s general internet browsing doesn’t consume your office’s bandwidth.

Can FortiClient use IKEv2?

Yes — FortiOS 7.x fully supports IKEv2, and I’d reach for it over IKEv1 aggressive mode on a new deployment where you’re not constrained by older client compatibility.

Why AES256/SHA256 instead of DES/SHA1?

DES and SHA1 are both cryptographically broken by modern standards — DES has a small enough keyspace to brute-force, and SHA1 has known collision attacks. I use AES256/SHA256 as the default in this guide for that reason; only fall back to DES/SHA1 if you’re stuck supporting a genuinely legacy client that can’t negotiate anything stronger.

Conclusion

FortiGate IPsec Remote Access VPN gives remote employees a secure way to reach internal resources over the public internet.

Between user authentication, a dynamic dial-up tunnel, a firewall policy, and the FortiClient app, this setup scales from a handful of remote workers up to a full enterprise remote-access deployment — and with AES256/SHA256 and IKEv2 where your clients support it, it holds up to current security standards too.

Read More – FortiGate Web Filtering Deep Dive

Read More – Cisco IKEv1 Debug Commands and States Reference