|
When manually executing 'diagnose vpn ike gateway flush' on the secondary IPsec FGSP member, the tunnel is flushed in the primary member.
The following debug commands can be read with IKE debugging:
Secondary:
diagnose vpn ike gateway flush
2025-11-13 19:14:53.104569 ike 0:VPN-1-221_1: deleting
2025-11-13 19:14:53.104750 ike 0:VPN-1-221_1: flushing
2025-11-13 19:14:53.104887 ike 0:VPN-1-221_1: deleting IPsec SA with SPI 41601789
2025-11-13 19:14:53.104941 ike 0:VPN-1-221_1:VPN-1-221: deleted IPsec SA with SPI 41601789, SA count: 0
2025-11-13 19:14:53.104966 ike 0:VPN-1-221_1:VPN-1-221: delete
Primary:
2025-11-13 19:14:53.145451 ike 0:VPN-1-221_1: HA del IKE SA 8ba5f85506579855/9537361887e9df8c
2025-11-13 19:14:53.145529 ike 0:VPN-1-221_1:11: HA send IKE SA del 8ba5f85506579855/9537361887e9df8c
2025-11-13 19:14:53.145556 ike 0:VPN-1-221_1: deleting IPsec SA with SPI 41601789
2025-11-13 19:14:53.145617 ike 0:VPN-1-221_1:VPN-1-221: deleted IPsec SA with SPI 41601789, SA count: 0
This is by design:
In FGSP, there is no fixed Primary or Secondary FortiGate. Any tunnel can operate on any member of the FGSP group at any given time. This means the Primary or Secondary role can switch very quickly.
When a tunnel is flushed from one FortiGate, if another FortiGate still retains it, it would break the tunnel synchronization rules and create asynchronous tunnel records among FGSP members.
Additionally, there can be multiple members in an FGSP group. If only the primary tunnel could accept the flush command, an administrator will need to locate the device currently holding the primary tunnel, log in, and flush it. If the primary tunnel switches, the admin will have to repeat the process, which is inefficient.
|
