FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
mricardez
Staff
Staff
Article Id 284890
Description This article describes the causes of IPSec flaps or packet loss occurring after performing an upgrade to FortiGate v7.0.13, v7.2.6 or v7.4.1.
Scope FortiGate v7.0.13, 7.2.6 and 7.4.1.
Solution

Some customers have reported IPSec flapping or packet loss after upgrading FortiGate to v7.0.13, v7.2.6 or v7.4.1.

 

This issue affects topologies where there are dynamic IPSec interfaces in redundancy, with IKE used to install a route static into the table through the Phase 2 selectors negotiated.


config vpn ipsec phase1-interface

edit <name>

set type dynamic
set add-route {enable | disable}

next

end

 

KBIPsecFlappingPacketLoss-17Nov2023.png

 

 

The following methods can be used to identify the issue:

 

1. Packet-loss on the SDWAN health-check

 

diagnose sys sdwan health-check
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

 

2. Phase1 with short time (seconds) after being created:


diagnose vpn ike gateway list | grep "name:\|created"
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

 

3. Only one route is installed on the routing table:

 

get router info routing-table details 192.168.101.0

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

 

4. Run a debug of the IKE process:

 

diagnose debug application ike -1
diagnose debug enable


With a text editor, filter the network of the phase2 selector '192.168.101.0' to obtain a pattern similar to the following:

 

mark@lat-mricardez:~/Descargas$ grep 192.168.101.0 console-output-CLI-Console-\(1\)\(12\).txt
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

To fix this issue, change the route-overlap to 'allow' in Phase2:


config vpn ipsec phase2-interface

edit <name>

set route-overlap allow

end

 

  • The reason is the change introduced in BUG 0872769.
  • The default setting of 'route-overlap' is 'use-new', which will delete the new routes after detecting twin connections.
  • The 'set-overlap use-new' setting in phase2 was not working as intended, and was instead allowing the route-overlap into the routing table.
  • This issue was reverted in v7.0.13, v7.2.6 and v7.4.1, which has lead to this experience after an upgrade.
  • Using 'set route-overlap allow' is the correct configuration.
  • Changing to 'set route-overlap allow' before upgrading will ensure a seamless upgrade.
  • Upon upgrading before changing the setting, it will be necessary to flush the IPSec for it to take effect (diagnose vpn ike gateway flush).