cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3910
Views
5
Helpful
5
Replies

IKEv2 - Auth Reply Timer Expire

ehayric1320
Level 1
Level 1

Hello. I am assisting my customer with reestablishing an IKEv2 tunnel with their vendor which went down recently. The customer is using a Cisco CGR router. To keep this post simple, the vendor is telling me that they are receiving my phase one AUTH but they say that the reply from their side isn't getting back to me. The tunnel state on their side flaps between READY and down several times before finally giving up. My debug logs do show messages about failing to receive an offer message before the timer expires.

We have really thrown the kitchen sink at this. We tried to change the PSK to 'cisco' as a test but it still fails. I don't think the PSK is the issue. I am also seeing that the customer CGR is trying to establish multiple tunnels over UDP 500 and 4500 (NAT-T) but they always get stuck in the 'IN-NEG' state. Interestingly, the only tunnel that shows the PSK is the ones it tries to form over 4500. The UDP 500 shows unknown for the PSK.

The traffic does go through an ASA but it appears the proper rules are in place since they are receiving the first AUTH message from my customer. I can't think of anything else to add to my CGR configuration. I have gone over it with the vendor and they see nothing else to change. Could this be some sort of route issue on their end or an ISP issue causing the traffic not to get back? Could my ASA be blocking return traffic?

I tried to simulate this exactly in my CML lab and it works fine.

crypto ikev2 proposal customer-proposal
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ikev2 policy customer-policy
match fvrf any
proposal customer-proposal
!
crypto ikev2 keyring keychain-customer
peer vendor
address X.X.172.174
identity email csr@customer.com
pre-shared-key local tX5bVIF5UWmPWZs
pre-shared-key remote tX5bVIF5UWmPWZs
!
crypto ikev2 profile customer
match identity remote email domain customer.com
identity local email cgr@customer.com
authentication remote pre-share
authentication local pre-share
keyring local keychain-customer
dpd 55 2 periodic
!
crypto ipsec profile customer
set transform-set tset-customer
set pfs group14
set ikev2-profile customer
!
interface Tunnel370
description Tunnel-to-CGR-customer
no ip address
ip mtu 1400
ip tcp adjust-mss 1360
ipv6 address 2001:CAE2::2/64
ipv6 enable
tunnel source GigabitEthernet2/1
tunnel destination X.X.172.174
tunnel protection ipsec profile customer
!
interface GigabitEthernet2/1
description Uplink_to_ASA
no switchport
ip address 172.22.X.X 255.255.255.0
duplex auto
speed auto
ipv6 address FD95:4723:8FD9:1::2/64
ipv6 enable

*Aug 17 14:03:02.280: IKEv2-ERROR:(SESSION ID = 122,SA ID = 5):: Failed to receive the AUTH msg before the timer expired
*Aug 17 14:03:02.280: IKEv2:(SESSION ID = 122,SA ID = 5):Auth exchange failed
*Aug 17 14:03:02.280: IKEv2-ERROR:(SESSION ID = 122,SA ID = 5):: Auth exchange failed
*Aug 17 14:03:02.282: IKEv2:(SESSION ID = 122,SA ID = 5):Abort exchange
*Aug 17 14:03:02.282: IKEv2:(SESSION ID = 122,SA ID = 5):Deleting SA

5 Replies 5

@ehayric1320 The description of Gi2/1 implies you've an ASA in front of this router, is UDP/4500 permitted inbound/outbound on the ASA ACL? (I assume obviously UDP/500 already is)

Does the peer have an ACL or firewall in front of their router?

Can you take a packet capture and provide the output for review. Can you provide the full IKEv2 debugs?

 

 

Thank you for the reply Rob. I know UDP/4500 is permitted outbound. I am not sure about inbound but I know IP is allowed inbound just to the CGR router object from this vendor's public IP. I have asked the vendor about ACL's and they say there is none but who knows. I do not have remote access to the CGR router to obtain a capture at the moment but I have uploaded the full debug outputs along with a sanitized output of the ASA config.

This is not acl issue, 

I see two tunnel and I see tunnel source using ipv4 but the tunnel source interface is ipv4/ipv6 

Can you sure that the tunnel use from end to end ipv4?

I mentioned this to the vendor but they dismissed it rather quickly and said that wouldn't cause an issue. I see nothing in the logs or tunnel status that show IPv6 being used.

The ASA nat statement includes 'net-to-net' which is supposed to translate the first IPv4 address to first available IPv6 but I don't think it is having any effect.

for router 
tunnel mode ipsec ipv6 v4-overlay
use to pass ipv6 over ipv4.
but for ASA I will make check if this mode is available or not