03-09-2020 09:08 AM
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
03-09-2020 09:55 AM
Hi,
Is routing functional? Do you have each protected network routed egress the correct interface? Can you share your VPN and routing configuration for all tunnels from both sides? Also, post the complete output of the "debug".
Regards,
Cristian Matei.
03-09-2020 11:02 AM
I can only share the configuration on our side, since we don't have access to the other end. Both tunnels on our ASA (one working and one non-working) are identical, except for peer IP and ACL.
access-list VENDOR extended permit ip host 10.11.120.106 172.16.185.224 255.255.255.224
crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA256
protocol esp encryption aes-256
protocol esp integrity sha-256
crypto map CRYPTOMAP 10 match address VENDOR
crypto map CRYPTOMAP 10 set peer 172.16.185.204
crypto map CRYPTOMAP 10 set pfs group14
crypto map CRYPTOMAP 10 set ikev2 ipsec-proposal ESP-AES256-SHA256
crypto map CRYPTOMAP interface outside
crypto ikev2 policy 4
encryption aes-256
integrity sha256
group 14
prf sha256
lifetime seconds 28800
crypto ikev2 enable outside
group-policy VENDOR-GP internal
group-policy VENDOR-GP attributes
vpn-tunnel-protocol ikev2
tunnel-group 172.16.185.204 type ipsec-l2l
tunnel-group 172.16.185.204 general-attributes
default-group-policy VENDOR-GP
tunnel-group 172.16.185.204 ipsec-attributes
ikev2 local-authentication pre-shared-key *
ikev2 remote-authentication pre-shared-key *
peer-id-validate nocheck
nat (inside,outside) source static LOADBAL-PRIV LOADBAL-PUBLIC destination static VENDOR_IP VENDOR_IP no-proxy-arp route-lookup
Debug is attached below (has results from packet-tracer in the results). This is a policy-based VPN, and the only routes are the gateway plus ones to the internal network for the pertinent 10.x.x.x networks. Routing is functional. The debug was obtained using packet-tracer, which should bring up the tunnel.
Yes, the protected network egresses the correct interface. Even if it weren't, wouldn't phase 1 stay up?
03-09-2020 11:49 AM - edited 03-09-2020 11:52 AM
I noted in your debug your Child sa is not coming up.
and why your access-list is different you showed us some thing in debug its completely something else?
nat (inside,outside) source static VEND_TUL_LB_VIP VEND_TUL_LB_VIP_NAT destination static LAN_VEND_CHICAGO LAN_VEND_CHICAGO no-proxy-arp
03-09-2020 10:18 AM
need more data to analyse it.
debug crypto condition peer x.x.x.x
debug crypto ikev2 platform 127
debug crypto ikev2 protocol 127
debug crypto ipsec 127
!
capture ISAKMP1 trace interface outside ip host x.x.x.x host y.y.y.y
capture ISAKMP2 trace interface outside ip host y.y.y.y host x.x.x.x
where x.x.x.x is your outside interface ip address and Y.Y.Y.Y is remote peer ip address
!
logging buffered debugging
logging buffer-size 7665554
and share the outputs.
03-09-2020 11:03 AM
I won't have access to the ASA until Wednesday. I'll do the additional debugging and commands then. Thanks
03-12-2020 07:15 AM
The remote side made a change to the various tunnels prior to our meeting yesterday, and all came up immediately yesterday. I've requested details on what change they made, but I've not heard back. The problem is solved.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide