Phase 1 Negotiation Problems

[ryandibble]

Hi everybody,

I'm working on creating a tunnel between an ASA 5505 and a box running Check Point NG/AI. I've set up a couple of other Cisco to Check Point tunnels with this same Check Point peer without any problems. This time however, a SA is never created and I get the following when I debug ISAKMP on the ASA:

Dec 19 03:48:14 [IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Received an un-encrypted PAYLOAD_MALFORMED notify message, dropping

Dec 19 03:48:14 [IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Error, peer has indicated that something is wrong with our message. This could indicate a pre-shared key mismatch.

Dec 19 03:48:14 [IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Information Exchange processing failed

The pre-shared key is not mismatched. Does anybody have any ideas as to what else I might check?

Thanks in advance,

Ryan

[JORGE RODRIGUEZ]

Hi Ryan, looking at this message seems you are hitting the peer , can you confirm this? check your Ike policies which is part of Phase-1 isakmp sa configuration , and that these policies do match the other end. . Pase-2 would be Ipsec sa configuration.

Ike policies entails the following , and make sure these policies do agree at both ends so that Phase-1 is complete to be processed by phase-2

a-Encryption type 3des,aes-128 , aes-192 etc..

b-DH Group=1,2,5 and 7 most commonly used is 2

c-Authentication type pre-share, or rsa-sig

d-Hash type =sha, md5

e-Ike authentication :pre-shared key(this MUST match at both ends )

If still problems let us know, we may need to turn on some debugging

Rgds

Jorge

[ryandibble]

Jorge,

Everything matches on both ends. This tunnel was up on Friday, then went down sometime over the weekend and now it doesn't seem to want to come back up.

For what it's worth we're using:

AES-256

SHA

DH Group 5

Pre-shared auth with a confirmed matching key

Lifetimes of 86400

I can post whatever debugs you think would be helpful. Thanks.

[JORGE RODRIGUEZ]

Are you completely sure nothing has changed on either end on anything pertaining to configuration, tunnels don't just go down unless something had changed on either end.

If you could post output of "debug crypto isakmp " and sent interesting traffic to try bringing the tunnel up..

as usual with debugs you may want to do it after business hours if asa is currently in production.

Jorge

[ryandibble]

The Check Point engineer on the other end swears that nothing has changed. We verified the ISAKMP settings (again) immediately prior to my last post.

I agree that tunnels don't usually go down on their own - that's why this is so perplexing. Here's the debug output:

Dec 19 10:13:45 [IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Removing peer from peer table failed, no match!

Dec 19 10:13:45 [IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Error: Unable to remove PeerTblEntry

Dec 19 10:13:49 [IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Error, peer has indicated that something is wrong with our message. This could indicate a pre-shared key mismatch.

Dec 19 10:13:49 [IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Information Exchange processing failed

There's not much more than what I already posted earlier, so I stepped it up a notch to debug level 10 and attached the relevant output to this post.

Thanks for your help.

-Ryan

[JORGE RODRIGUEZ]

Ryan, you are correct in original post. The sa fails processing,I do not see anything indicating key matching or found peers. Have you guys try changing the keys for sake of trying different pre share key, what version code are you running.

[IKEv1 DEBUG]: Group = x.x.7.225, IP = x.x.7.225, Generating keys for Initiator...

[IKEv1 DEBUG]: Group = x.x.7.225, IP = x.x.7.225, constructing ID payload

[IKEv1 DEBUG]: Group = x.x.7.225, IP = x.x.7.225, constructing hash payload

[IKEv1 DEBUG]: Group = x.x.7.225, IP = x.x.7.225, Computing hash for ISAKMP

[IKEv1 DEBUG]: Group = x.x.7.225, IP = x.x.7.225, constructing dpd vid payload

[IKEv1]: IP = x.x.7.225, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + VENDOR (13) + NONE (0) total length : 84

[IKEv1]: IP = x.x.7.225, IKE_DECODE RECEIVED Message (msgid=a3377722) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 40

[IKEv1]: IP = x.x.7.225, IKE_DECODE RECEIVED Message (msgid=a3377722) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 40

[IKEv1]: Group = x.x.7.225, IP = x.x.7.225, Received an un-encrypted PAYLOAD_MALFORMED notify message, dropping

[dodgerfan78]

try rebooting both boxes, I have read something about IKE cookies...maybe this is your problem

[JORGE RODRIGUEZ]

The fail occors once ASA receives the data from checkpoint which is probably failing in sending outbount encryted data and asa does the job to drop it, so I think this could be a checkpoint issue more than the ASA, this is just a thought ..

Rgds

Jorge

[ryandibble]

Well, the issue is solved. And, I'm embarrased to say, it was a mismatched key after all. The fellow on the Check Point end had evidently re-entered the key sometime after the tunnel had origanlly come up, and mistyped it. Even though he was reading back to me the correct key, the key that was actually on the box was one character off.

I've fat-fingered my share of long, complex ISAKMP keys before, so it's all good. At any rate, problem solved! As always, thanks for your help, guys.

[ryandibble]

I'm running 7.2(2).

I just reloaded the ASA, and there's been no change. The Check Point box holds a key position in our production environment, so it cannot be rebooted during business hours. We may rebuild the Check Point config to see if that works.

If anybody has any other ideas, I'm eager to hear 'em. Thanks for you help thus far.

[JORGE RODRIGUEZ]

Ryan, are you saying that after the checkpoint engineer corrected the key the problem was solved ? then why you had to reboot the ASA.. please explain the update.. is the tunnel up or not.

If the problem still exists I would recommend to rebuild the tunnel from the check point side and test, at this point I don't think is the ASA having issues. A reboot would be a last resourt thing but on the checkpoint side and that would be if you have exausted all other options.

Also don't forget to use rating system to contribute on anyone's help this encouranges to even help more..

Rgds

Jorge

[ryandibble]

Jorge,

My last post was actually the one about the problem being solved, but you'd have to look at the timestamps to notice this. My post about reloading the ASA looks as if it was a later post because it appears at the bottom because it appears at the bottom this thread.

In short, the problem was fixed by replacing the Check Point key.

Thanks,

Ryan

[JORGE RODRIGUEZ]

Thanks Ryan,

Rgds

Jorge

[MMstre]

I want to update this post with another cause and resolution that i found today when running into this error.

I received this same error today and the cause was the crypto map attached to the interface. When creating a VPN, the ASDM overwrote the crypto attached to the interface with the ASDM default.

So make sure the crypto map on the interface is the correct one that the VPNs are using