ISAKMP debug output

[kpong]

Dear all,

I have configured a buildin l2tp/ipsec WinXp to connect to IOS vpn router. The WinXp can only pass the IKE phase 1 negotiation but always failed in IKE phase 2 negotiation.

Does someone could tell me what is meaning of the following ISAKMP debug message and what is "encaps is 2" ?

Mar 4 17:24:08 HKT: ISAKMP: transform 1, ESP_DES

Mar 4 17:24:08 HKT: ISAKMP: attributes in transform:

Mar 4 17:24:08 HKT: ISAKMP: encaps is 2

Mar 4 17:24:08 HKT: ISAKMP: authenticator is HMAC-MD5

Mar 4 17:24:08 HKT: validate proposal 0

Mar 4 17:24:08 HKT: ISAKMP (0:3): atts not acceptable. Next payload is 0

Mar 4 17:24:08 HKT: ISAKMP (0:3): phase 2 SA not acceptable!

I have also tried to use the VPN client to connect to same IOS VPN router. It can success in both IKE phase 1 and 2 negotiation. I found the only difference between the debug output message of VPN client and WinXp build-in VPN client is the encaps number and position in the transform output.

Here is the debug output of VPN client to IOS vpn router.

Mar 4 17:22:49 HKT: ISAKMP (0:4): processing SA payload. message ID = 282672330

Mar 4 17:22:49 HKT: ISAKMP (0:4): Checking IPSec proposal 1

Mar 4 17:22:49 HKT: ISAKMP: transform 1, ESP_DES

Mar 4 17:22:49 HKT: ISAKMP: attributes in transform:

Mar 4 17:22:49 HKT: ISAKMP: authenticator is HMAC-MD5

Mar 4 17:22:49 HKT: ISAKMP: encaps is 1

Mar 4 17:22:49 HKT: validate proposal 0

Mar 4 17:22:49 HKT: ISAKMP (0:4): atts are acceptable.

Thanks in advance.

[ciscomoderator]

Often times complex troubleshooting issues are best addressed in an interactive session with one of our trained technical assistance engineers. While other forum users may be able to help, it’s often difficult to do so for this type of issue.

To utilize the resources at our Technical Assistance Center, please visit http://www.cisco.com/tac and to open a case with one of our TAC engineers, visit http://www.cisco.com/tac/caseopen

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

[NetTech24]

Straigh from the Cisco site:

The following output is an IKE negotiation failure between SJVPN and SJhub when the OU fields don't match. As you can see from the debugs collected on SJhub, IKE authentication in the phase I negotiation was still successful after certificate validation and CRL checking; howerver, during QM negotiation, when the settings in the crypto map are checked, due to the DN mismatch between the crypto identity set on the SJhub and the ISAKMP identity sent by the SJVPN, QM negotiation failed.

[cjacinto]

Looks like you configured your 2000 machine to use AH instead of ESP. See the sample config on:

http://www.cisco.com/warp/customer/707/2000.html