asked on

What lines do I need to change when migrating one end of a VPN connection to an new ISP?

I have a IPSec VPN Tunnel setup between two locations.
I want to move the ISP at one location
In order to make the VPN tunnel work at Location B .. what lines must I edit on the PIX?

If Location A is IP Address 999.999.999.999 and these lines exist in the running-config at location B could I just change the address in these two lines and be done

crypto map outside_map 30 set peer 999.999.999.999
isakmp key ******** address 999.999.999.999 netmask 255.255.255.255 no-xauth no-config-mode

Could I jsut do something like
no crypto map outside_map 30 set peer 999.999.999.999
no isakmp key ******** address 999.999.999.999 netmask 255.255.255.255 no-xauth no-config-mode

then
crypto map outside_map 30 set peer 888.888.888.888
isakmp key ******** address 888.888.888.888 netmask 255.255.255.255 no-xauth no-config-mode

Thanks in advance for any help. Of couse I need ot chnge the IP on the Location A interface as well.

ASKER CERTIFIED SOLUTION

batry_boy

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

DanRaposo

ASKER

batry boy

Thanks for the info ... I am not sure if it worked or not. Let me explain. I had decided that instead of just changing the IP I would add a new tunnel and switch between them. I couldn't get it to ever come up.
However, after trying your command I couldn't get the original to come up any more either .. Or so I thought. It turns out I was not patient enough. The original VPN connection came up within 20 minutes of my giving up for the night. Not sure why it even took that long. The bottom line here is that I don't have a good understanding of how this works. So let me restate what I am trying to do and offer a couple paths I could try and maybe then you or someone could help me get where I need to go.

THE GOAL: We are changing ISPs so I need to change the outside interface IP address and gateway on my LOCAL Pix

- to do this I thought I would setup a second tunnel on the REMOTE side PIX with access-rules similar to the original tunnel. This way I could go back and forth by changing the IP on the LOCAL PIX.
- maybe it is better to replace the tunnel policy on the REMOTE PIX with the new info instead of adding a new policy, which requires a new set of IPSEC rules
- I did notice that on the REMOTE PIX ... if I edit the tunnel policy and click advanced that I could add an additional peer as a backup.

THE QUESTIONS
Do you think this would be a good way to test it? In other words could I leave everything as is currently working on the REMOTE PIX except add that second peer from the new ISP and then make the iace and gateway changes on the LOCAL PIX?
Would I then need to run any clear commands?
Is there a better way?
Is there a way/command to test the tunnel policy?

I ran through this but at the time I wasn't able to get anywhere. https://www.experts-exchange.com/questions/22413133/PIX-to-PIX-501's-won't-work-URGENT.html

Thanks for your help. I really need to get this working before they shutdown our original ISP!!!

batry_boy

>>Do you think this would be a good way to test it? In other words could I leave everything as is currently working on the REMOTE PIX except add that second peer from the new ISP and then make the iace and gateway changes on the LOCAL PIX?

Yes, you could do this. However, you'll also have to specify another "isakmp key" statement in the remote pix as well. So, you would need to add an additional "crypto map xxxx set peer <new_ip_address>" statement as well as a "isakmp key ******* address <new_ip_address> netmask 255.255.255.255" statement.

>>Would I then need to run any clear commands?

I would run the "clear cryp is sa" and "clear cryp ip sa" commands, but it would bounce any other tunnels too.

>>Is there a way/command to test the tunnel policy?

The only way to test it is to send interesting traffic defined by the crypto map ACL and see if the tunnel comes up.

DanRaposo

ASKER

I believe this answer is correct. It turns out my ISP has a problem with the routing and therefore I was unable to prove my connection was working.