We have 4 tunnels that will be built to one of our vendors, and they are using ASA's at both of their locations and we have 2 ASA's at both of ours. One tunnel came up OK, one is still not configured on the vendor end, and the final two tunnels won't come up. We've compared the configuration on our end to make sure the configuration is identical for the one tunnel that does work, and our vendor states they have done the same. We've also shared the configurations when one a Zoom conference, and things appear OK on both ends to me. Here is what we are seeing, and I'd really appreciate any ideas on this one:
1) IKEv2-PROTO-2: (54): Peer's policy verified
2) IKEv2-PROTO-2: (54): Verification of peer's authentication data PASSED
3) IKEv2-PROTO-2: (54): IKEV2 SA created; inserting SA into database. SA lifetime timer (86400 sec) started
4) IKEv2-PROTO-2: (54): Session with IKE ID PAIR (10.150.185.204, 10.11.10.10) is UP
*5*) IKEv2-PROTO-1: (54): Detected unsupported failover version
One forum stated this was a problem with pfs, but we've confirmed both ends have pfs configured identically. There are limited hits when searching for this message on Google.
*6*) IKEv2-PROTO-2: (54): Process delete request from peer
Debugging is set to 255 our end. We're regrouping this week, but I'm at a loss as to what to try next. Here is some debug info around the above #6 message:
IKEv2-PROTO-2: (54): Sending Packet [To 10.150.185.204:4500/From 10.11.10.10:4500/VRF i0:f0]
(54): Initiator SPI : 2B1AD530F5ADA576 - Responder SPI : A3773F2815F6BC2B Message id: 1
(54): IKEv2 INFORMATIONAL Exchange RESPONSEIKEv2-PROTO-3: (54): Next payload: ENCR, version: 2.0 (54): Exchange type: INFORMATIONAL, flags: INITIATOR MSG-RESPONSE (54): Message id: 1, length: 76(54):
Payload contents:
(54): ENCR(54): Next payload: DELETE, reserved: 0x0, length: 48
(54): Encrypted data: 44 bytes
(54):
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_CHK_INFO_TYPE
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_RECV_DEL
IKEv2-PROTO-2: (54): Process delete request from peer
IKEv2-PROTO-2: (54): Processing DELETE INFO message for IKEv2 SA [ISPI: 0x2B1AD530F5ADA576 RSPI: 0xA3773F2815F6BC2B]
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_CHK4_ACTIVE_SA
IKEv2-PROTO-2: (54): Check for existing active SA
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_STOP_ACCT
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_IPSEC_DEL
IKEv2-PROTO-2: (54): Delete all IKE SAs
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_START_DEL_NEG_TMR
IKEv2-PROTO-5: (54): Action: Action_Null
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: EXIT Event: EV_CHK_PENDING
IKEv2-PROTO-5: (54): Sent response with message id 1, Requests can be accepted from range 2 to 2
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: EXIT Event: EV_NO_EVENT
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000000 CurState: EXIT Event: EV_FREE_NEG
IKEv2-PROTO-5: (54): Deleting negotiation context for peer message ID: 0x0
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (I) MsgID = 00000001 CurState: READY Event: EV_RECV_DEL
IKEv2-PROTO-5: (54): Action: Action_Null
IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (I) MsgID = 00000001 CurState: DELETE Event: EV_FREE_SA
IKEv2-PROTO-2: (54): Deleting SA
