FortiGate IPsec VPN Tunnel Down: How to Troubleshoot It

By the Tech Matrix engineering team · Updated June 2026

A FortiGate IPsec site-to-site tunnel that won't come up almost always fails in one of two places: Phase 1 (IKE) or Phase 2 (IPsec SA). This guide walks the exact checks and CLI commands to find which phase is failing and why — then how to fix it.

Step 1 — Confirm which phase is down

First establish where the negotiation is breaking. In the GUI, open Dashboard > Network > IPsec and check whether Phase 1 and Phase 2 are up. Faster from the CLI:

diagnose vpn tunnel list

This lists each tunnel with its Phase 1 and Phase 2 selectors, the SPI, and encrypted/decrypted packet counts. If you see Phase 1 but no Phase 2 SA, the problem is Phase 2. If there's no Phase 1 at all, start there.

Step 2 — Phase 1 (IKE) is down

If Phase 1 never establishes, work through these in order:

Reachability: can the FortiGate reach the peer's public IP? Test with execute ping <peer-ip> and execute traceroute <peer-ip>.
IKE ports: confirm UDP 500 and 4500 (NAT-T) aren't blocked along the path. If the FortiGate is behind a NAT device, forward UDP 500/4500 to it.
Matching parameters: the pre-shared key, IKE version (v1/v2), mode, DH group, and at least one encryption/authentication proposal must match on both ends.
Peer ID: if either side uses aggressive mode or a non-IP local ID, confirm the peer ID type and value match.

Watch the live negotiation to see exactly where it fails:

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

Reproduce the connection, read the IKE messages, then stop with diagnose debug disable. The debug names the mismatch — for example "no SA proposal chosen" (proposal mismatch) or a pre-shared-key mismatch.

Step 3 — Phase 1 is up but Phase 2 won't establish

If IKE completes but no IPsec SA forms, the cause is almost always the Phase 2 selectors or proposals:

Quick-mode selectors: the local and remote subnets must mirror exactly on each side (your local = their remote, and vice-versa). A mismatch is the most common Phase 2 failure.
Phase 2 proposals: encryption, authentication, and PFS (and the PFS DH group) must have at least one match.
Keylife / replay: mismatched key lifetimes or replay settings can cause repeated rekey failures.

Step 4 — Tunnel comes up, then drops

If the tunnel establishes but won't stay up, check the Phase 2 settings: increase the Keylife value or enable Autokey Keep Alive / Dead Peer Detection (DPD) so idle tunnels aren't torn down. Also confirm both ends agree on at least one Phase 1 proposal so rekeys don't fail.

How Tech Matrix solves this in ~60 seconds

The slow part isn't the steps — it's running them one device at a time and matching output against the exact FortiOS version you're on. Tech Matrix connects to your FortiGate through a secure agent, reads diagnose vpn tunnel list and the IKE debug itself, and tells you which phase failed and why — grounded in your firmware and config, with your approval on every command.

Create free account →See how it works

Frequently asked questions

How do I check if a FortiGate IPsec tunnel is up?

In the GUI go to Dashboard > Network > IPsec, or run 'diagnose vpn tunnel list' in the CLI. Confirm both Phase 1 (IKE) and Phase 2 (IPsec SA) are established.

Why is FortiGate Phase 1 stuck on connecting?

Usually IKE traffic (UDP 500/4500) is blocked, the peer IP is unreachable, or the pre-shared key, IKE version, or proposals do not match on both ends.

What command shows IPsec debug output on FortiGate?

Run 'diagnose debug application ike -1' then 'diagnose debug enable' to see live IKE negotiation, and 'diagnose debug disable' to stop.

Next →Palo Alto VPN