Have a question or want to start a discussion? Post it! No Registration Necessary. Now with pictures!
- Posted on
- changing IP addresses for VPN
April 28, 2005, 11:39 am
rate this thread
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
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,
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!
Re: changing IP addresses for VPN
: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
: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
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
: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.
- » Digital Wall Covering | Digitally Printing In Malaysia | Dot2Dot
- — Newest thread in » Cisco Certification
- » Android Toast Overlay Attack: "Cloak and Dagger" with No Permissions [te...
- — The site's Newest Thread. Posted in » General Telecommunications Forum
- » RoboCaller now Showing Legitimate Numbers in CallerID [telecom]
- — The site's Last Updated Thread. Posted in » General Telecommunications Forum