Lab: FortiGate HQ-to-Branch IPsec VPN | FortiGate Course

The situation

FGT1 (HQ, 203.0.113.2, LAN 10.0.1.0/24) and FGT2 (branch, 198.51.100.2, LAN 10.0.3.0/24) both reach the Internet. Build a route-based IKEv2 tunnel: to-BR1 on FGT1, to-HQ on FGT2. Both sites may start sessions to each other.

1. Goal: BR-PC reaches FILE1 through the tunnel, and HQ reaches the branch.

Task 1: FGT1

Show the configuration

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
        set dhgrp 19
        set remote-gw 198.51.100.2
        set psksecret <lab-key>
    next
end
config vpn ipsec phase2-interface
    edit "to-BR1"
        set phase1name "to-BR1"
        set proposal aes256-sha256
        set dhgrp 19
        set src-subnet 10.0.1.0 255.255.255.0
        set dst-subnet 10.0.3.0 255.255.255.0
    next
end
config firewall address
    edit "BR1-LAN"
        set subnet 10.0.3.0 255.255.255.0
    next
end
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
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"
    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"
    next
end

Move policies 10 and 11 above the deny-all policy from the earlier labs.

Task 2: FGT2

Show what changes

Everything mirrors FGT1:

Phase 1 to-HQ, remote-gw 203.0.113.2, the same key, proposal and DH group.
Phase 2 selectors src 10.0.3.0/24, dst 10.0.1.0/24.
Address HQ-LAN 10.0.1.0/24; route 10.0.1.0/24 via to-HQ plus a distance-254 blackhole.
Policies port2 → to-HQ and to-HQ → port2.

Task 3: verify

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version

FGT1 # get vpn ipsec tunnel summary
'to-BR1' 198.51.100.2:0  selectors(total,up): 1/1  rx(pkt,err): 52/0  tx(pkt,err): 49/0

Then from BR-PC open a share on FILE1, and from an HQ PC ping BR-PC. Both rx and tx counters should rise.

Find the fault

For faults 1 to 3, run IKE debug on FGT1 while the tunnel tries to come up:

diagnose debug reset
diagnose vpn ike log filter rem-addr4 198.51.100.2
diagnose debug application ike -1
diagnose debug enable

The filter limits output to this peer. Stop with diagnose debug disable.

Fault 1

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version

FGT1 # (IKE debug, trimmed)
ike 0:to-BR1:3: sent IKE msg (SA_INIT): 203.0.113.2:500->198.51.100.2:500 ...
ike 0:to-BR1:3: received notify type NO_PROPOSAL_CHOSEN
ike 0:to-BR1:3: negotiation failure

Show diagnosis

FGT2 rejected every phase 1 proposal FGT1 offered. show vpn ipsec phase1-interface to-HQ on FGT2 shows set proposal aes128-sha1 and set dhgrp 14. Fix: make the proposals and DH groups match (aes256-sha256, group 19) on both sides.

Fault 2

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version

FGT1 # (IKE debug, trimmed)
ike 0:to-BR1:4: sent IKE msg (SA_INIT) ...
ike 0:to-BR1:4: received IKE msg (SA_INIT) ...
ike 0:to-BR1:4: sent IKE msg (AUTH) ...
ike 0:to-BR1:4: received notify type AUTHENTICATION_FAILED

Show diagnosis

SA_INIT succeeded, so proposals match, but FGT2 couldn't verify FGT1's proof: the pre-shared keys differ. Fix: set the same psksecret on both phase 1 entries (paste it; typos are common).

Fault 3

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version

FGT1 # (IKE debug, trimmed)
ike 0:to-BR1:5: sent IKE msg (AUTH) ...
ike 0:to-BR1:5: received IKE msg (AUTH) ...
ike 0:to-BR1:5: IKE SA established
ike 0:to-BR1:5: received notify type TS_UNACCEPTABLE

Show diagnosis

Phase 1 is up, but FGT2 refused the traffic selectors, so no IPsec SA exists (selectors 0/1 in the summary). FGT2's phase 2 has src-subnet 10.0.30.0/24, a typo for 10.0.3.0/24. Fix: correct FGT2's selectors so they mirror FGT1's.

Fault 4

The tunnel is up (selectors 1/1), but nothing passes in either direction. Debug flow on FGT1 for traffic from 10.0.3.20 shows:

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version

FGT1 # (debug flow, trimmed)
msg="vd-root:0 received a packet(proto=6, 10.0.3.20:50211->10.0.1.5:445) from to-BR1. flag [S], ..."
msg="reverse path check fail, drop"

Show diagnosis

The packet arrives on to-BR1, but FGT1 has no route back to 10.0.3.0/24 through to-BR1, so the reverse path check drops it. The same missing route explains the other direction: HQ traffic for 10.0.3.0/24 follows the default route to the Internet instead of the tunnel. get router info routing-table all shows route 20 missing. Fix: add the static route to 10.0.3.0/24 via to-BR1.

diagnose debug disable

Always stop debug output when finished.

Check yourself

Predict · scenario 1

IKE debug shows SA_INIT exchanged successfully, then AUTHENTICATION_FAILED. What is the likely cause?

Predict · scenario 2

The summary shows selectors(total,up): 1/0 and debug shows TS_UNACCEPTABLE. Which part of the configuration should you compare?

Predict · scenario 3

Which tunnel counter pattern suggests FGT1 receives traffic from the branch but sends nothing back?

Lab: HQ to branch IPsec

What you will learn

The situation

Task 1: FGT1

Task 2: FGT2

Task 3: verify

Find the fault

Fault 1

Fault 2

Fault 3

Fault 4

Check yourself