Course menu

Module 5: Users and VPNsLesson 5.3 (3 of 5 in this module)21 of 33 in the FortiGate Administrator course

Site-to-site IPsec VPN

Connecting FGT1 to a branch FortiGate: phase 1 and phase 2, the route and blackhole, the two policies, and verifying the tunnel.

Intermediate · 13 min read

What you will learn

After this lesson, you can configure a route-based IPsec tunnel between two FortiGates, route and allow traffic through it, and verify phase 1, phase 2 and traffic counters.

  • Phase 1/2 config
  • Tunnel routes
  • VPN policies
  • Verification

A site-to-site VPN permanently joins two networks over the Internet. On FortiGates it is usually route-based: each side has a phase 1 (peer, authentication, IKE proposal) and a phase 2 (selectors and ESP proposal) that create a tunnel interface; a static route sends the remote subnet into that interface, and firewall policies allow traffic between the LAN and the tunnel in each direction.

In simple terms: The two offices' firewalls build a locked tunnel between them. Each one is told 'the other office's network is through the tunnel' and 'traffic may go both ways'.

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.

port1port1IPsec: to-BR1 ↔ to-HQFILE1HQ LAN · 10.0.1.5FGT1203.0.113.2InternetFGT2198.51.100.2BR-PCbranch LAN · 10.0.3.20
  1. 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 end

The 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 end

FGT2 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.

Simplified illustration of the FortiOS 7.4 GUI · not a screenshot
FGT1VPN › IPsec Tunnels

Edit VPN Tunnel: to-BR1

Network

Remote Gateway
Static IP Address
IP Address
198.51.100.2
Interface
port1

Authentication

Method
Pre-shared Key
Pre-shared Key
••••••••••••••••••••Identical on both FortiGates.
Version
1 2

Phase 2 Selectors

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.

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 end

Route 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 end

The 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

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): 1204/0  tx(pkt,err): 1187/0
One selector pair, up, with packets in both directions. (Example output.)
Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
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
Phase 1 (IKE SA) and phase 2 (IPsec SA) both established. If NAT were detected, the ports would show 4500. (Example output, trimmed.)

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

✅ 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

Predict · scenario 1

HQ users can open files on branch PCs, but branch users can't reach FILE1. The tunnel is up. What is missing on FGT1?

Predict · scenario 2

What is the blackhole route with distance 254 for?

Predict · scenario 3

FGT1's phase 2 has src 10.0.1.0/24 and dst 10.0.3.0/24. What must FGT2's be?

FAQ

Should I use the VPN wizard?
The IPsec wizard (VPN › IPsec Wizard) builds the phase 1, phase 2, routes, address objects and policies in one go, and is a fine way to start. Knowing what it creates matters when something breaks, which is why this lesson builds each piece by hand.
Do I need NAT on the VPN policies?
No. Both sides route each other's private subnets directly, so NAT stays off and each side sees the real addresses. NAT would also break the match with the phase 2 selectors.