05-17-2024 01:26 PM
We have been trying to configure a test Cisco ISR 4331 router to establish an IKEv2 tunnel for VPN traffic to a Cisco ASA firewall hosted by our VPN provider. Currently when the ASA initiates the tunnel with traffic, it establishes and stays up until the ISR tries to transmit traffic across the tunnel, at which point the tunnel is deleted. Initiating the tunnel from the ISR is initially successful but results in the immediate deletion of the tunnel. I have been troubleshooting with the ASA host, but so far have been unable to determine why ISR traffic is causing the tunnel deletion. I've included a sanitized version of the ISR config and can provide debug logs if needed.
Solved! Go to Solution.
05-21-2024 03:07 PM
only in ISR add no-NAT for protect traffic
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/14132-ios-D.html
MHM
05-17-2024 01:38 PM
you have ACL apply to tunnel source try add udp 500 and 4500 to ACL
MHM
05-17-2024 02:05 PM
I added the following to ip access-list extended 199:
25 deny udp any any eq 500
105 deny udp any any eq 4500
Tunnel creation no longer progresses past the INIT phase.
05-17-2024 02:13 PM
you need to permit not deny
MHM
05-17-2024 02:25 PM
I tried that as well before posting my reply, it does not alter the behavior I was seeing before the change. Successful Phase 1 and Phase 2 negotiation, SA establishes but is immediately deleted.
Current GigabitEthernet0/0/0 access list:
Extended IP access list 199
1 permit udp any any eq isakmp (52 matches)
2 permit udp any any eq non500-isakmp
10 deny tcp any any eq 22 (23 matches)
20 deny udp any any eq tftp
30 deny udp any any eq 1025
40 deny tcp any any eq 1720
50 deny tcp any any eq 2005
60 deny udp any any eq 2005
70 deny udp any any eq 2427
80 deny udp any any eq 2517
90 deny tcp any any eq 4005
100 deny udp any any eq 4005
110 deny tcp any any eq 5060 (2 matches)
120 deny udp any any eq 5060 (9 matches)
130 deny tcp any any eq 5061 (2 matches)
140 deny udp any any eq 5061 (1 match)
150 deny tcp any any eq 6005 (10 matches)
160 deny udp any any eq 6005
170 deny tcp any any eq 11720
180 deny udp any any range 16384 32767 (9 matches)
190 permit ip any any (482470 matches)
05-19-2024 02:41 AM
what ASA code and what ISR code running ?
can you share ASA side config also and have you run the debug to check what causing the tear down the tunnel ? ( have you initiated the interesting traffic ?)
can you post show crypto isak sa and show cry ipsec sa
some of the ASA code dont like high DH - for testing try DH 5 and see if that works ?
try troubleshooting :
05-20-2024 08:06 AM
The ISR code is included with my original post, I've included the relevant sanitized code from the ASA with this response.
I have run the debugs, the logs show that the tunnel is established and is encrypting data between the ISR and ASA, unfortunately that data is a DELETE message to tear down the tunnel. Unfortunately, the only indication of why the tunnel delete request is initiating is not very helpful: "IKEv2:(SESSION ID = 52,SA ID = 1):Queuing IKE SA delete request reason: unknown". I've included a sanitized cycle from the debug log, as well as the output of the requested "show crypto" commands.
05-20-2024 08:47 AM
sure this not work
you run crypto map in asa and vti in ISR that not work
you need to use VTI in both
MHM
05-21-2024 12:47 PM
Sorry for the delay in response, I was working with the ASA host to remove an extraneous proposal and set the integrity to null, I wanted to verify those changes would not resolve issue before updating the ticket here. Would implementing a crypto map on the ISR, rather than trying to navigate the ASA host through configuring a tunnel, resolve the issue instead? When I've tried to configure a crypto map on the ISR to match their settings, there seems to be no attempt to establish an SA at all even after trying to generate interesting traffic.
05-21-2024 01:12 PM
share the ASA and ISR config when you use crypto map
MHM
05-21-2024 02:59 PM
05-21-2024 03:07 PM
only in ISR add no-NAT for protect traffic
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/14132-ios-D.html
MHM
05-22-2024 09:04 AM - edited 05-22-2024 11:21 AM
I added the following configuration:
ip access-list extended NONAT-TUNNEL
deny ip 10.245.167.0 0.0.0.255 172.24.16.0 0.0.3.255
deny ip 10.245.167.0 0.0.0.255 172.24.32.0 0.0.3.255
permit ip 10.245.167.0 0.0.0.255 any
route-map NONAT permit 10
match ip address NONAT-TUNNEL
ip nat inside source route-map NONAT interface GigabitEthernet0/0/0 overload
There was no change, ISR still shows no apparent attempts to establish a tunnel with the crypto map configured.
*Edit: Not sure why the "match ip address" line keeps auto-formatting. Also forgot to include the NONAT-TUNNEL, that has been corrected as well.
05-23-2024 09:10 AM
OK, the tunnel is establishing and stable now. Simple mistake on my end after the last change was the reason the tunnel wasn't initiating, pinging from a device connected to two private networks, it was sending the traffic over the network that already had an IKEv1 tunnel established. Thanks for your help MHM Cisco World, marked your solution as accepted.
05-23-2024 09:17 AM
Friend You are so so welcome
have a nice day
MHM
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