IT Toolbox
Procedure

Diagnose an IPsec tunnel on FortiGate

Diagnose a FortiGate IPsec tunnel methodically across IKE Phase 1, Phase 2, selectors, routing, firewall policies, counters, packet capture, and targeted IKE debugging.

Networking

Objective

Identify precisely why a FortiGate IPsec tunnel is down, established without traffic, or working in only one direction by separating WAN reachability, IKE Phase 1, IPsec Phase 2, selectors, routing, and firewall-policy checks.

Prerequisites

  • Exact Phase 1 name and, when available, the related Phase 2 name.
  • Peer public IP or FQDN, the WAN interface in use, and the precise time of the last failure.
  • Expected local and remote subnets and the routing design: static routes, SD-WAN, or dynamic routing.
  • Access to VPN logs on both endpoints or a coordination channel with the remote administrator.
  • A configuration backup before any change.

Step-by-step procedure

1

Qualify the symptom before making changes

Determine whether Phase 1 is absent, Phase 2 does not establish, the tunnel is up without traffic, or traffic works in only one direction. Record the time, the last configuration change, and the affected subnets. Start with one reproducible test flow so each observation can be correlated.

get vpn ipsec tunnel summary
diagnose vpn ike status
Expected result
  • The affected tunnel is identified unambiguously.
  • The failure is classified as IKE/Phase 1, IPsec/Phase 2, or post-tunnel traffic.
2

Check peer reachability and IKE ports

Confirm that the WAN interface is operational and that traffic can reach the peer. IKE uses UDP 500 and normally switches to UDP 4500 when NAT-T is required; ESP may be visible directly when NAT-T is not used. Use a short filtered capture to confirm packets leave the firewall and whether replies return.

diagnose sniffer packet any 'host <PEER-IP> and (udp port 500 or udp port 4500 or proto 50)' 4 30 l
Expected result
  • IKE packets leave toward the peer and replies return when the upstream path is healthy.
3

Check IKE Phase 1

Inspect the IKE gateway state and compare IKE version, identity, cryptographic proposal, authentication, DPD, and peer address with the remote configuration. A PSK, certificate, identity, or proposal error usually blocks the negotiation here. Do not weaken cryptography at random; compare both sides first.

diagnose vpn ike gateway list
show full-configuration vpn ipsec phase1-interface
Expected result
  • An established IKE SA is visible when Phase 1 is healthy.
  • Critical Phase 1 parameters match the documented peer configuration.
4

Check Phase 2, selectors, and counters

An established Phase 1 does not guarantee Phase 2. Inspect IPsec SAs, proxy IDs/selectors, PFS, proposals, and lifetimes. Verify that source and destination networks match what the peer actually proposes. Use RX/TX counters to distinguish no traffic, transmit-only traffic, and bidirectional traffic.

diagnose vpn tunnel list name <TUNNEL-NAME>
show full-configuration vpn ipsec phase2-interface
Expected result
  • A Phase 2 SA is installed with the expected selectors.
  • Counters clearly show whether traffic is absent, one-way, or bidirectional.
5

Check routes and the egress path

Verify that the remote network uses the intended tunnel interface or SD-WAN path. When several routes exist, compare prefix length, distance, and priority. The remote site also needs a return route to the local network; a more specific route to the Internet or another VPN can leave the tunnel up but unusable.

get router info routing-table details <REMOTE-HOST>
get router info routing-table all
Expected result
  • The test destination is routed through the intended tunnel.
6

Check firewall policies and NAT

Identify the LAN-to-IPsec policy and, when required, the IPsec-to-LAN policy. NAT is normally disabled for a classic site-to-site VPN unless the design explicitly requires it. Check source and destination objects, services, policy order, and logs so a broader rule cannot divert the test flow to another egress path.

Expected result
  • The test flow matches the intended VPN policy.
  • NAT behavior and network objects are consistent with the Phase 2 selectors.
7

Trace a test flow through FortiOS

If the tunnel and routing look correct, run a filtered flow debug for one source and destination. The trace should reveal the route, policy decision, and any deny. Stop and reset the debug immediately after collection. On NP6/NP7 platforms, remember that hardware offload can hide some sessions from software traces.

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter saddr <SOURCE-IP>
diagnose debug flow filter daddr <DESTINATION-IP>
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 100
diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset
Expected result
  • The routing and policy decisions are visible for the exact test flow.
  • The debug is stopped immediately after evidence is collected.
8

Enable targeted IKE debugging only if necessary

For an unexplained negotiation failure, filter the IKE log to the affected tunnel, enable the IKE daemon debug temporarily, reproduce one negotiation, capture the first meaningful error, and stop the debug. Use that first mismatch to guide the correction rather than changing several proposals at once.

diagnose vpn ike log filter clear
diagnose vpn ike log filter name <PHASE1-NAME>
diagnose debug application ike -1
diagnose debug enable
diagnose debug disable
diagnose debug reset
Expected result
  • The error can be tied to authentication, proposal, identity, selector, or connectivity.

Validation

The procedure is validated when:

  • Phase 1 and Phase 2 are established with the documented parameters and selectors.
  • The route to the remote network uses the intended path and the VPN policy matches the traffic.
  • IPsec counters increase in both directions during the test.
  • A representative application flow works and no debug remains enabled.

Rollback

  • If a change was made during troubleshooting, restore the last documented configuration that allowed the tunnel to establish.
  • Clear an SA or restart a tunnel only after assessing impact, and prefer the narrowest possible action.
  • Restore the configuration backup if several settings were changed without producing a reproducible improvement.

Troubleshooting / common errors

  • If Phase 1 never forms, compare peer reachability, identity, authentication, and cryptographic proposals first.
  • If Phase 1 is up but Phase 2 is absent, compare selectors, PFS, proposals, and lifetimes on both endpoints.
  • If both phases are up but traffic fails, focus on routing, policy, NAT, return path, and packet counters.
♡ 0