Site to Site vpn stuck in IKE Phase 1 - MM_WAIT_MSG2

[esa_fresa]

We're doing a site to site vpn. The tunnel has worked before but after some maintenance on the ASA_Receiving location(no config changes to asa made, this asa is directly attached to the internet) the tunnel won't come back up. The devices can ping each other without an issue.

This is an L2L vpn, I'm wondering if the type saying user is related to the issue?

ASA_Initiator

IKE Peer: 71.13.xxx.xxx
    Type    : user            Role    : initiator
    Rekey   : no              State   : MM_WAIT_MSG2

ASA_Receiving

# show crypto isakmp sa

There are no isakmp sas

[pjain2 · Accepted solution]

Hey,

is the remote end ASA as well?

If so, apply the below captures on both the ASA's:

capture capout interface <outside interface name> match udp host <local public ip> host <remote public ip>

The tunnel gets stuck on MM_WAIT_MSG2 for 2 reasons:

1. either an issue with the phase1 policies on the remote end or

2. UDP 500 is not reaching the remote end or the remote end is sending the UDP 500 packet back and is not reaching the local ASA. 

Regards

[esa_fresa]

The remote end is an ASA as well. The ASA_Receiving output shown is from it. The "There are no isakmp sas" message means that the receiving ASA isn't even receiving the first setup message, right?

I'll send the capout output when I get the chance.

[pjain2]

yeah but the more accurate way to verify if the udp 500 packet is coming to ASA or not is by applying captures.

[esa_fresa]

I ran the captures. The receiving ASA_Receiving wasn't getting any udp packets, as expected, however the ASA_Initiator was only sending udp packets on port 364, not on 500. 

1: 15:08:16.675334       802.1Q vlan#989 P0 199.48.156.xx.xx > 71.13.171.xx.xx:  udp 364

2: 15:08:24.914061       802.1Q vlan#989 P0 199.48.156.xxx.xxx > 71.13.171.xxx.xxx:  udp 364

 etc... more of the same

[pjain2]

udp 364 is the packet size of 365.

the port number will be seen like this:

1.1.1.1:500>2.2.2.2:500

do you see port 500 in the initiator's capture?

[esa_fresa]

Yes I do, so the packets aren't making it to the other side. That's all I need, thanks for your help!

[esa_fresa]

edit: corrected clock, this wasn't the issue

[grodriguez7]

Was the clock being out of synch the issue? I am having the exact same problem as described.

[esa_fresa]

If I remember correctly, this specific issue turned out to be an inbetween Palo Alto device that was sending the setup packets out the wrong interface due to a bug.

More often though when we have this issue where pings are successful but udp 500 isn't received, it's been due to either a misconfigured peer address or an acl blocking the packets.

I hope this helps!

On a side note, I'm laughing at myself looking back at this post. I've learned so much since then!

[grodriguez7]

Thanks for the reply.

  Yeah, this one has me scratching my head, it worked for months up until a couple days ago. The tunnel is stuck in the MM_WAIT_MS2 phase, nothing was changed on either side.

[suneel.waqas]

Hello dear,

what was the solution if it stuck in MM_WAIT_MS2. please share your finding if problem is resloved.

[15109821628]

I also encountered a similar question, and have been stuck in Rekey: no State: MM_WAIT_MSG2
stage, how to solve it?