IKEv2 IPsec SA Issues only when we are the Responder

[Eric Snijders]

So for the past couple of months we've been building an environment in Azure. With trial & error i've experienced that on the Cisco ASA's side, i need to specify the complete VNet address spaces (we are using 2 address spaces in 1 VNet) in 1 SA (meaning: 1 ACL entry with all our sources and both Azure Address Spaces as destination) to let it work. I'm not really satisfied with this, since this means i'm getting SA's between subnets i dont want.

Yesterday i've started experimenting with it. I created a seperate ACL entry for every SA i wanted. Now this is working fine ONLY when our ASA is the initiator. When the Azure side is initiating, we're not getting any completed SA's.

Now i've tried debugging where it's failing with the following commands:

debug crypto condition peer <AZURE_IP>
debug crypto ikev2 protocol 127
debug crypto ipsec 127

But i must say i'm not really sure what to look for. I tried looking for what Azure is actually offering in 1 SA, meaning: what subnets/networks are they offering and what are they expecting, but i can't find it. The only reasonable information i see somewhere between all the lines, is:

IKEv2-PROTO-4: (518): Processing IKE_AUTH message
IKEv2-PROTO-7: (518): Failed to verify the proposed policies
IKEv2-PROTO-2: (518): There was no IPSEC policy found for received TS

I'm not seeing any differences in IKEv2 SA's between responding or initiating. So how could i troubleshoot this?

[Rob Ingram]

Hi,
Has one device got PFS (Perfect Forward Secrecy) configured and not the other?

[Eric Snijders]

I had PFS configured on my ASA. I just stripped it off, but still the same issue. When "we" (e.g.: the ASA) initiates everything goes fine. When Azure initiates i'm getting issues.

I've also enabled IKEv2 Platform debugging, and just before the earlier error i'm seeing this:

IKEv2-PLAT-4: (498): Crypto Map: No proxy match on map AZURE-LSP-MAP seq 1
IKEv2-PLAT-4: (498): Crypto map AZURE-LSP-MAP seq 2  peer doesn't match map entry

It's still weird to me why this would only work one way. Because even though we have 2 different address spaces in our Azure environment, i dont want established SA's between subnets who aren't even supposed to be communicating. Is there any way i can find out exactly WHAT the SA offer is regarding the interesting traffic?

[Sheraz.Salim]

so your formed a phase 1 but your phase 2 does not coming up.

could you debug crypto condition peer x.x.x.x and debug crypto ipsec 127 and show us the debugs. also could you please share your configuration too.

[Eric Snijders]

Hi Sheraz,

Yes, Phase1 forms just fine. Phase 2 only works when "our" side (ASA) initiates the session. I've just found this article, describing the cyphers used by Azure when responding or initiating: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#RouteBasedOffers

On Azure's side, i've just created a IPsec Policy with the following settings:

--dh-group DHGroup24 
--ike-encryption AES256 
--ike-integrity SHA384 
--ipsec-encryption AES256 
--ipsec-integrity SHA256 
--pfs-group None 
--sa-lifetime 7200 
--sa-max-size 1024

On the ASA's side i've made a new IPsec Transform set and applied it on the crypto map:

crypto ipsec ikev2 ipsec-proposal AZU_MITZ
 protocol esp encryption aes-256
 protocol esp integrity sha-256

crypto map AZURE-LSP-MAP 1 match address S2S_AZURE_MITZ
crypto map AZURE-LSP-MAP 1 set peer AZURE_WAN
crypto map AZURE-LSP-MAP 1 set ikev2 ipsec-proposal AZU_MITZ
crypto map AZURE-LSP-MAP 1 set security-association lifetime seconds 7200
crypto map AZURE-LSP-MAP 1 set security-association lifetime kilobytes unlimited

access-list S2S_AZURE_MITZ line 1 extended permit ip 192.168.252.0 255.255.255.192 10.168.50.0 255.255.255.0 (hitcnt=505) 0x5c44df77
access-list S2S_AZURE_MITZ line 2 extended permit ip 172.24.0.0 255.255.0.0 10.0.3.0 255.255.255.0 (hitcnt=18) 0x197e40eb

I verified that Phase 1 is forming fine, even with the new settings in Azure:

IKEv2 SAs:

Session-id:1674, Status:UP-IDLE, IKE count:1, CHILD count:0

Tunnel-id Local                                               Remote                                                  Status         Role
491260539 LOCAL_WAN/500                                     AZURE_WAN/500                                       READY    RESPONDER
      Encr: AES-CBC, keysize: 256, Hash: SHA384, DH Grp:24, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/13 sec

Attached you'll find the output of the debugs after clearing the Phase 1 SA and initiating it from Azure's side.
And even after all these changes: when i initiate the tunnel everything is working fine. I just hope that having 1 VNet with multiple address spaces doesnt mean i need to have every subnet cross-connect with SA's, cause that's definitely something we're trying to avoid.

[Sheraz.Salim]

I had a good look in your debug and spotted the same issue with you mentioned earlier in your post

IKEv2-PLAT-4: (60): Crypto Map: No proxy match on map AZURE-LSP-MAP seq 1
IKEv2-PLAT-4: (60): Crypto map AZURE-LSP-MAP seq 2 peer doesn't match map entry

both side not use PSF values. does your remote side have a same access-list 

access-list S2S_AZURE_MITZ line 1 extended permit ip 192.168.252.0 255.255.255.192 10.168.50.0 255.255.255.0 (hitcnt=505) 0x5c44df77
access-list S2S_AZURE_MITZ line 2 extended permit ip 172.24.0.0 255.255.0.0 10.0.3.0 255.255.255.0 (hitcnt=18) 0x197e40eb

if ASA is the initiator your phase 2 come up but when your remote side initiate  your tunnel does not come up.

could you run again some debug in this order

capture VPN1 trace isakmp interface outside match ip host a.a.a.a host b.b.b.b
!
capture VPN2 trace isakmp interface outside match ip host b.b.b.b host a.a.a.a
!
debug crypto condition peer b.b.b.b
!
debug crypto ipsec 127
!
debug crypto ikev2 proto 127
!
debug crypto ikev2 platform 127
!
logging buffered debugging
!
logging buffer-size 20565874
Note: * a.a.a.a is your source outside and b.b.b.b is your remote peer ip address

I want to see what packet you get when your remote is the initiator.

[Eric Snijders]

Both side not use PFS values. does your remote side have a same access-list 

Yes, PFS is not used. It's a VPN Tunnel between a Cisco ASA and Microsoft Azure. Unfortunately, i cannot statically specify a source within Azure. You can only configure the "remote subnets".

How can i securely share the PCAP's with you? I'm not sure if it's safe to drop isakmp PCAP's including WAN IP's straight in this thread.

[Sheraz.Salim]

oh yes. i forget that its a security risk to share this information. I guess if you have a TAC support open a case with cisco or with any other provider.

[Eric Snijders]

I can share some details with you:

Yellow = Azure WAN
Blue = Cisco WAN

I'm not really sure what i'm looking for, but interesting to me looks packet #9, which has the "Traffic Selector - Initiator" and "Traffic Selector - Responder" headers, looking like this:

So this is the offer coming from Azure WAN, when Phase 2 is not being established.