Troubleshooting Tip: Disabling FortiGate IPsec tunnel for five minutes as a workaround to an ISP stale cache issue

[Matt_B]

Description	This article demonstrates an uncommon ISP issue that can affect a previously working IPsec tunnel, preventing the tunnel from passing traffic until a manual workaround is applied.
Scope	VPN gateways not using NAT traversal, especially site-to-site tunnels.
Solution	This issue is likely to occur in environments with the following attributes: ISP devices use route caching for performance optimization. Tunnels send consistent data traffic (more than one packet every five minutes). ISP uses asymmetric routing or has a misconfigured failover for stateless traffic. This issue is not exclusive to FortiGate IKE gateways; it can affect any device forming an IPsec tunnel. This issue does not affect new deployments. If issues are encountered when configuring a new IPsec tunnel, configure a basic site-to-site tunnel and modify as needed. See this document: Basic site-to-site VPN with pre-shared key. Example: In the example deployment below, IKE traffic and ESP traffic typically take the same path between the two VPN gateways, allowing tunnel data traffic to pass between the sites. During a link flap, IKE traffic and ESP traffic is briefly misdirected to an unintended gateway. IKE traffic recovers automatically after the interface flap, but constant data traffic may preserve an incorrect routing or forwarding decision indefinitely for session-less ESP traffic. Workaround: Disable the IPsec tunnel on both sides and wait for five (5) minutes. This is a common caching default value and allows the invalid routing/forwarding decision to time out on the ISP device(s). GUI: Go to Network -> Interfaces -> Expand physical interface dropdown -> 'Right-Click' VPN tunnel interface -> Select 'Set Status' -> Select 'Down'. CLI: config system interface     edit "Tunnel"         set status down     next end If the administrator only has access to one side of the tunnel, disable the IPsec tunnel and wait seven (7) minutes to allow sufficient time for DPD to bring down the tunnel on the remote side. This interval is sufficient assuming the remote side has the default settings for either IKEv1 or IKEv2, see this article: Technical Tip: IKEv2 retransmission and DPD. After the interval has elapsed, enable the IPsec tunnel again. GUI: Go to Network -> Interfaces -> Expand physical interface dropdown -> 'Right-Click' VPN tunnel interface -> Select 'Set Status' -> Select 'Up'. CLI: config system interface     edit "Tunnel"         set status up     next end Verify the issue is resolved by triggering some tunnel traffic and observing bidirectional communication. BRANCH-FGT # diagnose sniffer packet Tunnel '' 4 4 l interfaces=[Tunnel] filters=[none] pcap_lookupnet: Tunnel: no IPv4 address assigned 2026-01-16 19:01:53.177369 Tunnel -- 10.56.253.1 -> 10.120.253.1: icmp: echo request 2026-01-16 19:01:53.177447 Tunnel -- 10.120.253.1 -> 10.56.253.1: icmp: echo reply 2026-01-16 19:01:57.178758 Tunnel -- 10.56.253.1 -> 10.120.253.1: icmp: echo request 2026-01-16 19:01:57.178813 Tunnel -- 10.120.253.1 -> 10.56.253.1: icmp: echo reply Note: Forcing NAT traversal can also work around this issue in some deployments, since this forces IKE and data traffic to be encapsulated in the same UDP port 4500 session. config vpn ipsec phase1-interface     edit "Tunnel"         set nattraversal forced     next end config vpn ipsec phase1-interface     edit "Tunnel"         set npu-offload disable     next end If the workaround does not resolve the issue, collect IPsec troubleshooting steps to verify it is not a firewall issue and reach out to both sites' ISPs to verify. If the workaround temporarily resolves the issue, but it reoccurs later, reach out to the relevant ISPs. Expected Symptoms: Typically, the VPN gateway administrator has no access to ISP devices to confirm the issue directly. It can only be suspected once other likely possibilities are eliminated. When the issue occurs, troubleshooting on FortiGates acting as VPN gateways will show the following: The tunnel shows 'Online' in the IPsec widget on both sides. Pinging the remote device appears in a packet capture on the remote device, whether or not the remote device responds. BRANCH-FGT: BRANCH-FGT # execute ping 10.17.56.2 PING 10.17.56.2 (10.17.56.2): 56 data bytes --- 10.17.56.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss HQ-FGT: HQ-FGT # diagnose sniffer packet any 'host 10.17.120.1 and proto 1' 4 10 l interfaces=[any] filters=[host 10.17.120.1 and proto 1] 2026-01-16 17:25:40.608175 port2 in 10.17.120.1 -> 10.17.56.2: icmp: echo request 2026-01-16 17:25:41.623471 port2 in 10.17.120.1 -> 10.17.56.2: icmp: echo request 2026-01-16 17:25:42.633330 port2 in 10.17.120.1 -> 10.17.56.2: icmp: echo request 2026-01-16 17:25:43.643193 port2 in 10.17.120.1 -> 10.17.56.2: icmp: echo request 2026-01-16 17:25:44.653001 port2 in 10.17.120.1 -> 10.17.56.2: icmp: echo request Note: In this case, the ping failure is expected because HQ-FGT is configured not to respond to ICMP echo requests. Both VPN gateways can send and receive IKE traffic (UDP port 500): HQ-FGT # diagnose sniffer packet any 'port 500 and host 10.17.120.1 and 10.17.56.2' 4 1000 l interfaces=[any] filters=[port 500 and host 10.17.120.1 and 10.17.56.2] 2026-01-16 17:18:01.760077 port2 out 10.17.56.2.500 -> 10.17.120.1.500: udp 80 2026-01-16 17:18:01.760457 port2 in 10.17.120.1.500 -> 10.17.56.2.500: udp 80 Packet sniffers on both sides show some outgoing ESP traffic, but no incoming ESP traffic. HQ-FGT # diagnose sniffer packet any 'proto 50 and host 10.17.120.1 and 10.17.56.2' 4 1000 l interfaces=[any] filters=[proto 50 and host 10.17.120.1 and 10.17.56.2] 2026-01-16 17:20:25.190744 port2 out 10.17.56.2 -> 10.17.120.1: ESP(spi=0x1a57ce12,seq=0xb) 2026-01-16 17:20:29.193242 port2 out 10.17.56.2 -> 10.17.120.1: ESP(spi=0x1a57ce12,seq=0xc) 2026-01-16 17:20:33.197337 port2 out 10.17.56.2 -> 10.17.120.1: ESP(spi=0x1a57ce12,seq=0xd) Note: To capture incoming ESP traffic in a packet sniffer, npu-offload must be disabled in the VPN tunnel phase1-interface configuration. Modifying this setting will cause a tunnel flap. config vpn ipsec phase1-interface     edit "Tunnel"         set npu-offload disable     next end DPD sent/received incrementing on one or both sides. Note that when IKEv2 is in use, it is normal to see DPD incrementing on only one side. HQ-FGT # diagnose vpn ike gateway list name <phase1-interface name> | grep DPD DPD sent/recv: 000000f3/000000f3 Bouncing the tunnel on either side causes the tunnel to renegotiate successfully, but no traffic passes. diagnose vpn ike gateway flush name <phase1-interface name> Rebooting either FortiGate does not resolve the issue. The workaround of disabling the IPsec tunnel and waiting for five minutes restores data connectivity. If the observed symptoms do not match expected symptoms, it is likely a different issue with the VPN gateway or ISP. Refer to general IPsec troubleshooting steps. Resolution: Since this is an ISP issue, it is not possible to prevent it from the VPN gateway configuration; it is only possible to recover manually once the issue occurs. If the issue occurs on a transit router, it is possible to prevent the issue by correctly configuring summary blackhole routes to stop traffic leaking on unintended routes when there is no more specific valid route. For a FortiOS example, see this document: Routing Concepts. Related articles: Troubleshooting Tip: Troubleshooting IPsec site-to-site tunnel connectivity Technical Tip: FortiGate IPsec VPN resource list Troubleshooting Tip: IPsec VPN tunnels Technical Tip: IPSec VPN NAT-traversal Technical Tip: Dynamic routing (BGP) over IPsec tunnel