A real-life situation
The branch behind FGT2 (LAN 10.0.3.0/24) needs FILE1 at headquarters (10.0.1.5), and HQ admins need to reach branch PCs. Both FortiGates already reach the Internet. Everything below is done on both sides, as mirror images; the commands show FGT1, with FGT2's differences noted.
- 1. Branch to HQ: FGT2 routes 10.0.1.0/24 into to-HQ; FGT1 decrypts and sends it to FILE1.
Step 1: phase 1
config vpn ipsec phase1-interface
edit "to-BR1"
set interface "port1"
set ike-version 2
set peertype any
set net-device disable
set proposal aes256-sha256 aes256gcm-prfsha384
set dhgrp 19 14
set remote-gw 198.51.100.2
set psksecret <a-long-random-key>
set dpd on-idle
next
endThe name to-BR1 becomes the tunnel interface. On FGT2 the entry is to-HQ with remote-gw 203.0.113.2 and the same key, proposals and DH groups. A long random pre-shared key matters: it is the only secret protecting the tunnel.
Step 2: phase 2
config vpn ipsec phase2-interface
edit "to-BR1"
set phase1name "to-BR1"
set proposal aes256-sha256 aes256gcm
set pfs enable
set dhgrp 19 14
set src-subnet 10.0.1.0 255.255.255.0
set dst-subnet 10.0.3.0 255.255.255.0
next
endFGT2 has the selectors the other way round: src 10.0.3.0/24, dst 10.0.1.0/24. Selectors of 0.0.0.0/0 on both sides also work and are common, because the route and policies already decide what enters the tunnel.
Edit VPN Tunnel: to-BR1
- Remote Gateway
- Static IP Address
- IP Address
- 198.51.100.2
- Interface
- port1
- Method
- Pre-shared Key
- Pre-shared Key
- ••••••••••••••••••••Identical on both FortiGates.
- Version
- 1 2
- Local Address
- 10.0.1.0/255.255.255.0
- Remote Address
- 10.0.3.0/255.255.255.0Mirror image of FGT2's selectors.
Network
Authentication
Phase 2 Selectors
Step 3: route and blackhole
config router static
edit 20
set dst 10.0.3.0 255.255.255.0
set device "to-BR1"
next
edit 21
set dst 10.0.3.0 255.255.255.0
set blackhole enable
set distance 254
next
endRoute 20 sends the branch subnet into the tunnel (no gateway needed on a tunnel interface). Route 21 only takes over if the tunnel is down, so branch traffic is dropped instead of leaking to the Internet by the default route.
Step 4: policies in both directions
config firewall address
edit "BR1-LAN"
set subnet 10.0.3.0 255.255.255.0
next
end
config firewall policy
edit 10
set name "HQ-to-BR1"
set srcintf "port2"
set dstintf "to-BR1"
set srcaddr "LAN-subnet"
set dstaddr "BR1-LAN"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 11
set name "BR1-to-HQ"
set srcintf "to-BR1"
set dstintf "port2"
set srcaddr "BR1-LAN"
set dstaddr "LAN-subnet"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
endThe tunnel is an interface, so it needs a policy each way: one for sessions HQ starts, one for sessions the branch starts. NAT stays off. Narrow the services once the tunnel works. Move both policies above any catch-all deny.
Step 5: verify
FGT1 # get vpn ipsec tunnel summary 'to-BR1' 198.51.100.2:0 selectors(total,up): 1/1 rx(pkt,err): 1204/0 tx(pkt,err): 1187/0
FGT1 # diagnose vpn ike gateway list name to-BR1 vd: root/0 name: to-BR1 version: 2 interface: port1 5 addr: 203.0.113.2:500 -> 198.51.100.2:500 ... IKE SA: created 1/1 established 1/1 time 20/20/20 ms IPsec SA: created 1/1 established 1/1 time 10/10/10 ms
In the GUI: Dashboard › Network › IPsec widget, or VPN › IPsec Tunnels, where a tunnel can be brought up or down with a right-click.
Why it works this way
Treating the tunnel as an interface means the FortiGate handles VPN traffic with the same three steps as any traffic: a route chooses the tunnel, a policy allows it, and the session table tracks it. The IPsec-specific part is only phase 1 and phase 2, which build the interface.
Common mistakes
- Only one policy: the tunnel works for sessions started at one site but not the other.
- No route on one side, so replies follow the default route to the Internet.
- NAT enabled on a VPN policy.
- Forgetting that FGT2 needs everything too, mirrored.
Key takeaways
- Route-based VPN: phase1-interface + phase2-interface create a tunnel interface.
- A static route sends the remote subnet into the tunnel; a distance-254 blackhole stops leaks when it is down.
- Two policies, one per direction, without NAT.
- Verify with get vpn ipsec tunnel summary and diagnose vpn ike gateway list.
Check yourself
HQ users can open files on branch PCs, but branch users can't reach FILE1. The tunnel is up. What is missing on FGT1?
What is the blackhole route with distance 254 for?
FGT1's phase 2 has src 10.0.1.0/24 and dst 10.0.3.0/24. What must FGT2's be?