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

New ASA to Azure site-to-site VPN failing to connect

aok
Level 1
Level 1

Hello

 

We are trying to establish a new IPSec connection from a Cisco ASA to Azure. The Azure side is receiving an IKE Main Mode Expired error:

 

Received packet

Process Payload OAK NOTIFY/DELETE, SA 000000CA29290EE0

Received MM delete

Cleaning up mmSa: 000000CA29290EE0. Error 13885(ERROR_IPSEC_IKE_MM_EXPIRED)

QM done. Cleaning up qmSa 000000CA29294DF0.  Error 13885(ERROR_IPSEC_IKE_MM_EXPIRED)

Deleting QM.  MM: 000000CA29290EE0 QM: 000000CA29294DF0

Moving mmSa 000000CA29290EE0 to zombie list

Deleting MM from lists: 000000CA29290EE0

 

Microsoft advised that for Phase 1, the lifetime should be 28,800 seconds and for Phase 2 the lifetime has to be 3,600 seconds and 102,400,000 KB.

 

The only potential discrepancy I see is that the priority value associated with the crypto map doesn't have an entry in the IKEv2 policy with the same priority value. I've attached screenshots of what I'm referring to, it's the second crypto map connection with priority 2 that isn't working. Priorities 1 and 10 are working. My question is, do these priority values need to match or are they completely unrelated? If unrelated, anything else we should check?

 

Thanks

A

 

1 Accepted Solution

Accepted Solutions

Turns out the problem was that the subnet mask for the ASA side local network was different on both ends of the connection. We deleted the local network gateway and connection in Azure then recreated it with the same mask and all is working now. Thanks JP for your help narrowing down the issue.

 

A

View solution in original post

5 Replies 5

JP Miranda Z
Cisco Employee
Cisco Employee

Hi akomili,

 

The priority is completely unrelated, if you are completely sure all the setting are matching the Azure you can try the following debugs on the ASA:

 

-debug cry condition peer <azurepublicip>

-debug cry ikev2 protocol 120

 

Without those debugs you can see from the ASA perspective why the tunnel is not coming up. You can also share the debugs if you are not finding anything so i can give you a hand.

Keep in mind you can download the config template for ASA from Azure and make sure everything is matching since normally as long as you follow their template the tunnel will come up.

 

Hope this info helps!!

 

Rate if helps you!! 

 

-JP- 

Hi JP

 

I turned on the first debug command you suggested but I'm not seeing any output. Tried resetting the connection from the Azure side but still no results. We don't have IKEv2 turned on for this, only IKEv1.

 

Where would I find the config template?

 

Thanks

A

akomili,

I definitely understand, just to explain you a little bit, the first debug only creates a condition to get debugs from the specified peer, the 2nd debugs is the one that will give you outputs, i guess i got confused with ikev2 being mentioned at some point, you can run the following debugs:

debug cry condition peer <azurepublicip>
debug cry isa 180

The config template can be downloaded from the Azure site:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-download-vpndevicescript

Hope this info helps!!

Rate if helps you!!

-JP-

Hi JP

 

The second debug command isn't available. These are the options:

 

# debug crypto ?

ca                        Set PKI debug levels
condition              Set IPSec/ISAKMP debug filters
engine                  Set crypto engine debug levels
ike-common         Set IKE common debug levels
ikev1                     Set IKEV1 debug levels
ikev2                     Set IKEV2 debug levels
ipsec                     Set IPSec debug levels
ss-api                   Set Crypto Secure Socket API debug levels
vpnclient               Set EasyVPN client debug levels

 

I had a look at those scripts but unfortunately none of them match what we're doing as we're using IKEv1 and policy-based instead of route-based. We are on ASA version 9.1(7)

 

Thanks

A

Turns out the problem was that the subnet mask for the ASA side local network was different on both ends of the connection. We deleted the local network gateway and connection in Azure then recreated it with the same mask and all is working now. Thanks JP for your help narrowing down the issue.

 

A