|
Posted by al on April 28, 2005, 4:39 am
If you were Registered and logged in, you could reply and use other advanced thread options
Hi all,
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?
I will need to do one of our remote sites again and I cannot afford to
reboot the HQ PIX.
Thanks in advance,
Al
--
I am using the free version of SPAMfighter for private users.
It has removed 46119 spam emails to date.
Paying users do not have this message in their emails.
Try www.SPAMfighter.com for free now!
|
|
Posted by Walter Roberson on April 28, 2005, 5:21 am
If you were Registered and logged in, you could reply and use other advanced thread options
: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...
--
Feep if you love VT-52's.
|
| Similar Threads | Posted | | Changing the configuration register | December 29, 2005, 12:49 pm |
| ezvpn w/ router which has changing public address (PPPoE) | March 3, 2006, 1:53 pm |
| A discussion of how Cisco Unified Communications is changing the workplace environment | August 29, 2006, 4:33 am |
| binary and IP addresses | November 13, 2005, 6:58 am |
| hung ip addresses? | January 13, 2006, 10:58 pm |
| Q: Resolving duplicate IP addresses | April 8, 2005, 11:56 pm |
| Private Gateway IP Addresses | July 3, 2005, 10:42 pm |
| Q, regarding VLSM and host addresses | August 21, 2006, 6:01 pm |
| Frame addresses as it traverses Network | February 19, 2005, 8:28 pm |
| Number of usable addresses on a subnet | February 27, 2006, 6:11 pm |
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map