|
On the IKE debugs, the below error message is visible
'established IKE SA limit 4 reached, deleting 74f94841814c5424/a7ba7381614ebaf8' (Log file attached).
Explanation:
According to the IKE debug and verification commands, every 10 seconds a new IKEv2 SA is established, and as long as FortiOS has an embryonic limit of 4 IKE SAs per IPsec VPN, the oldest SA is deleted and a new one is created and this keeps on repeating.
This is a mechanism that FortiOS uses to prevent the IKE SA table from filling up with a large number of incomplete IKE SAs and overloading the IKE daemon and subsequently the FortiGate.
Nevertheless, from FortiGate's perspective, the IKEv2 SAs of the 'Test-Pri' IPSec tunnel are established and not in an embryonic (incomplete) state. So, for some reason, the vendor or other peer initiates yet another IKEv2 SA by sending an IKE_SA message and FortiGate responds by deleting its oldest IKEv2 SA and establishing a new one.
Therefore, tunnel flapping is therefore a consequence of the continuous IKE SA negotiation. It is a side effect of all the IKE SA negotiations never being completed from the Vendor's perspective.
This SA negotiation is not completed because FortiGate is the responder in this situation. From the FortiGate's vantage, the SA_INIT and IKE_AUTH initial exchanges are both considered completed.
Acting as a responder, the FortiGate is the one that sends the last message of the IKE_AUTH exchange. No new message is supposed to be exchanged after this IKE_AUTH. Since no 'informational' notification error is sent back to FortiGate by the Vendor, then from FortiGate's standpoint, it is normal that the newly negotiated IKE SA (and its associated Child-SA) be considered valid.
However, it is clear from the peer's behavior that the IKE_AUTH is not completed, it keeps re-transmitting its AUTH_REQUEST until the point where it considers the pending negotiation as timing out and switches to negotiating a brand new one from scratch.
Each AUTH_REQUEST received from the peer is correctly answered by the FortiGate with a re-transmission of its own AUTH_RESPONSE, and this consequently leads to the tunnel flapping and it shows the aforementioned error in the IKE debugs continuously.
The solution to this issue is to check with the vendor side and figure out why it is continuously sending SAs to FortiGate, which is making FortiGate to re-negotiate already established SAs. If still the issue persists, reach out to Fortinet TAC for further investigation.
Related document:
IPsec global IKE embryonic limit
|
