07-23-2020 03:02 AM
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?
07-23-2020 03:49 AM
07-23-2020 04:13 AM - edited 07-23-2020 04:34 AM
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?
07-23-2020 08:51 AM
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.
07-23-2020 10:40 AM
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.
07-23-2020 11:26 AM
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.
07-23-2020 12:59 PM
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.
07-23-2020 01:12 PM
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.
07-23-2020 02:04 PM
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.
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