MM_WAIT_MSG6 between 2 ASA

Alejandro Moran · ‎04-30-2013

Hi

We are in the process of migrating from a juniper to a Cisco ASA, there are some L2L tunnels to other ASA's and with one of them, we are stuck with the MM_WAIT_MSG6 state:

1 IKE Peer: 200.57.91.174

Type : L2L Role : initiator

Rekey : no State : MM_WAIT_MSG6

We have checked the pre-share keys and config several times, unfortunately we dont have access to the remote side, but they shared with us the configuration, and its basically the same....

our side:

access-list vpn_SandC extended permit ip host a.b.c.d host x.x.x.x

access-list vpn_SandC extended permit ip host a.b.c.d host x.x.x.y

crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map OUTSIDE_MAP 30 match address vpn_SandC

crypto map OUTSIDE_MAP 30 set pfs

crypto map OUTSIDE_MAP 30 set peer 200.57.91.174

crypto map OUTSIDE_MAP 30 set ikev1 transform-set ESP-3DES-MD5

crypto ikev1 policy 10

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 28800

tunnel-group 200.57.91.174 type ipsec-l2l

tunnel-group 200.57.91.174 ipsec-attributes

ikev1 pre-shared-key <xxxxxxxxx>

remote side:

access-list cajanicolas extended permit ip host x.x.x.x host a.b.c.d

access-list cajanicolas extended permit ip host x.x.x.y host a.b.c.d

crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map outside_map 20 match address cajanicolas

crypto map outside_map 20 set pfs

crypto map outside_map 20 set peer 201.147.38.18

crypto map outside_map 20 set ikev1 transform-set ESP-3DES-MD5

crypto ikev1 policy 5

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 28800

group-policy cajanicolas internal

group-policy cajanicolas attributes

vpn-filter value cajanicolasPolicy

tunnel-group 201.147.38.18 type ipsec-l2l

tunnel-group 201.147.38.18 general-attributes
default-group-policy cajanicolas
tunnel-group 201.147.38.18 ipsec-attributes
ikev1 pre-shared-key <xxxxxxxx>

The only difference I spot is that the remote side is adding a group policy for the tunnel, with a vpn filter. other than that phase1 and 2 are the same. does the group-policy could be affecting us?

running the isakmp debugs I get this:

Apr 29 18:44:44 [IKEv1]IP = 200.57.91.174, IKE Initiator: New Phase 1, Intf inside, IKE Peer 200.57.91.174 local Proxy Address 198.8.1.2, remote Proxy Address 200.15.1.143, Crypto map (OUTSIDE_MAP)

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing ISAKMP SA payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing NAT-Traversal VID ver 02 payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing NAT-Traversal VID ver 03 payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing NAT-Traversal VID ver RFC payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing Fragmentation VID + extended capabilities payload

Apr 29 18:44:44 [IKEv1]IP = 200.57.91.174, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 240

Apr 29 18:44:44 [IKEv1]IP = 200.57.91.174, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + NONE (0) total length : 80

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing SA payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Oakley proposal is acceptable

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing ke payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing nonce payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing Cisco Unity VID payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing xauth V6 VID payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Send IOS VID

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, constructing VID payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Send Altiga/Cisco VPN3000/Cisco ASA GW VID

Apr 29 18:44:44 [IKEv1]IP = 200.57.91.174, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 256

Apr 29 18:44:44 [IKEv1]IP = 200.57.91.174, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 256

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing ke payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing ISA_KE payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing nonce payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing VID payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Received xauth V6 VID

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing VID payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Received DPD VID

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing VID payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Received Cisco Unity client VID

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, processing VID payload

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Processing IOS/PIX Vendor ID payload (version: 1.0.0, capabilities: 00000025)

Apr 29 18:44:44 [IKEv1]IP = 200.57.91.174, Connection landed on tunnel_group 200.57.91.174

Apr 29 18:44:44 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, Generating keys for Initiator...

Apr 29 18:44:44 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, constructing ID payload

Apr 29 18:44:44 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, constructing hash payload

Apr 29 18:44:44 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, Computing hash for ISAKMP

Apr 29 18:44:44 [IKEv1 DEBUG]IP = 200.57.91.174, Constructing IOS keep alive payload: proposal=32767/32767 sec.

Apr 29 18:44:44 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, constructing dpd vid payload

Apr 29 18:44:44 [IKEv1]IP = 200.57.91.174, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + IOS KEEPALIVE (128) + VENDOR (13) + NONE (0) total length : 92

Apr 29 19:23:52 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, IKE MM Initiator FSM error history (struct &0x00007fff2edf6000) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG6, EV_PROB_AUTH_FAIL-->MM_WAIT_MSG6, EV_TIMEOUT-->MM_WAIT_MSG6, NullEvent-->MM_SND_MSG5, EV_SND_MSG-->MM_SND_MSG5, EV_START_TMR-->MM_SND_MSG5, EV_RESEND_MSG-->MM_WAIT_MSG6, EV_TIMEOUT

Apr 29 19:23:52 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, IKE SA MM:7faafcb2 terminating: flags 0x0100c022, refcnt 0, tuncnt 0

Apr 29 19:23:52 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, sending delete/delete with reason message

Apr 29 19:23:52 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, constructing blank hash payload

Apr 29 19:23:52 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, constructing IKE delete payload

Apr 29 19:23:52 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, constructing qm hash payload

Apr 29 19:23:52 [IKEv1]IP = 200.57.91.174, IKE_DECODE SENDING Message (msgid=c6c88b83) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 76

This message is the one telling me there is something wrong on the psk step, retry and then timeouts... but I don see anything that could be the problem...

Apr 29 19:23:52 [IKEv1 DEBUG]Group = 200.57.91.174, IP = 200.57.91.174, IKE MM Initiator FSM error history (struct &0x00007fff2edf6000) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG6, EV_PROB_AUTH_FAIL-->MM_WAIT_MSG6, EV_TIMEOUT-->MM_WAIT_MSG6, NullEvent-->MM_SND_MSG5, EV_SND_MSG-->MM_SND_MSG5, EV_START_TMR-->MM_SND_MSG5, EV_RESEND_MSG-->MM_WAIT_MSG6, EV_TIMEOUT

I got some captures on my side, and is the same, got the retry and then timeouts:

: 18:59:12.881027 201.147.38.18.500 > 200.57.91.174.500: udp 240

2: 18:59:12.916273 200.57.91.174.500 > 201.147.38.18.500: udp 80

3: 18:59:12.916624 201.147.38.18.500 > 200.57.91.174.500: udp 256

4: 18:59:12.953274 200.57.91.174.500 > 201.147.38.18.500: udp 256

5: 18:59:12.954204 201.147.38.18.500 > 200.57.91.174.500: udp 92

6: 18:59:20.949657 201.147.38.18.500 > 200.57.91.174.500: udp 92

7: 18:59:28.949673 201.147.38.18.500 > 200.57.91.174.500: udp 92

8: 18:59:36.949688 201.147.38.18.500 > 200.57.91.174.500: udp 92

Also, I've tried with and without the Nat-t and ipsec-over-tcp...and I get the same result.

any help is much appreciated!

speculatrix · ‎10-15-2013

I have this problem too, only I am trying to get Cisco 55x0 to talk to Strongswan on a linux box.

Oct 15 15:49:20 [IKE COMMON DEBUG]Duplicate entry already in Tunnel Manager

Oct 15 15:35:35 [IKEv1 DEBUG]Group = a.b.c.d, IP = a.b.c.d, IKE MM Initiator FSM error history (struct &0xabd01350) , : MM_DONE, EV_ERROR-->MM_WAIT_MSG6, EV_PROB_AUTH_FAIL-->MM_WAIT_MSG6, EV_TIMEOUT-->MM_WAIT_MSG6, NullEvent-->MM_SND_MSG5, EV_SND_MSG-->MM_SND_MSG5, EV_START_TMR-->MM_SND_MSG5, EV_RESEND_MSG-->MM_WAIT_MSG6, EV_TIMEOUT

Oct 15 15:35:35 [IKEv1 DEBUG]Group = a,b,c,d, IP = a.b.c.d, IKE SA MM:a958084f terminating: flags 0x01008022, refcnt 0, tuncnt 0

Oct 15 15:35:35 [IKEv1 DEBUG]Group = a.b.c.d, IP = a.b.c.d, sending delete/delete with reason message

Oct 15 15:35:35 [IKE COMMON DEBUG]IKEv1 was unsuccessful at setting up a tunnel. Map Tag = outside_map. Map Sequence Number = 8.

Oct 15 15:35:35 [IKE COMMON DEBUG]Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= outside_map. Map Sequence Number = 8.

at the strongswan end I see things I don't expect or hoped not to see which suggests strongswan is blocking stuff.

Oct 15 15:35:03 15[IKE] no peer config found

Oct 15 15:35:03 15[MGR] checkin and destroy IKE_SA (unnamed)[9]

Oct 15 15:35:03 15[IKE] IKE_SA (unnamed)[9] state change: CONNECTING => DESTROYING

Jouni Forss · ‎10-15-2013

Hi,

It would seem to me that a missmatch with PSK might be the reason if it stops with MM_WAIT_MSG6

- Jouni

Patrick Moubarak · ‎10-15-2013

Common issue when copy pasting pre-shared-keys, try something simple first just to make sure it works.

Watch out for spaces and carriage return charater when copy-pasting.

Take a look at this troubleshooting technote:

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml#solution09

Patrick

speculatrix · ‎10-15-2013

I found a note that suggested to disable rekeying on the strongswan side, which I did, this then means that the Cisco controls rekeying.

Oh, I also switched to using IKEv2 form IKEv1.

And it now works.

Of course, I don't know how stable it will be.

ajitp2004 · ‎10-15-2013

Hi,

MM_WAIT_MSG6 is possible in case of PSK mismatch. It is the state of the initiator when PSK is not same on both receiver and initiator. Please do this on both firewalls:

no tunnel-group xxxxxxx ipsec-attributes

and then reconfigure tunnel-group ipsec-attributes with correct PSK on both sides.

Ajit