Fortinet · FortiOS 7.4 · Lesson 7 of 12

Site-to-site: Phase-1 is the door, Phase-2 is the room

Branch LAN 10.30.0.0/24 must reach HQ 10.20.30.0/24. You need IKE (Phase-1) to the peer 198.51.100.10, IPsec SA (Phase-2) for those subnets, a tunnel interface, a route, and policies. Green Phase-1 with red Phase-2 is the most common “VPN is up” lie.

Updated 2026-08-18·20 min read·L2 primary·Quiz at end

After this page you can

Build a route-based IPsec (recommended) with matching proposals.
Set Phase-2 selectors (proxy IDs) to the real subnets.
Add tunnel route + policies both ways.
Read vpn tunnel list / ike debug when it fails.

The ticket

GUI: “VPN up.” Branch ping dies. Phase-1 is up. Phase-2 selectors are 0.0.0.0/0 vs 10.20.30.0/24. One side will not build the SA.

Quick interview answer

Phase-1 (IKE) authenticates the gateways (PSK or cert, DH, proposals). Phase-2 (IPsec) protects traffic between selectors (proxy IDs). Route-based VPN uses a tunnel interface + route; policy-based binds interesting traffic in the policy. FortiOS 7.4 IPsec wizard defaults to route-based. Selectors must match or be compatible — 0.0.0.0/0 vs a subnet is a classic mismatch, especially vs Azure/AWS.

HQ FortiGate IPsec to branch peer — Up on IKE is not up for the LAN.

Lab data · dummy only

FortiGate fgt-hq mgmt 10.10.10.1 · WAN 203.0.113.10 · LAN 10.20.30.0/24 · FortiManager 10.10.10.5 · FortiAnalyzer 10.10.10.6 · Priya 10.20.30.80 · branch peer WAN 198.51.100.10 · Azure VPN GW public 203.0.113.50 · AWS VGW public 203.0.113.60. RFC 5737. Not a customer.

Mental model

Layer	Must match	This lab
Phase-1	IKE version, PSK/cert, DH, enc/auth, lifetime style	IKEv2, PSK, 203.0.113.10 ↔ 198.51.100.10
Phase-2	Selectors, PFS, enc/auth	10.20.30.0/24 ↔ 10.30.0.0/24
Routing + policy	Tunnel if + static/BGP + ACCEPT both ways	vpn-branch, 10.30.0.0/24 via tunnel

https://fgt-hq.techclick-lab.in

Training mock · not live

Admin

DashboardPolicyVPNNetwork

VPN → IPsec Tunnels

vpn-branch

Remote Gateway

198.51.100.10

IKE

Version 2 / Pre-shared key

Phase-2 selectors

local 10.20.30.0/24 remote 10.30.0.0/24

Interface

vpn-branch (tunnel)

Bring up

Automatically / on traffic

FortiOS 7.4 IPsec Tunnels. Training mock.

How to choose

New build: route-based + IKEv2. Policy-based only if the peer is ancient. Cloud peers: read the cloud selector rules (Azure often 0.0.0.0/0 on policy-based, or use route-based VNet GW — later VPN lessons).

Runbook

Side A — proposals
Same IKEv2, AES256-SHA256, DH14/19, PSK. No mixed v1/v2.
Side B — selectors + route
Exact subnets both sides. Static: dest 10.30.0.0/24 device vpn-branch. Policies LAN→vpn-branch and reverse.
Side C — prove
diagnose vpn ike gateway list, diagnose vpn tunnel list, ping from 10.20.30.80 to 10.30.0.10.

VPN proof

diagnose vpn ike gateway list
# name: vpn-branch  created: …  IKE SA: established

diagnose vpn tunnel list name vpn-branch
# dest: 198.51.100.10  status: up  selectors: 10.20.30.0/24-10.30.0.0/24

execute ping-options source 10.20.30.1
execute ping 10.30.0.10

Four failures

1 · Phase-1 never up

PSK, IKE version, WAN NAT-T, peer IP wrong, UDP 500/4500 blocked.

2 · Phase-1 up, Phase-2 down

Selectors / PFS / proposal. This ticket.

3 · Both SAs up, ping dies

Missing route or policy, or interesting traffic not hitting the tunnel (SNAT by mistake).

4 · One-way

Return policy or return selector missing. Asymmetric firewall.

How to prove it

Close only when

1) IKE SA up. 2) Phase-2 selectors match the ping. 3) Bidirectional ping with source IP on the LAN. 4) You did not SNAT into the tunnel unless designed.

Traps

GUI says	You still check
Up	Which SA — IKE or IPsec — and selectors
Down	ike debug filtered, not a new wizard

FortiGate class series: FGT / FMG / FAZ · First day · Policy first match · SNAT vs VIP · Profiles + SSL · debug flow · IPsec S2S · SSL-VPN vs RA · SD-WAN SLA · VDOM · FGCP HA · Interview

Sources

FortiOS 7.4 — IPsec VPN (route-based / policy-based, Phase-1/2).