In article , al wrote: :Our HQ PIX is connected via IPSEC VPN to a number of our remote sites. :A couple of our remote site will need to change their public IP addresses. :What I normally do is to configure the remote PIX with their new IP :address :and configure the HQ PIX with the new remote site's peer address and point :the isakmp key to the new peer address. :Then I usually reboot the HQ PIX because when I type "show crypto isakmp :sa", the HQ PIX is still pointing to the remote's old IP address. :Is there a way to refresh this without rebooting the HQ PIX?
clear ipsec sa goes part way. However, according to Cisco, your update procedure is not quite right. What Cisco says you must do at HQ is first disable the crypto map against the outside interface, then do the adjustment to the peer IP (and any ACLs that might be affected), and then re-enable the crypto map against the interface.
Yes, this process -does- stop all IPSec traffic on -all- the tunnels while you make the adjustment. You can reduce this by preparing a -new- crypto map with all the updated details, and enabling that against the interface [with the side effect of disabling the previous one.]
In practice, if you are not changing the ACL associated with a crypto map policy, and are just changing the destination IP, what you can do is add another 'set peer' clause to that policy and then remove the old peer. The tunnels should then "fall over" to the new peer.
If you do change an ACL associated with a crypto map policy, you might look at the output of "show ipsec sa" and see that everything looks right, that the new potential SAs are there. Don't be fooled: when you change the ACL, if you do not clear the ipsec SA's then the PIX might refuse to -use- the SAs that other parts of the PIX knows that it has.
What you must particularily avoid is removing the 'match address' clause of an active crypto map: you will get a mess, possibly even including the PIX deciding that everything matches the non-existant ACL entry, and so it might decide that -everything- should be IPSec protected and promptly start dropping all inside packets with the dreaded "Recv'd packet is not an IPSec packet" message.
:I will need to do one of our remote sites again and I cannot afford to :reboot the HQ PIX.
You won't need to reboot any of the PIXes, not unless you make a mistake. Fatal mistakes including accently locking yourself out of the VPN that you are using to update the IP address on the remote PIX (something more likely to happen if the crypto map ACL includes a match on the remote PIX outside interface, such as for the purpose of getting syslog packets back through the VPN from the remote PIX.
Note that after you change the IP address of the remote PIX, you will have to disconnect your session and reconnect to the new address and tell it to save the configuration -- the ip address change takes effect immediately, before you can tell it to save the configuration...