CPUG

The Check Point User Group

A Resource For The Check Point Community.  Fast.  Useful.  Independent.

1. CCSA/CCSE One-Week Dual-Certification Training Course with CPUG in San Francisco!
    Courses Starting 12/8, (2009) 1/19, 2/9, 3/9, 4/6, 5/4, 6/8, 7/6, 8/3.
2. Join Us On LinkedIn - We now have a CPUG group.


Go Back   CPUG: The Check Point User Group > Check Point Firewall-1/VPN-1 And Related Products > VPN's (Virtual Private Networks)
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 2005-08-13
Administrator
 
Join Date: 2005-08-11
Location: San Francisco, CA
Posts: 582
Rep Power: 10
BarryStiefel has disabled reputation
Default Delays involved in rekeying VPNs

Delays involved in rekeying VPNs



I have a live Nokia IP530 + NG-FP3 supporting several VPNs to customer sites and want to safely upgrade to NG-AI with as little disruption to services as possible. Fortunately we have old IP440 which I can hot swap to, to cover us while we do the upgrade.

My strategy is to recover a backup of the existing IP530 on to the IP440, perform the upgrade on the IP440, then swap over to the IP440 while I upgrade the IP530.

My query is on how the VPN IKE keys will behave when I make the change over. The data on the IP440 is over a day old so any key information will be stale, but the remote ends will all have recently negotiated keys.

How can I get the VPNs to quickly negotiate new KEY sets without having to involve administrators at the customer sites or will this happen automatically?

Answer The actual encryption keys used to encrypt transmitted data are regularly re-negotiated. The pre-shared secret or certificates are used for authentication purposes. There would be no way for the IP440 to "know" what the encryption keys are, but that's a good thing.



When the IP440s are brought online in place of the IP530, both ends of the VPN will quickly realize they are "out of sync" and attempt to re-establish themselves. I'm sure someone out there knows exactly how this works itself out in IPSec terms, but it would be no different from a VPN endpoint suddenly disappearing from the net (catastrophic network or power failure). In many cases, it is able to recover from this gracefully, though not always. Sometimes you may need to do a policy reinstall in VPN-1/FireWall-1 to get things to recover.

If the remote end isn't VPN-1/FireWall-1, all bets are off of course.

-- RobertGraham - 06 Jan 2004

Followup As suggested the new keys were generated automatically without problems.



Thanks UPDATE



With NG, there's a new tool for controlling VPN tunnels. You can launch the TunnelUtil tool by typing:

vpn tu

You then see the following: ********** Select Option **********(1) List all IKE SAs(2) List all IPsec SAs(3) List all IKE SAs for a given peer(4) List all IPsec SAs for a given peer(5) Delete all IPsec SAs for a given peer(6) Delete all IPsec+IKE SAs for a given peer(7) Delete all IPsec SAs for ALL peers(8) Delete all IPsec+IKE SAs for ALL peers(A) Abort

Basically, this tool allows you to build and tear-down tunnels as you can with IOS. References:



Command Line Interface (CLI) NG with Application Intelligence -- ChrisG - 10 Jan 2004



FAQForm FAQs.Class: EncryptionFAQs FAQs.OS: FAQs.Version:
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


All times are GMT -7. The time now is 23:53.


Powered by vBulletin® Version 3.7.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.2.0