Cisco Bug: CSCvu15259 - Vedge receives a packet to remove SPIs for duplicate IKEv2 SAs but it removes all the SPIs instead.
Oct 14, 2020
- Cisco SD-WAN
Known Affected Releases
16.9.3 18.3.5 19.2.3 20.4.1 unspecified
Symptom: In the scenario of an IPSEC tunnel between a Vedge and a C1101, when there are duplicate IKEV2 SAs and the ISR is the initiator of negotiation. It sends a DELETE packet to remove the SPIs associated with those duplicate SAs. Vedge receives the DELETE packet, processes it, and initiates the removal of the associated SPIs, however, it removes all SPIs instead (the ones not mentioned in the removal packet) and the tunnel goes down. A second problem results from the one mentioned above when the tunnel is down, Vedge does not start a new negotiation, but rather tries to negotiate new SPIs with a CREATE CHILD_SA request and it gets stuck in RETRY_INITIATE status. ISR has the initial tunnel (before duplicate SAs) installed, therefore it rejects the CREATE_CHILD_SA request due to "IPsec SA with same proxies already exists" and sends a NOTIFY(TEMPORARY FAILURE) packet. This last behavior persists between the two devices. Conditions: The customer simulates a failover scenario with shutdown / no shutdown the physical interface with which it reaches the peer. In the Vedge when the interface is "shut", the tunnel goes down and in the ISR router the VPN tunnel remains up until the maximum number of retransmissions is reached. The ISR tries to build a new tunnel but fails because the vedge interface is still down. When the interface is "no shut", the vedge immediately starts a new negotiation and the tunnel is established without a problem. So far so good. However, the ISR was still retransmitting packets just before the Vedge initiated negotiation, therefore ISR currently has two sessions for the same peer (one in READY and one in IN-NEG status.) READY = IKE negotiation with Vedge as Initiator IN-NEG = IKE negotiation with ISR as initiator due to the attempt to establish a tunnel when Vedge was down. Vedge responds to ISR negotiation and a new entry (Tunnel) is established. In the ISR immediately after having completed the negotiation, it realizes that an entry already exists with the same proxies and it removes the duplicate SAs and sends a DELETE packet to the Vedge for those specific SA's. Vedge receives the DELETE and processes the packet without problem removing the specific SPIs indicated in the DELETE packet. Unfortunately, VEDGE not only deletes the specified SPIs but also deletes all the SPIs associated with that Tunnel and the VPN goes down. A second problem results from the above mentioned when the tunnel is down, Vedge does not start a new negotiation, but rather tries to negotiate new SPIs with a CREATE CHILD_SA request and it gets stuck in RETRY_INITIATE status. ISR has the initial tunnel (before duplicate SAs) installed, hence it rejects the CREATE_CHILD_SA request due to "IPsec SA with same proxies already exists" and sends a NOTIFY (TEMPORARY FAILURE) packet. This last behavior persists between the two devices.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases