[c-nsp] Cisco to Checkpoint VPN

Sat Feb 17 12:51:52 EST 2007

hmm... the output below is a typical (IOS) router "debug isakmp" output.
It indicates roughly "main mode message 4 was processed, now going to message 5".
please forgive some theoretic explanation here, could be helpful.
IKE consists of two phases: "phase one" [which can be done in "aggressive mode" (3 messages) and "main mode" (6 messages)] and "phase two" ["quick mode" (3 messages)].
Phase 1 secures the IKE itself, phase 2 secures the following "production IPsec connection".
In phase one these five parameters are important: authentication (PSK/certs), encryption, hash algorithm, dh group, lifetype/time. In phase two the following: mode (tunnel/transport), transforms [which traffic [ACLs on cisco] should be secured how (encyption, hash)], pfs yes/no, lifetime.
The six messages of main mode can be broken down to three bilateral exchanges:
- negotiation of parameters (message 1+2),
- exchange of key stuff for diffie hellman based generation of key material (message 3+4),
- identification/authentication, secured by the key material just generated (message 5+6).

Given this and regarding "message 4" seems to be processed (Old State = IKE_I_MM4  New
> > State = IKE_I_MM5) this would indicate a problem with the PSK. But the cisco message for PSK mismatch is another one ("%CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 10.1.1.1 failed its sanity check or is malformed" if cisco is responder, if cisco is initiator it's not so easy, usually it's something like

*Feb  8 08:40:11.487: ISAKMP:(1006):Old State = IKE_I_MM4  New State = IKE_I_MM5 
*Feb  8 08:40:11.487: ISAKMP (0:1006): received packet from 10.1.1.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
*Feb  8 08:40:11.487: %CRYPTO-6-IKMP_NOT_ENCRYPTED: IKE packet from 10.1.1.1 was not encrypted and it should've been.
")
 and he said he checked the PSK several times.

So what can we conclude here:

a) it does not look like a "phase 1" parameter problem, the param negotiation is already successfully done at the time of the debug sniplet.
b) it's not a phase 2 problem (so ACLs do not yet matter). Don't waste your time checking them at this point.

hard to investigate further without additional info. questions:

a) maybe something modifying packets in the path (NAT whatever)?
b) is cisco the initiator or responder of the connection? can you try the other direction and provide the debug output?
c) can you provide the whole debug output?
d) can you provide the relevant part of the cisco config and some details of the config on the cp side?
e) as this seems a s2s connection you've probably disabled x-auth for this one on the cisco side, haven't you?. [the error message should be different anyway, I vaguely assume]

thanks,

Enno

On Sat, Feb 17, 2007 at 07:29:53AM -0800, Ted Mittelstaedt wrote:
> A Cisco what?  IOS-based router?  PIX?  VPN coencentrator?
> 
> Please post the config from the cisco side along with version numbers
> 
> Ted
> 
> ----- Original Message ----- 
> From: "Jee Kay" <jeekay at gmail.com>
> To: "c-nsp" <cisco-nsp at puck.nether.net>
> Sent: Friday, February 16, 2007 6:16 AM
> Subject: [c-nsp] Cisco to Checkpoint VPN
> 
> 
> > I'm trying to set up a Cisco to Checkpoint VPN. As far as I can tell
> > everything is set up right (access-lists/IKE IDs match both sides,
> > PSKs have been reverified a hundred times, etc), but during the
> > negotiation we run into this:
> > 
> > Feb 16 14:13:29.400 GMT: ISAKMP:(0:77:HW:2): sending packet to x.y.z.t
> > my_port 500 peer_port 500 (I) MM_KEY_EXCH
> > Feb 16 14:13:29.404 GMT: ISAKMP:(0:77:HW:2):Input = IKE_MESG_INTERNAL,
> > IKE_PROCESS_COMPLETE
> > Feb 16 14:13:29.404 GMT: ISAKMP:(0:77:HW:2):Old State = IKE_I_MM4  New
> > State = IKE_I_MM5
> > Feb 16 14:13:29.488 GMT: ISAKMP (0:268435533): received packet from
> > x.y.z.t dport 500 sport 500 Global (I) MM_KEY_EXCH
> > Feb 16 14:13:39.404 GMT: ISAKMP:(0:77:HW:2): retransmitting phase 1
> > MM_KEY_EXCH...
> > Feb 16 14:13:39.404 GMT: ISAKMP (0:268435533): incrementing error
> > counter on sa, attempt 1 of 5: retransmit phase 1
> > 
> > To me it seems like we send the key exchange packet, the remote end
> > (x.y.z.t) replies correctly but we completely ignore it. 10 seconds
> > later we then retransmit the initial packet which then continues until
> > the session times out and is removed.
> > 
> > Does anyone know why the Cisco appears to be ignoring the MM_KEY_EXCH
> > packet reply from the remote end?
> > 
> > Thanks,
> > Ras
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Enno Rey

ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
PGP FP 055F B3F3 FE9D 71DD C0D5  444E C611 033E 3296 1CC1 