Troubleshooting IPsec site-to-site tunnel connectivity on FortiGate

1. Identify the affected VPN type and check Phase 2.

   Determine whether the issue involves a Site-to-Site VPN or Dial-Up VPN. Check Phase 2 from the GUI or CLI. In the GUI, use the IPsec tunnel status and select the Up or Inactive status name. The IPsec Monitor is also available under Dashboard -> IPsec Monitor.

   Check one tunnel:

   Copy CLI

   diagnose vpn tunnel list name <phase1-name>
   

   Check all tunnels:

   Copy CLI

   diagnose vpn tunnel list
   

   Interpret the result as follows:

   • SA=0: Phase 2 is down; continue with Phase 1 checks.
   • SA=1: Phase 2 is up; if traffic fails, proceed to step 6.
   • The SA alternates between Up and Down: proceed to step 7.

2. Check whether Phase 1 is established.

   Run the command from the relevant VDOM when VDOMs are enabled:

   Copy CLI

   diagnose vpn ike gateway list name <phase1-name>
   

   To display every Phase 1 gateway:

   Copy CLI

   diagnose vpn ike gateway list
   

   • State Connecting: proceed to step 3.
   • State Established: proceed to step 5.

3. Troubleshoot a Phase 1 failure from the responder.

   The initiator sends the original tunnel setup request. The responder receives it, so responder-side VPN status messages are generally the most useful for a Phase 1 failure.

   Verify all of the following:

   1. Determine whether another device exists upstream of the firewall.
   2. Confirm that the VPN gateway uses the correct outgoing interface.
   3. Confirm that the remote IP address is correct.
   4. Capture packets on the outgoing interface and verify that traffic arrives from the remote peer. Ensure that an upstream device permits IKE on ports 500/4500.

   In FortiOS v7.2 and v7.4, the GUI option is under the network section as Diagnostics, followed by New Packet Capture, rather than Packet Capture.

   CLI capture:

   Copy CLI

   diagnose sniffer packet any 'host <remote-peer-ip> and port (500 or 4500)' 6 0 l
   

   Press Ctrl+C to stop the capture.

4. Collect IKE debug output when UDP 500/4500 traffic is visible.

   On the receiver, start the debug and then initiate the tunnel or matching traffic from the remote side. Before FortiOS v7.4.1, use:

   Copy CLI

   diagnose debug console timestamp enable
   diagnose vpn ike log-filter dst-addr4 10.10.100.109
   diagnose debug application ike -1
   diagnose debug enable
   

   Here, 10.10.100.109 is the remote gateway.

   Starting with FortiOS v7.4.1, diagnose vpn ike log-filter dst-addr4 changed to diagnose vpn ike log filter rem-addr4. Display available filters with:

   Copy CLI

   diagnose vpn ike log filter ?
   

   Available filters are:

   • loc-addr4: IPv4 local gateway address range.
   • mloc-addr4: Multiple IPv4 local gateway addresses.
   • rem-addr4: IPv4 remote gateway address range.
   • mrem-addr4: Multiple IPv4 remote gateway addresses.
   • loc-addr6: IPv6 local gateway address range.
   • mloc-addr6: Multiple IPv6 local gateway addresses.
   • rem-addr6: IPv6 remote gateway address range.
   • mrem-addr6: Multiple IPv6 remote gateway addresses.

   FortiOS v7.4.1 and later example:

   Copy CLI

   diagnose vpn ike log filter rem-addr4 10.10.100.109
   diagnose debug application ike -1
   diagnose debug console timestamp enable
   diagnose debug enable
   

   In FortiOS v7.4.x, a busy VDOM can be filtered by tunnel name:

   Copy CLI

   diagnose vpn ike log filter name <name of tunnel>
   

   Run the packet capture and debug at approximately the same time. If VDOMs are enabled, enter the appropriate VDOM before running these commands.

   Stop and clear debugging with:

   Copy CLI

   diagnose debug reset
   diagnose debug disable
   

   If matching configurations still produce output similar to:

   Copy CLI

   ike 0:testvpn:testvpn: IPsec SA connect 5 x.x.x.y->x.x.x.x:0
   ike 0:testvpn: ignoring request to establish IPsec SA, no policy configured
   

   ensure that a firewall policy exists for the tunnel interface.

5. Troubleshoot Phase 2 when Phase 1 is established.

   1. Confirm that encryption and hash algorithms match on the initiator and responder.
   2. If PFS is enabled, verify that both peers use matching settings.
   3. Verify that the quick mode selectors, or interesting traffic definitions, match on both peers.
   4. If Phase 2 remains down, capture ports 500/4500 and run:
   Copy CLI

   diagnose vpn ike gateway list
   diagnose vpn ike log-filter dst-addr4 10.10.100.109
   diagnose debug console timestamp enable
   diagnose debug application ike -1
   diagnose debug enable
   

   Alternatively, display one gateway with:

   Copy CLI

   diagnose vpn ike gateway list name <tunnel-name>
   

   Stop debugging with:

   Copy CLI

   diagnose debug reset
   diagnose debug disable
   

   If IKE debug reports tunnel is administratively down, enable the interface in Network -> Interfaces. Edit the tunnel interface, select Enable, and save with OK. Alternatively:

   Copy CLI

   config system interface
       edit <tunnel name>
           set status up
       next
   end
   

   When VDOMs are enabled, execute the relevant commands in the VDOM context.

6. Troubleshoot traffic when Phase 2 is up.

   After establishment, traffic is encapsulated as ESP and sent to the peer.

   1. Verify that the Phase 2 quick mode selector covers the affected traffic. For example, selectors permitting 192.168.1.0/24 to 192.168.2.0/24 do not include a source PC at 10.10.100.100/24; traffic from that PC to 192.168.2.0/24 is therefore dropped.
   2. Check IPv4 policies and routing:
      • A policy must exist for the traffic flow.
      • Source and destination address objects must permit the flow.
      • Routes must point correctly to the tunnel.
      • If debug flow permits the traffic but reports No matching IPsec selector, drop, check whether NAT is enabled on the outbound IPsec VPN policy. Disable NAT on that policy and retest.
   3. If ping fails although the policy, Phase 2 selectors, and static or blackhole routes are correct—and debug flow shows traffic leaving through the correct tunnel and gateway—check Windows Firewall on the destination. Windows Firewall blocks ICMP requests by default. This condition can coexist with successful pings to the FortiGate interface and remote WAN interface. Permit ICMP temporarily for connectivity testing.
   4. If the problem continues, capture traffic for the remote peer with protocol 50 (ESP), and use separate SSH sessions.

   SSH session 1 — debug flow:

   Copy CLI

   diagnose debug console timestamp enable
   diagnose debug flow filter addr <destination-IP>
   diagnose debug flow filter proto <1 or 17 or 6>
   diagnose debug flow show iprope enable
   diagnose debug flow show function-name enable
   diagnose debug flow trace start 1000
   

   The protocol filter is optional: 1=ICMP, 6=TCP, and 17=UDP. Other protocol numbers can be used, such as 89 for OSPF.

   Stop debugging with:

   Copy CLI

   diagnose debug reset
   diagnose debug disable
   

   SSH session 2 — tunnel state:

   Copy CLI

   diagnose vpn tunnel list
   

   Or limit the output to one Phase 2 tunnel:

   Copy CLI

   diagnose vpn tunnel list name <phase2_tunnel_name>
   

   SSH session 3 — clear source and destination sessions:

   Copy CLI

   diagnose sys session filter clear
   diagnose sys session filter src <source-IP>
   diagnose sys session clear
   diagnose sys session filter clear
   diagnose sys session filter dst <destination-IP>
   diagnose sys session clear
   

   When VDOMs are enabled, do not run the session-clearing commands from a VDOM context.

   Collect packet captures and logs at approximately the same time and attach them, together with the network topology if available, to the Fortinet case. TAC can use the material to attempt ESP decryption in Wireshark. If the peer is another FortiGate, capture traffic there as well to determine whether encrypted packets arrive or are lost in transit.

7. Troubleshoot a flapping VPN.

   First establish whether one tunnel or all tunnels are affected.

   If every VPN is affected, check the Internet connection and collect firewall/interface health data:

   Copy CLI

   diagnose debug crashlog read
   diagnose sys top 2 50
   get system performance status
   diagnose hardware sysinfo conserve
   diagnose hardware deviceinfo nic <interface-name>
   execute tac report
   

   Press Ctrl+C to stop diagnose sys top 2 50; run it for five iterations. If VDOMs are enabled, do not execute these commands from the Global context.

   If only one tunnel flaps:

   1. Collect the VPN Events log.
   2. Determine whether the tunnel was previously stable.
   3. Review recent network or FortiGate changes and any newly installed network equipment; validate all changes and additions.
   4. Check for DPD failure and confirm that a local-in policy does not block DPD packets from the remote IPsec peer.
   5. If these checks do not identify the cause, collect the IKE logs and packet capture described in step 4.

   Submit captures, logs, and any network topology to TAC, ensuring that captures and logs cover the same period.

8. Collect the full TAC diagnostic set.

   SSH session 1:

   Copy CLI

   diagnose debug console timestamp enable
   diagnose vpn ike log filter dst-addr4 /rem-addr4 x.x.x.x
   diagnose debug application ike -1
   diagnose debug enable
   

   x.x.x.x is the remote gateway IP address.

   SSH session 2:

   Copy CLI

   diagnose debug crashlog read
   diagnose sys top 2 50
   get system performance status
   diagnose hardware sysinfo conserve
   diagnose hardware deviceinfo nic <interface-name>
   diagnose vpn ipsec status
   diagnose vpn ike errors
   diagnose vpn ike gateway list
   diagnose vpn tunnel list
   execute tac report
   

   Press Ctrl+C to stop diagnose sys top 2 50; run it for five iterations.

   Stop debugging with:

   Copy CLI

   diagnose debug reset
   diagnose debug disable
   

   Also collect two packet captures:

   • IKE traffic on UDP ports 500/4500.
   • ESP traffic using protocol 50.

   Some ISPs block port 500 when no ESP packets are received, requiring NAT-T under phase1 -> network. An ISP may also filter ESP by protocol number even though the tunnel itself is established.

9. Flush the tunnel when a clean renegotiation is required.

   Use:

   Copy CLI

   diagnose vpn tunnel flush <phase1-name>
   diagnose vpn ike gateway clear name <phase1-name>
   

   Or:

   Copy CLI

   diagnose vpn tunnel flush <phase1-name>
   diagnose vpn ike gateway flush name <phase1-name>
   

Use the following checks after correction:

1. Confirm Phase 1 reports Established:

diagnose vpn ike gateway list name <phase1-name>

2. Confirm Phase 2 reports Up with SA=1:

diagnose vpn tunnel list name <phase1-name>

3. Generate matching traffic and confirm it traverses the expected tunnel and policy.
4. Under Dashboard -> IPsec Monitor, review encrypt and decrypt counters:
   • Increasing encrypts with no decrypts may indicate that return traffic is not reaching the FortiGate.
   • Decrypts with no encrypts indicate that traffic arrives from the peer, but is not being sent toward the LAN or no LAN traffic is arriving for encryption.
   • If both counters remain at zero, identify which peer initiates traffic, verify that traffic reaches the FortiGate, and confirm the required firewall policies.

If diagnostic debugging remains enabled, stop and reset it:

diagnose debug reset
diagnose debug disable

No configuration rollback procedure is specified. If NAT was disabled or the tunnel interface was enabled solely as a test, restore the prior setting only if required by the intended design.