FortiGate IPsec Site‑to‑Site VPN (IKEv2) — Full CLI Setup, Verification, and Troubleshooting Guide

·

Introduction

IPsec site‑to‑site VPNs remain one of the most common ways to securely connect branch offices, data centers, and partner networks over the public Internet. On FortiGate, you can build these tunnels quickly via the VPN Wizard, but CLI configuration is often preferred in production for repeatability, change control, and automation. FortiOS uses IKE negotiations (Phase 1) to establish a secure control channel and then builds data‑plane IPsec SAs (Phase 2) for protected traffic. [docs.fortinet.com], [docs.fortinet.com], [community....rtinet.com]

This post focuses on a route‑based (interface‑mode) IPsec tunnel using IKEv2 and shows all key steps + commands, followed by verification and SOC‑friendly troubleshooting. [docs.fortinet.com], [docs.fortinet.com], [community....rtinet.com]

Background / Overview

What you’re building (route‑based IPsec)

A route‑based IPsec VPN on FortiGate creates a virtual tunnel interface that you route traffic into using static or dynamic routing. This is typically more scalable than policy‑based tunnels, especially when you have multiple subnets, want dynamic routing, or need advanced routing control. Fortinet’s docs describe how Phase 1 defines IKE negotiation parameters and that the interface type is tied to the tunnel identity (tun_id), which is why it can’t be changed after creation. [docs.fortinet.com], [docs.fortinet.com]

IKE Phase 1 vs Phase 2 (quick mental model)

  • Phase 1 (IKE SA): authentication + secure channel for negotiations. [docs.fortinet.com]

  • Phase 2 (IPsec SA): actual encrypted data‑plane parameters (selectors/proposals). [docs.fortinet.com], [docs.fortinet.com]

Network ports you must allow

IPsec commonly uses:

  • UDP/500 (IKE)

  • UDP/4500 (NAT‑Traversal / NAT‑T)
    These are frequently referenced in public FortiGate/IPsec configuration guides and troubleshooting checklists. [kevindarian.com], [networkinterview.com]

Technical Breakdown / Analysis

Lab topology (example)

We’ll use simple, realistic placeholders:

  • Site A (HQ FortiGate)

    • WAN interface: wan1 public IP: 203.0.113.10

    • LAN subnet: 10.10.10.0/24

  • Site B (Branch FortiGate)

    • WAN interface: wan1 public IP: 198.51.100.20

    • LAN subnet: 10.20.20.0/24

  • Tunnel name: A-to-B

  • IKE: IKEv2

  • Auth: Pre‑Shared Key (PSK)

Fortinet’s wizard and technical tips show typical site‑to‑site flows and that the wizard can automatically create addresses, routes, and policies; CLI gives you explicit control. [community....rtinet.com], [docs.fortinet.com], [docs.fortinet.com]

Step 0 — Pre‑flight checklist (do this first)

  1. Confirm both peers can reach each other’s WAN IPs (ping/traceroute from outside if possible). [networkinterview.com], [linkedin.com]

  2. Ensure no upstream device blocks UDP/500 and UDP/4500. [kevindarian.com], [networkinterview.com]

  3. Decide your crypto proposals and lifetime and use the same on both sides (mismatches are a top cause of failure; debug output will show “no proposal chosen”/negotiation mismatch). [networkinterview.com], [docs.fortinet.com]

  4. Decide whether you need NAT‑T and DPD (DPD is generally recommended). [docs.fortinet.com], [docs.fortinet.com]

Step 1 — Configure Phase 1 (IKE) on Site A

This defines the IKE negotiation parameters (peer, PSK, proposals, interface). [docs.fortinet.com]

config vpn ipsec phase1-interface

    edit "A-to-B"

        set interface "wan1"

        set ike-version 2

        set peertype any

        set remote-gw 198.51.100.20

        set psksecret "REPLACE_WITH_STRONG_PSK"

        # Proposals must match the peer

        set proposal aes256-sha256

        # Choose a DH group supported on both ends

        set dhgrp 14

        # Optional hardening/tuning

        set keylife 28800

        set dpd on-idle

        set nattraversal enable

    next

end

Why these fields matter: Fortinet documents Phase 1 as the definition of IKE negotiation parameters and explains the initiator/responder relationship. [docs.fortinet.com], [docs.fortinet.com]

Step 2 — Configure Phase 2 (IPsec SA/selectors) on Site A

Phase 2 defines the protected traffic selectors and IPsec proposals. [docs.fortinet.com], [docs.fortinet.com]

config vpn ipsec phase2-interface

    edit "A-to-B-p2"

        set phase1name "A-to-B"

        set proposal aes256-sha256

        set dhgrp 14

        set keylifeseconds 3600


        # Traffic selectors (local/remote protected subnets)

        set src-subnet 10.10.10.0 255.255.255.0

        set dst-subnet 10.20.20.0 255.255.255.0

    next

end

Tip: Multiple remote networks? Create multiple Phase 2 entries (one per remote subnet) or use broader selectors when appropriate, but keep least privilege in mind. Community and how‑to references show multi‑selector patterns in CLI. [getlabsdone.com], [community....rtinet.com]

Step 3 — Create static routes (Site A → Site B via tunnel)

Route‑based IPsec requires routing to the tunnel interface. Fortinet’s site‑to‑site and wizard guidance references static routes to remote subnets pointing at the tunnel interface. [community....rtinet.com], [docs.fortinet.com]

config router static

    edit 0

        set dst 10.20.20.0 255.255.255.0

        set device "A-to-B"

    next

end

Operational best practice: Fortinet community guidance notes adding a blackhole route in some designs to prevent traffic from leaking via the default route if the tunnel flaps (depends on your routing policy). [community....rtinet.com]

Step 4 — Firewall policies (permit HQ ↔ Branch over the tunnel)

Even with a tunnel and routes, FortiGate still needs policies that allow traffic from LAN to tunnel and back. Wizard docs note the wizard can auto-create these, but in CLI you create them explicitly. [community....rtinet.com], [docs.fortinet.com]

4A) Create address objects (optional but recommended)

config firewall address

    edit "HQ_LAN"

        set subnet 10.10.10.0 255.255.255.0

    next

    edit "BRANCH_LAN"

        set subnet 10.20.20.0 255.255.255.0

    next

end

4B) Create policies

HQ → Branch

config firewall policy

    edit 0

        set name "HQ_to_Branch_over_IPsec"

        set srcintf "lan"

        set dstintf "A-to-B"

        set srcaddr "HQ_LAN"

        set dstaddr "BRANCH_LAN"

        set action accept

        set schedule "always"

        set service "ALL"

        set nat disable

        set logtraffic all

    next

end

Branch → HQ (reverse direction)

config firewall policy

    edit 0

        set name "Branch_to_HQ_over_IPsec"

        set srcintf "A-to-B"

        set dstintf "lan"

        set srcaddr "BRANCH_LAN"

        set dstaddr "HQ_LAN"

        set action accept

        set schedule "always"

        set service "ALL"

        set nat disable

        set logtraffic all

    next

end

Note: Your interface names may differ (internal, port2, etc.). The key is LAN → tunnel and tunnel → LAN policies with NAT disabled for site‑to‑site. Wizard guidance highlights NAT configuration choices (“No NAT between sites”) for site‑to‑site. [community....rtinet.com], [docs.fortinet.com]

Step 5 — Repeat the configuration on Site B (mirror settings)

Site B must mirror Site A with swapped local/remote subnets and peer IPs.

Phase 1 (Site B)

config vpn ipsec phase1-interface

    edit "B-to-A"

        set interface "wan1"

        set ike-version 2

        set peertype any

        set remote-gw 203.0.113.10

        set psksecret "REPLACE_WITH_STRONG_PSK"

        set proposal aes256-sha256

        set dhgrp 14

        set keylife 28800

        set dpd on-idle

        set nattraversal enable

    next

end

Phase 2 (Site B)

config vpn ipsec phase2-interface

    edit "B-to-A-p2"

        set phase1name "B-to-A"

        set proposal aes256-sha256

        set dhgrp 14

        set keylifeseconds 3600

        set src-subnet 10.20.20.0 255.255.255.0

        set dst-subnet 10.10.10.0 255.255.255.0

    next

end

Static route (Site B → Site A)

config router static

    edit 0

        set dst 10.10.10.0 255.255.255.0

        set device "B-to-A"

    next

end

Policies (Site B)

Create equivalent BRANCH_LAN and HQ_LAN objects (or reuse names), then allow LAN↔tunnel with logging enabled. This aligns with Fortinet’s wizard-created policy behavior and common CLI workflows. [community....rtinet.com], [getlabsdone.com]

Step 6 — Bring up, verify, and test

6A) Check Phase 1 / IKE status

Fortinet provides IPsec/IKE diagnosis commands; the quickest overview is:

diagnose vpn ike status

diagnose vpn ike gateway list

These commands are documented by Fortinet as part of IPsec diagnose workflows. [docs.fortinet.com]

6B) Check Phase 2 / Tunnel SA status

diagnose vpn tunnel list

get vpn ipsec tunnel summary

Public troubleshooting references and Fortinet diagnose docs commonly use these to validate Phase 2 SAs and counters. [docs.fortinet.com], [networkinterview.com]

6C) Generate “interesting traffic”

If your tunnel is not set to auto‑negotiate, it may remain down until traffic matches selectors. Trigger traffic with a ping from HQ LAN to Branch LAN (or vice versa). [networkinterview.com], [linkedin.com]

Step 7 — Troubleshoot quickly (common failure points + commands)

7A) Turn on time stamps (helps correlate with captures)

diag debug console time enable

This practice is commonly recommended in troubleshooting writeups to correlate logs and packet sniffers. [linkedin.com], [networkinterview.com]

7B) IKE debug (when Phase 1 won’t establish)

Fortinet and community troubleshooting flows use IKE debug output to identify PSK mismatch, proposal mismatch, peer reachability, and NAT‑T issues. [docs.fortinet.com], [networkinterview.com]

diagnose vpn ike log-filter clear

diagnose vpn ike log-filter dst-addr4 198.51.100.20

diagnose debug application ike -1

diagnose debug enable

# reproduce the issue (generate traffic)

diagnose debug disable

diagnose debug reset

7C) Packet sniffer (verify UDP 500/4500 reachability)

diagnose sniffer packet any "host 198.51.100.20 and (udp port 500 or udp port 4500)" 4 0 a

Seeing no packets? That’s usually upstream ACL/NAT/routing. Seeing packets but no SA? That points to PSK/proposal/ID mismatch—use IKE debug. Troubleshooting guides emphasize these patterns. [networkinterview.com], [docs.fortinet.com]

7D) Policy route corner cases

If only some traffic should traverse the VPN, Fortinet shows how to use policy routes and notes the need for a gateway IP when doing policy routing; they recommend setting an IP/remote‑IP on the tunnel interface for that scenario. [community....rtinet.com]

## Detection & Defense

1) Log what matters (and keep it searchable)

  • Enable traffic logging on the VPN policies (set logtraffic all) to capture session metadata. (Policy logging is a common practice in FortiGate deployments, and wizard-created policies are typically visible under IPv4 Policy.) [community....rtinet.com], [docs.fortinet.com]

  • Monitor VPN events and tunnel status changes using the built‑in VPN monitors and CLI status commands. [docs.fortinet.com], [docs.fortinet.com]

2) SOC indicators of trouble

  • Repeated IKE negotiation failures (e.g., frequent retries, no proposal chosen, auth/PSK failures) can indicate configuration drift or active probing. IKE debug/diagnose commands provide this visibility. [docs.fortinet.com], [networkinterview.com]

  • Phase 1 up but Phase 2 down often points to selector mismatch or routing/policy issues; diagnose vpn tunnel list is the fastest check. [linkedin.com], [docs.fortinet.com]

3) Hardening recommendations

  • Prefer IKEv2 for modern interoperability and cleaner negotiation behavior (widely used in current FortiGate templates and docs). [getlabsdone.com], [docs.fortinet.com]

  • Use strong PSKs (or certificates where feasible) and rotate them; PSK mismatch is a common operational failure and an obvious weak point if reused. [networkinterview.com], [community....rtinet.com]

  • Keep proposals consistent and avoid legacy algorithms; proposal mismatch is a top root cause of failed bring‑up. [networkinterview.com], [docs.fortinet.com]

Remediation & Best Practices

  1. Use the VPN Wizard for a baseline, then export/standardize CLI The wizard automatically creates addresses, routes, and policies; you can use it as a reference and then convert to a standardized CLI template. [community....rtinet.com], [docs.fortinet.com]

  2. Add explicit routing and consider blackhole routes where appropriate Fortinet community guidance notes blackhole routing as a tactic to prevent traffic escaping via the default route during tunnel flaps (validate carefully in your environment). [community....rtinet.com]

  3. Make troubleshooting repeatable Document your “golden” commands:

    • diagnose vpn ike gateway list

    • diagnose vpn tunnel list

    • IKE debug filter + debug application ike
      These are core Fortinet‑documented workflows for IPsec troubleshooting. [docs.fortinet.com], [networkinterview.com]

  4. Treat VPN changes like firewall changes Put crypto suite, lifetimes, DPD, and selectors under change control and validate after any ISP/NAT changes. Phase 1 is sensitive to interface type and tunnel identity constraints described by Fortinet. [docs.fortinet.com]

Key Takeaways

  • Route‑based IPsec on FortiGate = Phase 1 (IKE) + Phase 2 (IPsec) + routes + policies. [docs.fortinet.com], [docs.fortinet.com], [community....rtinet.com]

  • Most failures come down to reachability (UDP 500/4500), PSK mismatch, or proposal/selector mismatch—use FortiGate’s diagnose and IKE debug to pinpoint quickly. [networkinterview.com], [docs.fortinet.com], [kevindarian.com]

  • Enable logging on VPN policies and monitor tunnel state so SOC teams can differentiate misconfiguration from probing/noise. [docs.fortinet.com], [community....rtinet.com]

References (optional)

  • Fortinet Docs — Phase 1 configuration (FortiOS 7.6.x): https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/790613/phase-1-configuration [docs.fortinet.com]

  • Fortinet Docs — Site‑to‑site VPN (Administration Guide): https://docs.fortinet.com/document/fortigate/latest/administration-guide/202791/site-to-site-vpn [docs.fortinet.com]

  • Fortinet Docs — IPsec related diagnose commands: https://docs.fortinet.com/document/fortigate/7.6.3/administration-guide/44240/ipsec-related-diagnose-commands [docs.fortinet.com]

  • Fortinet Community — Site‑to‑site VPN between FortiGates (Wizard/notes): https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-VPN-Site-to-Site-between/ta-p/197922 [community....rtinet.com]

  • GetLabsDone — CLI site‑to‑site template examples: https://getlabsdone.com/how-to-configure-fortigate-site-to-site-vpn-step-by-step-using-the-cli/ [getlabsdone.com]

👇 Follow + Tools (clickable)

  • Sign up FREE (Web App): https://app.cyberhawkthreatintel.com

  • YouTube: https://www.youtube.com/@cyberhawkconsultancy

  • YouTube: https://www.youtube.com/@cyberhawkk

  • TikTok: https://www.tiktok.com/@cyberhawkthreatintel

  • X: https://x.com/cyberhawkintel

  • Telegram: https://t.me/cyberhawkthreatintel

Hashtags / SEO

#cyberhawktheatintel #cyberhawkconsultancy #cyberhawkk
Additional: #FortiGate #FortiOS #IPsec #IKEv2 #VPN #SiteToSiteVPN #NetworkSecurity #SOC #ThreatIntelligence