Symptom

In the scenario where A and B (Hub) have an IKEv2 VPN and peer C, with the same IKE identity that peer A, attempts to negotiate an IKEv2 VPN with peer B, debugs for IKEv2 should show that the reason the tunnel with peer A was torn down was because peer C presented an existing IKE ID used on another connection, i.e., if the VPN network has multiple IKEv2 connections (such Hub and Spoke topologies) and more than 1 device has the same Local Identity Configured, the second IKEv2 connection will be established with the HUB device but the initial connection will be deleted with no apparent reason. This flap will continue over and over again every time the other peer try to recover its VPN session and debugs won't show why this is happening. Platforms like ASA/FPR handle this situation as a Reconnection when explaining why the previous VPN session was dropped. For DMVPN: *Jun 12 17:43:49.921: IKEv2-INTERNAL:(SESSION ID = 18,SA ID = 2):SM Trace-> SA: I_SPI=8E924045360F343C R_SPI=11EF39494B950CFB (R) MsgID = 1 CurState: READY Event: EV_DEL_NEG_TMO *Jun 12 17:43:49.922: IKEv2-INTERNAL:(SESSION ID = 18,SA ID = 2):Deleting negotiation context for peer message ID: 0x1 *Jun 12 17:43:57.614: IKEv2:(SESSION ID = 18,SA ID = 2):Queuing SA delete for IC *Jun 12 17:43:57.616: IKEv2-INTERNAL:(SESSION ID = 18,SA ID = 2):SM Trace-> SA: I_SPI=8E924045360F343C R_SPI=11EF39494B950CFB (I) MsgID = 1 CurState: READY Event: EV_DELETE *Jun 12 17:43:57.616: IKEv2-INTERNAL:(SESSION ID = 18,SA ID = 2):Action: Action_Null *Jun 12 17:43:57.616: IKEv2-INTERNAL:(SESSION ID = 18,SA ID = 2):SM Trace-> SA: I_SPI=8E924045360F343C R_SPI=11EF39494B950CFB (I) MsgID = 1 CurState: DELETE Event: EV_DELETE *Jun 12 17:43:57.617: IKEv2-INTERNAL:(SESSION ID = 18,SA ID = 2):Action: Action_Null *Jun 12 17:43:57.617: IKEv2-INTERNAL:(SESSION ID = 18,SA ID = 2):SM Trace-> SA: I_SPI=8E924045360F343C R_SPI=11EF39494B950CFB (I) MsgID = 1 CurState: INFO_I_BLD_INFO Event: EV_SND_SA_DEL *Jun 12 17:43:57.617: IKEv2:(SESSION ID = 18,SA ID = 2):Sending DELETE INFO message for IKEv2 SA [ISPI: 0x8E924045360F343C RSPI: 0x11EF39494B950CFB] For S2S: *Jun 12 23:38:26.873: IKEv2:(SESSION ID = 9,SA ID = 3):Sending Packet [To 192.168.2.2:500/From 192.168.10.10:500/VRF i0:f0] Initiator SPI : 747DAF80E6E8DA74 - Responder SPI : 1FABD5B8B74244F2 Message id: 1 IKEv2 IKE_AUTH Exchange RESPONSE *Jun 12 23:38:26.874: IKEv2-PAK:(SESSION ID = 9,SA ID = 3):Next payload: ENCR, version: 2.0 Exchange type: IKE_AUTH, flags: RESPONDER MSG-RESPONSE Message id: 1, length: 96 Payload contents: ENCR Next payload: NOTIFY, reserved: 0x0, length: 68 *Jun 12 23:38:26.875: IKEv2:(SESSION ID = 9,SA ID = 3):Auth exchange failed *Jun 12 23:38:26.876: IKEv2-ERROR:(SESSION ID = 9,SA ID = 3):: Auth exchange failed *Jun 12 23:38:26.880: IKEv2:(SESSION ID = 9,SA ID = 3):Abort exchange *Jun 12 23:38:26.880: IKEv2:(SESSION ID = 9,SA ID = 3):Deleting SA

Conditions

- HUB and SPOKE topology (DMVPN or S2S where the HUB works as concentrator for more than 1 peer device) - IKEv2 protocol - Same local identity configured on more than 1 SPOKE device

Workaround

+ Shut down the tunnel for the second SPOKE device with the same local identity + Configure unique IKE Identity for each Spoke device in the VPN environment

Further Problem Description