VPN and CA - %CRYPTO-4-IKMP_BAD_MESSAGE

d-garnett · ‎12-06-2005

Hello all,

I was testing out VPN with Certificate Authority and it seems that the renew date on my certs (once recieved by the IOS Router) always time warp backward.

Validity Date:

start date: 10:02:26 PST Dec 6 2005

end date: 10:12:26 PST Dec 6 2006

renew date: 16:00:00 PST Dec 31 1969

Associated Trustpoints: CA

After I enroll via SCEP and the routers get the certs, everything is ok as far as IKE Phase 1, 2 negotiation, and data transfer over the VPN is concerned. But after I reboot the devices and reset the clock the IKE Phase 1 fails and I can no longer establish VPN connectivity.

The following appears in the debugs

Initiator:

Dec 6 20:35:45.339: ISAKMP (0:11): Old State = IKE_I_MM6 New State = IKE_I_MM6

Dec 6 20:35:45.343: ISAKMP: reserved not zero on ID payload!

Dec 6 20:35:45.343: -Traceback= 61E91CDC 61E91E48 61E85A60 61E87AA8 61EAA84C 61EAC614 61FF7F68 61EAEB94 61EAE9E4 61E89530 61E899F8

Dec 6 20:35:45.343: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 192.168.211.1 failed its sanity check or is malformed

Responder:

Dec 6 20:36:44.099: ISAKMP: reserved not zero on ID payload!

Dec 6 20:36:44.099: -Traceback= 61E91CDC 61E91E48 61E8875C 61E89B10

Dec 6 20:36:44.099: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 192.168.211.2 failed its sanity check or is malformed

Dec 6 20:36:44.099: ISKAMP: growing send buffer from 1024 to 3072

Dec 6 20:36:44.099: ISAKMP (0:2): incrementing error counter on sa: PAYLOAD_MALFORMED

gfullage · ‎12-06-2005

The renew date issue is a cosmetic bug I believe, basically unless you have configured auto-enrollment then the renew date is meaningless and so it just shows up as a bogus date. See http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee78279&Submit=Search for details.

Now, what do you mean by "But after I reboot the devices and reset the clock..."? If you're using certificates you should definately be configuring NTP on your routers also, so they boot up with the correct time. I have had issues in the past with changing the time after a reboot.

Also, can you send through the "debug cry pki trans" and "debug cry pki mess" output from both sides, that may give us more information on what's going on.