Remote site - How to change the set peer command with maintaining the tunnel

I am going to need to change our headquarters public IP within the next day or two, on our remote VPN Endpoints how can I work around configuring the new crypto maps, and tunnel-groups and not having to drive out to 20 branches.

Create entire new crypto maps and new tunnel-groups? I did that last time and as soon as we switched and changed our HQ ASA outside IPs the tunnels never came up had to drive out to each site and perform the clear crypto ipsec/isakmp sa and delete the old crypto group.

Right now, I am thinking of adding the new IP address in the same crypto group, set peer command. I only need to create one more tunnel-group then

So, something like

Remote site:
set peer 1.1.1.1 (new HQ IP Address) 2.2.2.2

Will this work?

Thanks

Find more posts tagged with

Comments

Hondabuff

For one, I would create an ACL on the branch Firewalls that allows SSH from the Private and public IP of the corp office. Seems silly if your VPN drops that you would have to drive to each site to bounce the tunnel. 2nd, Is there any way during the maintenance window to bring up a new interface with new public IP while still having the old WAN IP still up or is the Carrier just changing the IP on you? That way your not dropping the network for the Corp office and VPN's at all the branch offices at once.

Edificer

Thanks for looking into this. I appreciate it. We have a closed communication network.

There are existing ACLs for the private IPs, but none for the public IPs on remote branch currently. The carrier has giving us until Saturday to complete the transition. Fortunately, our Carrier technicians deployed and installed ODFs in our datacenter today with the newly directly connected Fiber connections to their datacenter. We are migrating from Wireless to Fiber. This allows me to deploy a 5505 in our datacenters, bring up a tunnel with an ASA just feets away from it (per request we have been giving 2 /29 Public IP ranges) and try to find a solution. In that case, if the tunnel drops it wont be a nightmare for me a quick rollback allows me to have another attempt.

My network predecessors have tried several things (whilst they have had to do this in their career timeline)
they made the remote Endpoint the initiator - Failed
they created new crypto maps and tunnel-groups - Failed

As a result, I was dispatched with the duty to bring them up again.

tomorrow I will try and add the new public IP in the existing set peer command after having created the tunnel-group for the new public IP.
If that fails, I will repeat the same but override the existing set peer command and have only one public IP entry in the existing set peer command instead of two.

If that fails, I guess creating new tunnel-groups, new crypto maps perform a clear configure tunnel-group (old public IP) and switch Main to the new public IP. Theoretically, this should work.

Fingers crossed. Will keep you posted!

Edificer

It all turned out good today I actually tested on our live-production, there was downtime for no more than 3 minutes but I had clearance.

On remote Endpoint I created the tunnel-groups, and added another IP in the existing crypto maps. When switching Main over to the new IP the vpn only came up after the clear crypto ipsec/isakmp sa command. I'm not sure if I am following guidelines for this. I will research and look for the proper procedures regarding a change of public IP on Main ASA.

I guess when they did this last time the command 'default originate' or something similar that caused the Endpoint to be the initiator was the culprit.

Cider

Edificer wrote: »

It all turned out good today I actually tested on our live-production, there was downtime for no more than 3 minutes but I had clearance.

On remote Endpoint I created the tunnel-groups, and added another IP in the existing crypto maps. When switching Main over to the new IP the vpn only came up after the clear crypto ipsec/isakmp sa command. I'm not sure if I am following guidelines for this. I will research and look for the proper procedures regarding a change of public IP on Main ASA.

I guess when they did this last time the command 'default originate' or something similar that caused the Endpoint to be the initiator was the culprit.

can you draw some sort of topology for this and configs (if you can). I would like to try and recreate, seems interesting.

Edificer

Will do. I will actually give you our existing connection diagram on Sunday, leaving out sensitive IPs ect. (Where I am located the Friday and Saturday are weekends, Sunday is first working day of the week)

Follow up on further configuration detail:

We successfully migrated over to the new public IP. There is no IP entry for the old public IP in any of our Endpoint ASAs. I learned something else in the process of doing that that I think might be helpful to y'al (if you are a newbie like me).

Our Endpoint ASAs now were online with the new public IP, but it had 2 IP entries in the same set peer command as:
crypto map Field_Map 10 set peer 1.1.1.1 2.2.2.2

So, I rewrote the set peer command as:
crypto map Field_Map 10 set peer 2.2.2.2

To no avail it still showed as:
crypto map Field_Map 10 set peer 1.1.1.1 2.2.2.2

So, I created a new numbered (11) crypto maps with the exact match of the existing crypto map but with only one IP entry so I had a backup if I did any misconfiguration and the VPN would still be up.

Now I entered the following command:
no crypto map Field_Map 10 set peer 1.1.1.1

The VPN immediately dropped after entering the command for only a few seconds. Although, the crypto map now showed as:
crypto map Field_Map 10 set peer 2.2.2.2

I deleted the 'backup' crypto map 11 and ran the same procedure with other VPN Endpoints. It's simple, but only if you know it!