NSE4 Part 8: IPsec VPN

NSE4 Part 8: IPsec VPN

Part 8 of the NSE4 series. This post covers Lesson 14 of the official curriculum — IPsec VPN. The exam tests both the protocol mechanics and the FortiGate-specific configuration knobs.

IKEv1 vs IKEv2

Two versions of the Internet Key Exchange protocol negotiate the SAs:

Feature	IKEv1	IKEv2
Phase 1 messages	6 (main mode) or 3 (aggressive)	4 (IKE_SA_INIT + IKE_AUTH)
Built-in NAT-T	Optional	Mandatory
EAP authentication	Via XAUTH extension	Native
Multiple traffic selectors per SA	No	Yes
Asymmetric auth (PSK + cert)	No	Yes

If the exam shows a packet capture, you can tell the version from the IKE header — IKEv1 uses exchange types 2 (main) or 4 (aggressive); IKEv2 uses 34 (IKE_SA_INIT) and 35 (IKE_AUTH).

Use IKEv2 unless the peer doesn’t support it. It’s faster, more flexible, and inherently NAT-aware.

Phase 1 and Phase 2

Two SAs are negotiated:

• Phase 1 (IKE_SA) — establishes a secure control channel between the two IKE peers. Authenticates the peers (PSK or certificate). Encrypts subsequent IKE messages.
• Phase 2 (Child SA / IPsec SA) — actually carries user data. There can be multiple Phase 2 SAs under one Phase 1, each with its own selector pair.

Failure during Phase 1 is almost always: mismatched proposals, wrong PSK, or NAT-T disagreement. Failure during Phase 2 is almost always: mismatched local/remote selectors or PFS group.

Route-based vs policy-based VPN

Two ways to express the VPN on a FortiGate:

Route-based (default, recommended). Phase 2 selectors are typically 0.0.0.0/0 ↔ 0.0.0.0/0 and the tunnel appears as a virtual interface. Routes (static or dynamic) decide what enters the tunnel. Firewall policies treat the tunnel interface like any other interface.

config vpn ipsec phase1-interface
    edit "to-branch"
        set interface "wan1"
        set ike-version 2
        set remote-gw 198.51.100.10
        set psksecret ********
        set peertype any
        set proposal aes256-sha256
        set dpd on-idle
    next
end

config vpn ipsec phase2-interface
    edit "to-branch-p2"
        set phase1name "to-branch"
        set proposal aes256-sha256
        set src-subnet 0.0.0.0/0
        set dst-subnet 0.0.0.0/0
    next
end

config router static
    edit 1
        set device "to-branch"
        set dst 10.20.0.0/16
    next
end

config firewall policy
    edit 50
        set srcintf "internal"
        set dstintf "to-branch"
        set srcaddr "local-net"
        set dstaddr "branch-net"
        set service "ALL"
        set action accept
    next
end

Policy-based (legacy). The IPsec config defines explicit local/remote subnets and a firewall policy with set action ipsec triggers the tunnel for matching traffic. Configurable but harder to scale; route-based is what the exam expects unless it explicitly asks otherwise.

Site-to-site vs dial-up

• Site-to-site — both peers have static IPs. Simplest setup; either side can initiate.
• Dial-up — one peer has a dynamic IP. The dynamic side initiates; the static side accepts using set type dynamic (FortiGate calls this dialup VPN). Multiple remote peers can share one dial-up phase 1 by using XAUTH (IKEv1) or EAP (IKEv2) for per-user identification.

Authentication

Two practical options:

• Pre-shared key — single string, configured on both peers. Easy, fragile if leaked.
• Certificates — PKCS#12 or X.509. Each peer presents a cert signed by a trusted CA. Scales better and supports per-peer identity.

config vpn ipsec phase1-interface
    edit "to-branch"
        set authmethod signature      ; cert-based
        set certificate "fortigate-cert"
        set peer "branch-cert-id"
    next
end

NAT traversal and DPD

Two subtle behaviours that come up in exam scenarios:

NAT-Traversal (NAT-T). When IKE/ESP traffic crosses a NAT, the peers detect the NAT in IKE and switch ESP to UDP/4500 to make NAT-friendly. Mandatory in IKEv2; controlled by set nattraversal enable|disable|forced in IKEv1.

Dead Peer Detection (DPD). Periodic IKE keepalives. Three modes:

• on-demand — send DPD only when there’s outbound traffic and no recent inbound.
• on-idle — send DPD when the tunnel goes idle to detect stale peers.
• disable — never send DPD (relies on rekey timers to notice failure).

DPD interval and retries tune how quickly a tunnel is declared dead — too aggressive and you’ll false-positive across flaky links; too lax and failover is slow.

Diagnostics

The two commands you reach for first:

diagnose vpn ike gateway list
diagnose vpn tunnel list

The first shows Phase 1 status (Up/Down, peer IP, IKE version, last error). The second shows Phase 2 SAs with byte counters. If gateway list is missing, Phase 1 never came up. If gateway list is up but tunnel list is empty or counters don’t increment, Phase 2 is broken.

For full negotiation trace:

diagnose debug application ike -1
diagnose debug enable

Common error patterns and fixes:

• No matching gateway for peer ip x.x.x.x → remote-gw mismatch, or peer behind NAT and nattraversal not set.
• Phase1 negotiation failed: probable pre-shared key mismatch → speaks for itself.
• Phase 2 selectors do not match → src-subnet / dst-subnet differ between peers. Both sides must agree on selectors exactly (route-based default 0.0.0.0/0 ↔ 0.0.0.0/0 avoids this entirely).
• Tunnel comes up, traffic asymmetric → routing or RPF on one side; check the static route points at the tunnel interface.

get vpn ipsec tunnel summary
get vpn ipsec tunnel name <p2-name>

are quieter, friendlier views of the same data, fine for routine status checks.

Part 9 covers routing — static, policy, OSPF and BGP basics — together with SD-WAN, which builds on top of routing.