A real-life situation
Staff work from home and need FILE1 (10.0.1.5) and internal web apps on 10.0.1.0/24. Their home addresses change all the time, so a site-to-site tunnel per user is impossible. One dial-up tunnel on FGT1 serves all of them, and the AD group Staff decides who may connect.
Phase 1: dial-up, IKEv2 with EAP
config firewall address
edit "RA-Pool"
set type iprange
set start-ip 10.10.10.1
set end-ip 10.10.10.100
next
end
config vpn ipsec phase1-interface
edit "RA-VPN"
set type dynamic
set interface "port1"
set ike-version 2
set peertype any
set net-device disable
set mode-cfg enable
set proposal aes256-sha256
set dhgrp 19 14
set eap enable
set eap-identity send-request
set authusrgrp "Staff"
set ipv4-start-ip 10.10.10.1
set ipv4-end-ip 10.10.10.100
set dns-mode manual
set ipv4-dns-server1 10.0.1.5
set ipv4-split-include "LAN-subnet"
set psksecret <group-pre-shared-key>
next
end
config vpn ipsec phase2-interface
edit "RA-VPN"
set phase1name "RA-VPN"
set proposal aes256-sha256
next
endtype dynamic accepts peers from any address. EAP asks each user for credentials, checked against the Staff group. Mode config gives clients an address from 10.10.10.1–100, the internal DNS server and a route for LAN-subnet only (split tunnel). Phase 2 selectors stay 0.0.0.0/0; each client gets its own SA.
The policy
config firewall policy
edit 12
set name "RA-VPN-to-LAN"
set srcintf "RA-VPN"
set dstintf "port2"
set srcaddr "RA-Pool"
set dstaddr "LAN-subnet"
set groups "Staff"
set action accept
set schedule "always"
set service "HTTPS" "SMB" "DNS"
set logtraffic all
next
endRemote users only reach what this policy allows, from the pool addresses, and only as members of Staff. No route is needed: FortiOS adds a route for each connected client's address into the tunnel automatically.
The client side
In FortiClient, the user creates an IPsec VPN connection that pairs with this phase 1:
| FortiClient setting | Value |
|---|---|
| VPN type | IPsec VPN |
| Remote gateway | vpn.example.com (203.0.113.2) |
| Authentication method | Pre-shared key (the group key) |
| IKE version | 2, matching the phase 1 |
| EAP | On; the user then signs in with their AD username and password |
Split or full tunnel?
| Split tunnel | Full tunnel | |
|---|---|---|
| Through the VPN | Company subnets only | Everything |
| Internet browsing | Direct from home | Through FGT1, inspected by its security profiles |
| Load on FGT1 | Low | Higher (needs an RA-VPN → port1 policy with NAT) |
Who is connected?
FGT1 # diagnose vpn ike gateway list vd: root/0 name: RA-VPN_0 version: 2 interface: port1 5 addr: 203.0.113.2:4500 -> 192.0.2.77:64916 ... assigned IPv4 address: 10.10.10.1/255.255.255.255 ... IKE SA: created 1/1 established 1/1 time 140/140/140 ms IPsec SA: created 1/1 established 1/1 time 0/0/0 ms
Why it works this way
A dial-up tunnel can't know its peers in advance, so user authentication and mode config take the place of fixed remote gateways and selectors. The pre-shared key only proves the client is configured for this VPN; the username, password and group decide who it is and what it may reach.
Common mistakes
- Relying on the group pre-shared key as the only secret: it is shared by everyone and easily leaked.
- Forgetting the internal DNS server, so users can reach servers by IP but not by name.
- An address pool that overlaps a home network (192.168.1.0/24) or the LAN.
- Allowing service ALL to the whole LAN for every remote user.
Key takeaways
- Remote access uses a dial-up (type dynamic) IPsec phase 1 with EAP (IKEv2) or XAuth (IKEv1).
- Mode config hands out address, DNS and split-tunnel routes.
- A policy from the tunnel interface, with the user group, decides what remote users reach.
- New designs should use IPsec; SSL VPN is being retired in recent FortiOS releases.
Check yourself
Which phase 1 setting lets users connect from addresses that aren't known in advance?
Remote users reach 10.0.1.5 by IP but not fileserver.example.local by name. What is missing?
With split tunnelling, where does a remote user's web browsing go?