FortiExpert logoFortiExpert
Sign in
← Back to knowledge base
high#0872769

Troubleshooting IPsec flapping or packet loss after upgrading FortiGate

Confirmed 9/18/2026

Problem

After an upgrade, redundant dynamic IPsec tunnels may flap or experience packet loss when IKE installs static routes based on negotiated Phase 2 selectors. The issue applies when the Phase 1 interface is dynamic and `add-route` is enabled.

Symptoms

Typical indicators include high packet loss or a dead member in an SD-WAN health check, Phase 1 security associations showing an age of only a few seconds, only one of the redundant IPsec routes appearing in the routing table, and IKE debug output repeatedly moving, deleting, and adding the same selector route between tunnels.

Environment

FortiGate deployments with redundant dynamic IPsec interfaces where IKE installs static routes from negotiated Phase 2 selectors. The relevant Phase 1 configuration is: ``` config vpn ipsec phase1-interface edit <name> set type dynamic set add-route enable next end ```

FortiOS version

FortiOS v7.0.13, v7.2.6, v7.4.1, and later versions

Root Cause

The behavior results from the change associated with bug 0872769. The default Phase 2 `route-overlap` value is `use-new`, which deletes new routes after twin connections are detected. Previously, `route-overlap use-new` did not behave as intended and allowed overlapping routes into the routing table. That behavior was reverted in FortiOS v7.0.13, v7.2.6, and v7.4.1, exposing configurations that depended on it. The supported configuration for retaining overlapping routes is `set route-overlap allow`.

Solution

  1. Confirm that the affected Phase 1 interface is dynamic and uses IKE-installed routes:
config vpn ipsec phase1-interface
    edit <name>
        set type dynamic
        set add-route enable
    next
end
  1. Check SD-WAN health-check status for excessive packet loss or a dead tunnel member:
diagnose sys sdwan health-check

An affected result can resemble:

Health Check(Spoke1):
Seq(4 VPN1): state(dead), packet-loss(95.000%) sla_map=0x0
Seq(5 VPN2): state(alive), packet-loss(11.000%) latency(9.479), jitter(4.353), bandwidth-up(19999998), bandwidth-dw(19999998), bandwidth-bi(39999996) sla_map=0x0
  1. Check whether Phase 1 SAs are repeatedly recreated and therefore show an age of only a few seconds:
diagnose vpn ike gateway list | grep "name:\|created"

Example:

name: VPN2_0
created: 1s ago
IKE SA: created 1/1 established 1/1 time 10/10/10 ms
IPsec SA: created 2/2 established 2/2 time 0/0/0 ms
name: VPN1_0
created: 1s ago
IKE SA: created 1/1 established 1/1 time 10/10/10 ms
IPsec SA: created 1/1 established 1/1 time 10/10/10 ms
  1. Check the selector destination in the routing table. For the example network, run:
get router info routing-table details 192.168.101.0

An affected system may contain only one route:

Routing table for VRF=0
Routing entry for 192.168.101.0/24
Known via "static", distance 15, metric 0, best
* via VPN1 tunnel 200.52.10.17, tun_id
  1. Enable IKE debugging:
diagnose debug application ike -1
diagnose debug enable

Filter the captured output in a text editor for the Phase 2 selector, such as 192.168.101.0. The issue is indicated by repeated moving route, del route, and add route messages that alternate the route between interfaces, for example:

ike 0:VPN1_0:562:1753: peer proposal is: peer:0:192.168.101.0-192.168.101.255:0, me:0:0.0.0.0-255.255.255.255:0
ike 0:VPN1_0:562:Spoke1LAN:1753: dst 0 7 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2:1748: moving route 192.168.101.0/255.255.255.0 oif VPN2(32) metric 15 priority 1 to 0:VPN1:1753
ike 0:VPN2:1748: del route 192.168.101.0/255.255.255.0 tunnel 20.0.0.3 oif VPN2(32) metric 15 priority 1
ike 0:VPN1:1753: add route 192.168.101.0/255.255.255.0 gw 200.52.10.17 oif VPN1(31) metric 15 priority 1
ike 0:VPN2:563:1755: TSi_0 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2:563:Spoke1-LAN_E:1755: TSi_0 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2_0:563:Spoke1-LAN_E:1755: dst 0 7 0:192.168.101.0-192.168.101.255:0
ike 0:VPN1:1753: moving route 192.168.101.0/255.255.255.0 oif VPN1(31) metric 15 priority 1 to 0:VPN2:1755
ike 0:VPN1:1753: del route 192.168.101.0/255.255.255.0 tunnel 200.52.10.17 oif VPN1(31) metric 15 priority 1
ike 0:VPN2:1755: add route 192.168.101.0/255.255.255.0 gw 20.0.0.3 oif VPN2(32) metric 15 priority 1
ike 0:VPN1_0:564:1761: peer proposal is: peer:0:192.168.101.0-192.168.101.255:0, me:0:0.0.0.0-255.255.255.255:0
ike 0:VPN1_0:564:Spoke1LAN:1761: dst 0 7 0:192.168.101.0-192.168.101.255:0
ike 0:VPN2:1755: moving route 192.168.101.0/255.255.255.0 oif VPN2(32) metric 15 priority 1 to 0:VPN1:1761
ike 0:VPN2:1755: del route 192.168.101.0/255.255.255.0 tunnel 20.0.0.3 oif VPN2(32) metric 15 priority 1
ike 0:VPN1:1761: add route 192.168.101.0/255.255.255.0 gw 200.52.10.17 oif VPN1(31) metric 15 priority 1
  1. Configure each applicable Phase 2 interface to permit route overlap:
config vpn ipsec phase2-interface
    edit <name>
        set route-overlap allow
    end
  1. If possible, apply set route-overlap allow before upgrading to avoid interruption. If the appliance was already upgraded before this change, flush the IPsec gateways so the setting takes effect:
diagnose vpn ike gateway flush

Verification

After applying the configuration and flushing IPsec when required, repeat these checks:

diagnose sys sdwan health-check

diagnose vpn ike gateway list | grep "name:\|created"

get router info routing-table details 192.168.101.0

Verify that SD-WAN packet loss returns to expected levels, Phase 1 SAs are no longer recreated every few seconds, and the required redundant IPsec routes remain installed instead of being moved repeatedly between tunnels.

Tags

No tags yet.

Community rating

— / 5 (0)

Discussion (0)

    No comments yet.