Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > MM_KEY_EXCH never completes. Bad password? Anything else?

Reply
Thread Tools

MM_KEY_EXCH never completes. Bad password? Anything else?

 
 
professorguy professorguy is offline
Member
Join Date: Sep 2006
Posts: 39
 
      11-15-2006
I have a vpn tunnel that gets to MM_KEY_EXCH but never comes up. I know this can be casued by a mismatched pre-shared key. But is there anything else that might casue it?

I'm heading out to a remote site to retype a password, but would like to eliminate other possibilities before making this pilgrimage.

Here's what the near exchange looks like:

================= output from vpn appliance ========================
crypto_isakmp_process_block:src:64.zzz.yyy.xxx, dest:24.zzz.yyy.xxx
spt:500 dpt:500
OAK_MM exchange
ISAKMP (0): processing SA payload. message ID = 0

ISAKMP (0): Checking ISAKMP transform 1 against priority 20 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 2
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP (0): atts are not acceptable. Next payload is 0
ISAKMP (0): Checking ISAKMP transform 1 against priority 30 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 2
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP (0): atts are not acceptable. Next payload is 0
ISAKMP (0): Checking ISAKMP transform 1 against priority 40 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 2
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP (0): atts are acceptable. Next payload is 0
ISAKMP (0): SA is doing pre-shared key authentication using id type
ID_IPV4_ADDR
return status is IKMP_NO_ERROR
================================================== ==================

Notice that it found matching policies and there was no error. Then
Phase 2 begins:

================= output from vpn appliance ========================
crypto_isakmp_process_block:src:64.zzz.yyy.xxx, dest:24.zzz.yyy.xxx
spt:500 dpt:500
OAK_MM exchange
ISAKMP (0): processing KE payload. message ID = 0

ISAKMP (0): processing NONCE payload. message ID = 0

ISAKMP (0): processing vendor id payload

ISAKMP (0): received xauth v6 vendor id

ISAKMP (0): processing vendor id payload

ISAKMP (0): remote peer supports dead peer detection

ISAKMP (0): processing vendor id payload

ISAKMP (0): processing vendor id payload

ISAKMP (0): speaking to another IOS box!

ISAKMP (0): ID payload
next-payload : 8
type : 1
protocol : 17
port : 0
length : 8
ISAKMP (0): Total payload length: 12
return status is IKMP_NO_ERROR
================================================== ==================

Notice it talked to the peer and even noticed it was another cisco
firewall (IOS box). The key exchange gets going:

================================================== ==================
Cisco# sho isakmp sa
Total : 5
Embryonic : 1
dst src state pending created
64.zzz.yyy.xxx 24.zzz.yyy.xxx MM_SA_SETUP 0 0
xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx QM_IDLE 0 2
xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx QM_IDLE 0 1
....
Cisco# sho isakmp sa
Total : 5
Embryonic : 1
dst src state pending created
64.zzz.yyy.xxx 24.zzz.yyy.xxx MM_KEY_EXCH 0 0
xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx QM_IDLE 0 2
xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx QM_IDLE 0 1
....
================================================== ==================

But the key exchange never completes. Eventually the reaper cleans up
the connection.
 
Reply With Quote
 
 
 
 
professorguy professorguy is offline
Member
Join Date: Sep 2006
Posts: 39
 
      11-16-2006
I turned on 'logging debug' on our vpn appliance (a PIX). Looks like the remote peer won't acknowledge our tunnel request.

The interesting traffic is recognized. The NAT addresses (proxies) are correct:

2006-11-15 16:34:10 Local0.Info X.Y.Z.2 %PIX-6-302013: Built outbound TCP connection 22034 for outside:10.232.A.B/9999 (10.232.A.B/9999) to inside:X.Y.Z.247/1138 (10.232.C.D/113

The tunnel is constructed:

2006-11-15 16:34:10 Local0.Debug X.Y.Z.2 %PIX-7-702303: sa_request, (key eng. msg.) src= <mypeer_ip>, dest= <theirpeer_ip>, src_proxy= 10.232.C.D/255.255.255.255/0/0 (type=1), dest_proxy= 10.232.A.B/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 28800s and 4608000kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4004

But dies after 2 minutes without a SYN ACK:

2006-11-15 16:36:12 Local0.Info X.Y.Z.2 %PIX-6-302014: Teardown TCP connection 22034 for outside:10.232.A.B/9999 to inside:X.Y.Z.247/1138 duration 0:02:01 bytes 0 SYN Timeout
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
integer >= 1 == True and integer.0 == False is bad, bad, bad!!! rantingrick Python 44 07-13-2010 06:33 PM
Bad media, bad files or bad Nero? John Computer Information 23 01-08-2008 09:17 PM
ActiveX apologetic Larry Seltzer... "Sun paid for malicious ActiveX code, and Firefox is bad, bad bad baad. please use ActiveX, it's secure and nice!" (ok, the last part is irony on my part) fernando.cassia@gmail.com Java 0 04-16-2005 10:05 PM
24 Season 3 Bad Bad Bad (Spoiler) nospam@nospam.com DVD Video 12 02-23-2005 03:28 AM
24 Season 3 Bad Bad Bad (Spoiler) nospam@nospam.com DVD Video 0 02-19-2005 01:10 AM



Advertisments