Solved: Issue Getting IKEV1 Phase II Up

jonathanw84 · ‎09-16-2021

I am trying to configure an IKEv1 IPSEC tunnel on this ASR1001X. Phase I comes up no issue. However, none of the interesting traffic specified in the ACL being used for the encryption domain is being matched and therefor Phase 2 is never established. I've confirmed my configuration with the provider on the other end of the tunnel, and I have also ran "monitor capture" commands and have confirmed that the correct traffic is making it to the router for the correct destination.

We have other IPSEC tunnels that are functioning without issue, but these tunnels are route-based as opposed to this one which is policy-based. Is it possible that there is an overlap of the routes on the router or is there something I am missing? We do have a route that points any 10.0.0.0/8 network traffic to the firewall, but the networks specified in the encryption domain ACL are more specific. Please help!

Thanks!

jonathanw84 · ‎09-23-2021

Hi All,

TAC was able to figure this out and it was a very simple issue. We have other route-based tunnels on this same router and one of the static routes on the router was sending all traffic destined to this new policy-based tunnel to another direction, so it was never hitting the external interface where the crypto map was applied. I added a static route for the particular network in question (10.223.251.0/24) pointing out the external interface where the crypto map is applied and this has fixed the issue.

Thanks to all for taking a look!

View solution in original post

Georg Pauwen · ‎09-16-2021

Hello,

--> but these tunnels are route-based as opposed to this one which is policy-based

By that, do you mean 'legacy' crypto map based as opposed to VTI ?

Actually, I have seen many, many times that crypto maps (which are considered legacy) do not work, especially on the newer ASR routers; as soon as you use VTIs, everything works fine. So that might be the first thing you want to try...

jonathanw84 · ‎09-16-2021

Hi Georg,

Thanks for the response. You correct - this configuration is using a crypto map as opposed to VTI. We have other IPSEC tunnels on this same router using VTIs and these are working as expected. You may be on to something...

I've also opened up a TAC case for assistance. Not sure why this vendor only supports such a legacy configuration...

Richard Burts · ‎09-16-2021

The partial config that was posted looks appropriate. Can you verify with the remote peer the use of pfs group14?

If phase 1 is completing that means that the ISAKMP negotiation is working and suggests that there is some mismatch in the ipsec parameters. One alternative way to investigate would be to run debug for ipsec for that remote peer and to post the output.

HTH

Rick

jonathanw84 · ‎09-16-2021

Thanks Richard. I have tried to debug ipsec and I get no output, almost as if the router isn't even attempting to do anything with the traffic. Debugging isakmp works just fine and I can see that Phase 1 is established with no issue. I have confirmed using monitor capture that the traffic is indeed making it to the router with the correct destination as well:
LAS-CCR02-1001X-I-B1F1R03.06-20#show monitor capture TEST buffer detailed
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 74 0.000000 10.80.1.247 -> 10.223.251.55 0 BE TCP
0000: CC7F7648 1381B40C 25E04010 08004500 ..vH....%.@...E.
0010: 003C846F 00003D06 E6EF0A50 01F70ADF .<.o..=....P....
0020: FB37E823 01BB8B73 BA2D0000 0000A002 .7.#...s.-......
0030: 4000BEA6 00000204 02180103 03000101 @...............

1 74 0.000000 10.80.1.247 -> 10.223.251.55 0 BE TCP
0000: B40C25E0 4010CC7F 76481381 08004500 ..%.@...vH....E.
0010: 003C846F 00003C06 E7EF0A50 01F70ADF .<.o..<....P....
0020: FB37E823 01BB8B73 BA2D0000 0000A002 .7.#...s.-......
0030: 4000BEA6 00000204 02180103 03000101 @...............

jonathanw84 · ‎09-16-2021

Thanks Richard. I have tried to debug ipsec and I get no output, almost as if the router isn’t even attempting to do anything with the traffic. Debugging isakmp works just fine and I can see that Phase 1 is established with no issue. I have confirmed using monitor capture that the traffic is indeed making it to the router with the correct destination as well:

LAS-CCR02-1001X-I-B1F1R03.06-20#show monitor capture TEST buffer detailed

----------------------------------------------------------------------------

# size timestamp source destination dscp protocol

----------------------------------------------------------------------------

0 74 0.000000 10.80.1.247 -> 10.223.251.55 0 BE TCP

0000: CC7F7648 1381B40C 25E04010 08004500 ..vH....%.@...E.

0010: 003C846F 00003D06 E6EF0A50 01F70ADF .<.o..=....P....

0020: FB37E823 01BB8B73 BA2D0000 0000A002 .7.#...s.-......

0030: 4000BEA6 00000204 02180103 03000101 @...............

1 74 0.000000 10.80.1.247 -> 10.223.251.55 0 BE TCP

0000: B40C25E0 4010CC7F 76481381 08004500 ..%.@...vH....E.

0010: 003C846F 00003C06 E7EF0A50 01F70ADF .<.o..<....P....

0020: FB37E823 01BB8B73 BA2D0000 0000A002 .7.#...s.-......

0030: 4000BEA6 00000204 02180103 03000101 @...............

Georg Pauwen · ‎09-16-2021

Hello,

just in case, can you post the full running config ? Maybe we can spot something...

jonathanw84 · ‎09-17-2021

Hi Georg,

I would but there is a lot of information there I would have to parse through and block out. Is there a particular section you're interested in?

Thanks!

Rob Ingram · ‎09-16-2021

@jonathanw84

You've defined an isakmp profile, but in your configuration you've not referenced this under the crypto map - i.e.

crypto map TUNNEL-DEV 10 ipsec-isakmp
 set isakmp-profile TUNNEL-DEV

jonathanw84 · ‎09-17-2021

Hi Rob,

I have tried to add that with no luck. My understanding is that command is not necessary - both the configuration generated from the peer and what I've experienced I've never had to define that under the crypto map. I could very well be wrong though

Thanks!

jonathanw84 · ‎09-20-2021

Update on this. TAC was able to verify that SHA2 does not work for Phase II on the ISR 1001X platform and recommended moving to SHA1 for the transform set. We made this change on both ends and the tunnel is up, but we can only get the first line of the ACL used for the encryption domain to establish an SA on Phase II. Everything is down despite other traffic being generated on other networks. Any suggestions?

Thanks all!

Georg Pauwen · ‎09-20-2021

Hello,

try and make the access list numbered instead of named:

access-list 101 permit ip host 10.80.158.90 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.80.164.90 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.80.158.46 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.80.164.29 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.40.39.53 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.40.39.54 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.40.39.55 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.40.39.50 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.40.39.51 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.40.39.52 10.223.251.0 0.0.0.255
access-list 101 permit ip host 10.40.39.56 10.223.251.0 0.0.0.255
access-list 101 permit ip 10.80.0.0 0.0.1.255 10.223.251.0 0.0.0.255
!
crypto keyring TUNNEL-DEV
local-address 111.111.111.111
pre-shared-key address 44.X.X.X key BLAHBLAHBLAH
exit
!
crypto isakmp policy 10
encr aes 256
hash sha256
authentication pre-share
group 14
lifetime 28800
!
crypto isakmp profile TUNNEL-DEV
keyring TUNNEL-DEV
match identity address 44.X.X.X 255.255.255.255
local-address 111.111.111.111
!
crypto ipsec transform-set TUNNEL-DEV esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto map TUNNEL-DEV 10 ipsec-isakmp
match address 101
set peer 44.X.X.X
set transform-set TUNNEL-DEV
set pfs group14
set security-association lifetime second 3600
!
interface TenGigabitEthernet0/0/0
crypto map TUNNEL-DEV

jonathanw84 · ‎09-20-2021

Thanks Goerg. I gave that a shot and same issue. Only 10.80.158.90 establishes an SA. The rest are down.

Georg Pauwen · ‎09-20-2021

Hello,

does the other side match this access list exactly ?

jonathanw84 · ‎09-20-2021

Hi Georg,

They say it does. The cut config that their Aviatrix gateway provides specific to the ASR has the networks listed like that for me, so I'm assuming they do have it in place.