FortiGate Site-to-Site IPsec VPN Configuration with a Branch Office Example

Connecting geographically separated office networks securely is a core requirement for enterprise organizations. A FortiGate site to site IPsec VPN creates an encrypted route-based tunnel across untrusted public networks such as the internet. This setup allows private subnets at different locations to communicate as if they were on the same local network.

This technical guide explains how to design, build, verify, and troubleshoot a route-based site-to-site IPsec VPN tunnel between two FortiGate firewalls using FortiOS. You will learn the mechanics of Phase 1 and Phase 2 negotiations, routing behavior, firewall policy enforcement, and practical CLI troubleshooting techniques.

Related NetworkFix resources: Explore the FortiGate security guides for more FortiGate-focused content, or browse the Tutorials & Guides section for additional hands-on configuration walkthroughs.

Real-Life Scenario

An enterprise organization operates a Head Office (HQ) in Chicago and a Branch Office in Austin. Both sites connect to local internet service providers (ISPs) using static public IP addresses.

The organization requires seamless, secure communications between internal devices at both sites. Users in the Branch Office must access corporate database servers located at Head Office. HQ staff require direct management access to local branch servers. The traffic between both local area networks (LANs) must be encrypted without modifying internal host IP addressing.

Lab Topology

The following diagram illustrates the route-based VPN tunnel topology connecting the HQ FortiGate and the Branch FortiGate across the internet.

 HQ Network                                 Internet                                Branch Network
[10.10.10.0/24]                                                                    [10.20.20.0/24]
       |                                                                                  |
 (port2: 10.10.10.1)                                                               (port2: 10.20.20.1)
+--------------+                                                                  +--------------+
| HQ-FortiGate |                                                                  | BR-FortiGate |
+--------------+                                                                  +--------------+
 (port1: 198.51.100.2)                                                            (port1: 203.0.113.2)
       |                                                                                  |
       +--- [Gateway: 198.51.100.1] --- (IPsec VPN Tunnel) --- [Gateway: 203.0.113.1] ---+

Example Addressing and Objects

The table below outlines the network subnets, interface assignments, public IPs, and object naming conventions used throughout this configuration guide. All values are labeled for lab/example purposes.

Prerequisites

Before configuring a FortiGate site to site IPsec VPN, ensure the following prerequisites are met:

• Static Public IP Addresses: Assign accessible static public IP addresses to both FortiGate WAN interfaces, or use dynamic DNS (DDNS) if dynamic WAN IPs are used.
• Non-Overlapping Subnets: Verify that the local and remote internal network subnets do not overlap. If subnets overlap, destination NAT or virtual IP mapping is required.
• Administrative Access: Ensure administrative access to both FortiGate devices via HTTPS or SSH.
• Cryptographic Agreement: Align proposal settings prior to setup, including IKE version, encryption protocols, authentication algorithms, Diffie-Hellman (DH) groups, and Pre-Shared Keys (PSK).

Step-by-Step GUI Configuration

This section walks through configuring the IPsec VPN tunnel using the FortiOS Graphical User Interface (GUI). Navigation paths may vary slightly depending on your FortiOS release and administrator profile settings.

Step 1: Configure Phase 1 and Phase 2 Tunnel Settings (HQ-FortiGate)

1. Log in to the HQ-FortiGate GUI.
2. Navigate to VPN > IPsec Tunnels and click Create New > IPsec Tunnel.
3. Enter a tunnel Name (for example, HQ-to-Branch). Select Custom build type and click Next.
4. Under Network settings:
   • Set IP Version to IPv4.
   • Set Remote Gateway to Static IP Address.
   • Enter the remote public IP address in the Remote IP field: 203.0.113.2.
   • Set Interface to your internet-facing interface (for example, port1).
5. Under Authentication:
   • Set Method to Pre-shared Key.
   • Enter the strong shared secret in the Pre-shared Key field.
   • Set IKE Version to 2.
6. Under Phase 1 Proposal:
   • Set Encryption to AES256 and Authentication to SHA256.
   • Set DH Group to 14 (or higher, such as 19 or 20).
   • Set Key Lifetime to 86400 seconds.
7. Expand Phase 2 Selectors:
   • Set Local Address to Subnet and enter 10.10.10.0/255.255.255.0.
   • Set Remote Address to Subnet and enter 10.20.20.0/255.255.255.0.
   • Under Advanced, set Encryption to AES256 and Authentication to SHA256.
   • Enable Auto-negotiate and Autokey Keep Alive if continuous tunnel initiation is required.
8. Click OK to save the tunnel configuration.

Step 2: Create Address Objects and Static Routes (HQ-FortiGate)

1. Navigate to Policy & Objects > Addresses and create address objects for ADDR_HQ_LAN (10.10.10.0/24) and ADDR_BR_LAN (10.20.20.0/24).
2. Navigate to Network > Static Routes and click Create New.
3. Set Destination to Subnet and enter 10.20.20.0/255.255.255.0.
4. Set Interface to the newly created VPN interface: HQ-to-Branch.
5. Click OK.

Step 3: Create Firewall Policies (HQ-FortiGate)

FortiOS requires active firewall policies to authorize traffic entering or exiting virtual IPsec interfaces.

1. Navigate to Policy & Objects > Firewall Policy and click Create New.
2. Configure the Outbound Policy (LAN to VPN):
   • Name: HQ-to-Branch-Outbound
   • Incoming Interface: port2 (LAN)
   • Outgoing Interface: HQ-to-Branch (VPN interface)
   • Source: ADDR_HQ_LAN
   • Destination: ADDR_BR_LAN
   • Service: ALL
   • Action: ACCEPT
   • NAT: Disabled (Ensure Source NAT is turned off).
3. Click OK.
4. Create the Inbound Policy (VPN to LAN):
   • Name: Branch-to-HQ-Inbound
   • Incoming Interface: HQ-to-Branch (VPN interface)
   • Outgoing Interface: port2 (LAN)
   • Source: ADDR_BR_LAN
   • Destination: ADDR_HQ_LAN
   • Service: ALL
   • Action: ACCEPT
   • NAT: Disabled.
5. Click OK.

Repeat these step-by-step procedures on the Branch FortiGate, reversing local and remote subnet definitions, IP addresses, and policy directional flows.

CLI Configuration

Command Line Interface (CLI) configuration offers a fast, precise, and standardized implementation path. Below are the complete FortiOS CLI commands for both Head Office and Branch Office firewalls.

Head Office (HQ-FortiGate) CLI Configuration

# Step 1: Create Firewall Address Objects
config firewall address
    edit "ADDR_HQ_LAN"
        set subnet 10.10.10.0 255.255.255.0
    next
    edit "ADDR_BR_LAN"
        set subnet 10.20.20.0 255.255.255.0
    next
end

# Step 2: Configure Phase 1 Interface
config vpn ipsec phase1-interface
    edit "HQ-to-Branch"
        set interface "port1"
        set ike-version 2
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set dhgrp 14
        set remote-gw 203.0.113.2
        set psksecret EXAMPLE_SECRET_KEY_123
        set dpd on-idle
    next
end

# Step 3: Configure Phase 2 Interface
config vpn ipsec phase2-interface
    edit "HQ-to-Branch-P2"
        set phase1name "HQ-to-Branch"
        set proposal aes256-sha256
        set dhgrp 14
        set auto-negotiate enable
        set src-subnet 10.10.10.0 255.255.255.0
        set dst-subnet 10.20.20.0 255.255.255.0
    next
end

# Step 4: Configure Static Route
config router static
    edit 0
        set dst 10.20.20.0 255.255.255.0
        set device "HQ-to-Branch"
    next
end

# Step 5: Configure Firewall Policies
config firewall policy
    edit 0
        set name "HQ-Outbound-To-Branch"
        set srcintf "port2"
        set dstintf "HQ-to-Branch"
        set srcaddr "ADDR_HQ_LAN"
        set dstaddr "ADDR_BR_LAN"
        set action accept
        set schedule "always"
        set service "ALL"
    next
    edit 0
        set name "HQ-Inbound-From-Branch"
        set srcintf "HQ-to-Branch"
        set dstintf "port2"
        set srcaddr "ADDR_BR_LAN"
        set dstaddr "ADDR_HQ_LAN"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

Branch Office (BR-FortiGate) CLI Configuration

# Step 1: Create Firewall Address Objects
config firewall address
    edit "ADDR_BR_LAN"
        set subnet 10.20.20.0 255.255.255.0
    next
    edit "ADDR_HQ_LAN"
        set subnet 10.10.10.0 255.255.255.0
    next
end

# Step 2: Configure Phase 1 Interface
config vpn ipsec phase1-interface
    edit "Branch-to-HQ"
        set interface "port1"
        set ike-version 2
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set dhgrp 14
        set remote-gw 198.51.100.2
        set psksecret EXAMPLE_SECRET_KEY_123
        set dpd on-idle
    next
end

# Step 3: Configure Phase 2 Interface
config vpn ipsec phase2-interface
    edit "Branch-to-HQ-P2"
        set phase1name "Branch-to-HQ"
        set proposal aes256-sha256
        set dhgrp 14
        set auto-negotiate enable
        set src-subnet 10.20.20.0 255.255.255.0
        set dst-subnet 10.10.10.0 255.255.255.0
    next
end

# Step 4: Configure Static Route
config router static
    edit 0
        set dst 10.10.10.0 255.255.255.0
        set device "Branch-to-HQ"
    next
end

# Step 5: Configure Firewall Policies
config firewall policy
    edit 0
        set name "BR-Outbound-To-HQ"
        set srcintf "port2"
        set dstintf "Branch-to-HQ"
        set srcaddr "ADDR_BR_LAN"
        set dstaddr "ADDR_HQ_LAN"
        set action accept
        set schedule "always"
        set service "ALL"
    next
    edit 0
        set name "BR-Inbound-From-HQ"
        set srcintf "Branch-to-HQ"
        set dstintf "port2"
        set srcaddr "ADDR_HQ_LAN"
        set dstaddr "ADDR_BR_LAN"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

How the Traffic Flows

Understanding internal packet processing inside FortiOS helps engineers design robust networks and isolate issues quickly. The following sequence details how an unencrypted IP packet travels from a source host at Head Office to a server at Branch Office.

1. Ingress & Routing Lookup: A computer on HQ LAN (10.10.10.50) sends an IP packet to a branch server (10.20.20.100). The packet arrives at HQ FortiGate interface port2. The FortiGate inspects its routing table. It finds a static route for 10.20.20.0/24 pointing out virtual interface HQ-to-Branch.
2. Firewall Policy Matching: FortiOS evaluates active firewall policies. It checks for a match with incoming interface port2, egress interface HQ-to-Branch, source address 10.10.10.50, and destination address 10.20.20.100. The firewall permits the traffic because it matches policy ID 1 (outbound policy).
3. IPsec SA Match & Encapsulation: The packet enters the virtual tunnel interface. FortiOS matches the destination subnet against Phase 2 Security Association (SA) traffic selectors. The engine encapsulates the original IP packet inside an Encapsulating Security Payload (ESP) header (IP protocol 50) and encrypts the payload using AES-256.
4. Egress Delivery: The original packet payload is encrypted. FortiOS prefixes a new outer IP header with source 198.51.100.2 and destination 203.0.113.2. The packet leaves the physical port1 interface towards the public gateway.
5. Remote Decapsulation & Policy Evaluation: The Branch FortiGate receives the ESP packet on port1. It looks up the SPI (Security Parameter Index), decrypts the outer payload using the agreed SA keys, and extracts the inner packet (10.10.10.50 -> 10.20.20.100).
6. Egress to Destination: The Branch FortiGate evaluates its inbound firewall policy from ingress interface Branch-to-HQ to egress interface port2. Upon matching the permit policy, the packet exits interface port2 and reaches host 10.20.20.100.

Verification

Confirm IPsec tunnel operation, state negotiation, routing table integration, and end-to-end dataplane connectivity using the following verification steps.

1. Check Phase 1 Status

Execute the following command to verify whether Phase 1 IKE negotiation is established:

diagnose vpn ike gateway list name HQ-to-Branch

Look for status output showing established, along with valid local/remote network addresses and assigned SPI entries.

2. Check Phase 2 Status

Verify active Security Associations and packet byte counts using:

diagnose vpn tunnel list name HQ-to-Branch-P2

The output must display established SAs with incrementing packet counters for both outbound (sa_out) and inbound (sa_in) security associations.

3. Verify Active Route Table

Confirm the static route targeting the remote subnet is active in the routing table:

get router info routing-table all

Ensure an entry exists for 10.20.20.0/24 pointing directly to interface HQ-to-Branch.

4. Dataplane Connectivity Test

Initiate a source-based ICMP echo request from the FortiGate CLI using the internal interface IP address as the source:

execute ping-options source 10.10.10.1
execute ping 10.20.20.1

A successful ping response proves routing, tunnel encapsulation, decryption, and firewall policies are operating correctly end-to-end.

Troubleshooting

When an IPsec tunnel fails to connect or pass traffic, follow a structured workflow to isolate the root cause.

Troubleshooting Workflow

1. Physical/Link Layer: Verify WAN interfaces have valid IP addresses and reachability to the remote public gateway.
2. Phase 1 IKE Diagnostics: Validate credentials, cryptographic proposals, and port 500/4500 reachability.
3. Phase 2 SA Diagnostics: Check traffic selector consistency (subnets) and perfect forward secrecy (PFS) settings.
4. Routing & Policy Checks: Verify return routes exist on both ends and firewall policies match traffic flows.
5. Dataplane Verification: Run debug flow engine traces to inspect packet handling steps.

Troubleshooting Matrix

Real-Time Debug Commands

Execute real-time IKE tracing to diagnose negotiation failures:

diagnose debug reset
diagnose debug application ike -1
diagnose debug enable

Observe the live terminal output to identify mismatch errors (such as PSK mismatch or no proposal chosen).

Execute packet tracing with the FortiGate packet diagnostic engine to observe routing and policy evaluation for specific traffic:

diagnose debug reset
diagnose debug flow filter saddr 10.10.10.50
diagnose debug flow filter daddr 10.20.20.100
diagnose debug flow show console enable
diagnose debug flow trace start 10
diagnose debug enable

Caution: Real-time debug commands consume CPU and memory resources. Always disable debugging routines immediately after collecting diagnostic data.

To safely clean up debug traces, run:

diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset

Common Mistakes

• Enabling NAT on Firewall Policies: Enabling Source NAT on IPsec policies changes host source IPs into WAN or interface IPs, preventing proper Phase 2 selector matching or causing asymmetric reply paths. Keep NAT disabled for normal site-to-site policy rules.
• Mismatched Phase 2 Selectors: Defining 10.10.10.0/24 local and 10.20.20.0/24 remote on HQ, but incorrectly entering 10.10.0.0/16 on the Branch side will cause Phase 2 negotiation to fail immediately. Ensure exact mirror configurations.
• Missing Return Routes: Setting up outgoing routes on HQ while forgetting to set up return routes on the Branch firewall leads to unidirectionally encrypted traffic that drops at the remote endpoint.
• Forgetting Dynamic Policy Definitions: FortiOS requires policies for incoming traffic from the tunnel interface to local LAN interfaces. Outbound-only policy configurations block return traffic packets.

Production Considerations

To ensure high availability, optimal performance, and security for enterprise deployments, apply the following production practices:

• Prefer IKEv2 over IKEv1: IKEv2 provides faster connection re-establishment, lower bandwidth overhead, native NAT traversal support, and superior error handling compared to IKEv1.
• Enable Dead Peer Detection (DPD): Configure DPD on both endpoints (e.g., set dpd on-idle) so FortiGate quickly detects dead peers and cleans up stale SAs.
• TCP MSS Clamping: Encapsulation overhead reduces the effective MTU available for transit packets. Adjust TCP MSS options on the IPsec phase1 interface to prevent fragmentation drops:

  config vpn ipsec phase1-interface
      edit "HQ-to-Branch"
          set tcp-mss-sender 1380
          set tcp-mss-receiver 1380
      next
  end
  

• SD-WAN Integration: In dual-ISP environments, terminate separate IPsec tunnels over each ISP circuit and group them into an SD-WAN zone. This allows automated performance-based failover and load balancing across redundant site-to-site tunnels.

Related FortiGate Guides

• FortiGate IPsec VPN troubleshooting
• FortiGate remote-access IPsec VPN
• FortiGate session troubleshooting
• FortiGate HA and failover

Summary

Building a FortiGate site to site IPsec VPN requires clear alignment of Phase 1 connection settings, Phase 2 network selectors, route tables, and firewall access policies. A route-based design provides flexible network control by decoupling encapsulation logic from policy filtering, allowing seamless scalability across complex enterprise topologies.

For the next step, see the NetworkFix FortiGate section for related firewall configuration guides and troubleshooting content.