VPN Site-to-Site between Checkpoint VPN-1 v4.1 and Cisco Concentrator 3000

[Santa]

Has anyone successfully accomplish this oh so tricky task?

It appears straight forward at first but then after setting up all the rules and objects only the cisco --> checkpoint side brings the tunnel up but the checkpoint --> cisco side does not.

The cisco side has all their servers running directly off of legal addresses instead of any NAT.

The Concentrator is on a differnt segment from the server we need to get to also.

On the Checkpoint side (ours) we use NAT to translate private to public.

When I try to generate traffic to bring the tunnel up I either get "no response from peer" or "Invalid cookie"

What the heck does Invalid cookie mean?? After searching around I find that others have had this problem but no one has resolved it as of yet.

We have tried almost every combination of encryption algorithm. MD5/3DES, SHA1/DES, MD5/DES all with the same results.

Anyone out there who has successfully done this combination of VPN Site-to-Site connection?

 

[spidey07]

yes.

Pay close attention to the re-key and key lifetime interfvals. Checkpoints is global across the entire firewall where the 3000 can do it on a peer by peer basis.

Check and double check all of your IPsec settings, log everything on both sides and maybe I can help. Its been a while since I've messed with it though.

 

[Santa]

We have our lifetime for IPSec set to 3600 and I had the other end change their lifetime to 3600 but 3600 is so long. Why would it not work at all?

I would imagine that it would work then just die off or something like that.

We have it completing the Phase 1 and Phase 2 when Cisco --> Checkpoint Packet gets generated but I am not sure if it is completing Phase 1 and Phase 2 Checkpoint --> Cisco packet generated.

As I mention when a packet is sent from the Cisco side it comes through and I can see in my log that the firewall decrypts the packet (ICMP) then when the response comes back from our server they pinged it encrypts the ICMP packet and sends it back over the tunnel. They get total round trip when orginating from their side.


Should I change the checkpoint key time out to match the cisco instead?
It was like 28800 or something like that.

Should we expect to be able to do 3DES/MD5? If so I would like to stop jumping around trying to do DES/SHA1/MD5/3DES combinations..

Let me know what would be helpful to see.

 

[spidey07]

As long as both sides send and accept the proper negotions you should be fine. So 3des/md5 is fine.

I'm trying to think through the ipsec negotiation phases, we need to find out where it is breaking and why. I'm guessing because with ipsec you have an initiator and a respondor. The initiator offers negotiations to which the responder replies - there is no negotiation per say.

Initiator - I want to do this, with this key time and this encryption
Responder - says yes or no.

Then phase 2 starts with the security assocations actually being built.

Try again and maybe change the re-key time as well.

Are you using any public key? Or pre-shared?

 

[spidey07]

http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a00800946a4.shtml

 

[Santa]

We saw that very same documentation on Cisco site.

It doesn't fit our setup to a T in the fact that the cisco side doesn't do NAT.

They just have machines with legal addresses assigned directly to their physical interfaces.

Also we are using pre-shared keys.

Have you ever heard of Invalid Cookie message? That is puzzling to me.

I don't know if its a helpful or just plain weird bogus message but it corosponds to when the tunnel is trying to come online.