VPN Tunnels

Correct - if all that has changed is the WAN IP of one of the PIX/ASA's, you should only have to update the IP address where it might appear in your configurations.  Once updated, you should be able to clear the VPN sessions to have them re-established (if they do not do so automatically).

And yes, same with the PCF's for your remote clients as well.

Good luck!

Mike

Assuming that you are NATTING traffic then only the peer addresses will need to change.

Ok so I cleared the vpns using clear isakmp and clear ipsec sa commands.  Now I can't get to the pix at all remotely.  What happend?

I rebooted back to the old config and was able to gain access again.  I changed the peer ip address again, but doing:

sh crypto isakmp sa

I don't see the ip of the tunnel that was just changed.

You can't just change the "set peer" statement in the crypto map - you must also change the tunnel-group to match the new IP.  Use the "clear config tunnel-group ipaddress" command to get rid of the existing tunnel-group, then re-add with the new IP.

On the ASA I mean.

well i dont have access (to the ASA remotely) to change a tunnel group.  On the other two pix's I changed the the peer addresses.  What exactly needs to be done to the ASA that the IP changed on?  The only change was the outside int ipaddress..

No change should need to be made on the ASA, unless I'm missing something in all of this.  You on the PIX units, you need to change the peer address and add new tunnel groups.  For example, let's say your PIX unit is communicating with a peer at 1.1.1.1.  You will have a configuration that looks like this:

crypto map outside_map 10 set peer 1.1.1.1
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
 pre-shared-key *****

When you change the IP of the peer to 2.2.2.2, you have to create a matching tunnel group.  If you just change the peer, you'll get this:

crypto map outside_map 10 set peer 2.2.2.2
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
 pre-shared-key *****

That doesn't match up and isn't going to function.  Add the following, making sure to match the ipsec-attributes associated with the old tunnel group.

tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
 pre-shared-key *****
no tunnel-group 1.1.1.1 ipsec-attributes
no tunnel-group 1.1.1.1 type ipsec-l2l

This needs to be done to assign the ISAKMP key for the tunnel as mentioned earlier.

I don't see anything where a tunnel-group was set.  Mine looks like this:

crypto map outside_map 10 ipsec-isakmp
crypto map outside_map 10 match address outside_cryptomap_10
crypto map outside_map 10 set peer x.x.x.x
crypto map outside_map 10 set tansform-set ESP-3DES-MD5

What should be done here?

There is a line with the old address that looks like this:

isakmp key ******* address x.x.x.x (old ip) netmask x.x.x.x no-xauth

Is this what I need to change?  If so does that key need to match something on the ASA?  I don't know what the key on the ASA is or the preshares.  The person who set this up is out with a medical emergency in the hospital.

Ah...  that line is a giveaway.  You're running an older version of the PIX software, so the terminology is a bit different.  You can forget the tunnel groups I mentioned earlier as those only apply to the new versions of the PIX OS.  You're right on the money with needing add the ISAKMP key for the new peer address, so the change would look something like this:

isakmp key ******* address x.x.x.x (new ip) netmask x.x.x.x no-xauth
no isakmp key ******* address x.x.x.x (old ip) netmask x.x.x.x no-xauth

The challenge, of course, is to recover the key as the PIX isn't going to show them to you.  With the newer software, this is relatively simple.  With the old software, there's no internal mechanism to do so.  What you *can* do is write the configuration to a TFTP server, which will provide a copy of the configuration with plaintext keys.

If you haven't got a TFTP server set up, you can easily get one (assuming you're running Windows) at http://tftpd32.jounin.net/tftpd32_download.html.  Once you've got it running, execute the following on the PIX to copy the configuration to the TFTP server.

write net x.x.x.x:pix-config.txt (where x.x.x.x is the address of your TFTP server)

Once the transfer is complete, open the pix-config.txt file and look for the ISAKMP statement.  You should find the encryption key in plaintext.

OK I am almost there.  When I run the wr net I keep getting the error:

TFTP write '/Corporate/pix-config.txt' at COR-FS on interface 1
Access violation

Can you tell me how to resolve that?

Are you including the /Corporate/ in the TFTP write command or is that somehow appearing on its own.  TFTP doesn't handle subdirectories, so you need to make sure that you're using something like this:

wr net x.x.x.x:pix-config.txt

...rather than this:

wr net x.x.x.x:/Corporate/pix-config.txt

It is appearing on its own.  I wrote the command as follows:

wr net x.x.x.x:pix-config.txt

not sure why it is doing that.  Have you got any ideas?

So I have the isakmp key ( I talked to the person who set it up and he gave me two options to try).  Is there a way to clear out everything on the tunnels so that I can see if it comes up?  If I change the isakmp key for the new ip address should that fix the problem and the tunnels just come up auto?

Issue the following command at a privileged prompt and you're good to go:

clear crypto isakmp sa
clear crypto ipsec sa

This will clear all of the encryption maps, but they will re-establish quickly.

I still cant get tunnels to come up.  Is there something else that I need to do?

You've got too many hands in the cookie jar here, this thread gets more and more confusing as we go.  
From what I can tell:

(1) You have a hub-and-spoke l2l vpn set up with an ASA at the hub and PIX at the two spokes
(2) The WAN IP of the ASA (the hub) was changed, now you need the tunnels to come back up

Are these statements true?  If so, this is not hard at all, but we've got to be sure we're talking about the same thing, is all.  Verify for me if the ASA is indeed the hub and the spokes are PIX.  Also, what version of code is on the ASA, and what version is on PIX?  Is this true hub-and-spoke, or are the VPNs meshed?  If it's true hub-and-spoke, are you hairpinning on your ASA (i.e., spoke A can get to spoke B through the ASA WAN interface).  

Also, are you using certs for the l2l phase 1 auth, or pre-shared-key?

Also, what is the output from a "show crypto isakmp sa" command?

Yes Texas you are correct.  I have an ASA that had tunnels to two other pixes.  The WAN IP address changed on the outside interface.  Pix are running ver 6.3 and ASA ver 8.  Thant was the only change made.  On the pix all i did was the following:

crypto map 30 set peer XXXX

isakmp key XXX address XXX netmask XXX no-xauth

I ran sh isakmp sa, and all of my tunnels are there except for the new ip tunnel

I am not using certs for ike i am using preshare key

Based on your response, all tunnels are using the same transform-set, yes?  
And the one tunnel that won't come up, is that to one of these PIX firewalls, or to a tunnel that is new to this config?

If you're missing one tunnel, verify on the ASA:

(1) You have some numbered access-list permitting traffic from the hub subnet to the remote spoke private subnet
(2) You have added the same ACL element(s) from step 1 here to your nat 0 statement on the ASA.
(3) You have bound this numbered ACL from step 1 to the crypto-map for the tunnel
(4) You have a valid tunnel-group with the pre-shared-key

Verify on the PIX:

(1) That you did not put a typo in the pre-shared-key when you reset the "isakmp key" command - I'll be anything this is your problem

To troubleshoot:

On your ASA, enable syslogging with level "warnings" to the buffer:

(1) config t
(2) logging enable
(3) logging timestamp
(4) logging buffered warnings

Then set a terminal ping from a host on the hub subnet to a host on the spoke subnet (ping hostip -t <enter>)

Then on your ASA,

(1) Clear log
(2) show log
(2) show log

You can use the space bar to scroll through the log.  You can keep issuing the clear log command if the log is too full and you can't make sense of what's what.  

Keep viewing the log, and the ASA will tell you exactly where the tunnel is failing.  I bet you see a pre-shared-key mismatch.  It's possible you'll see something else, but I bet it's a pre-shared-key mismatch.  If you don't see anything about your vpn in the log, you have a problem with access-lists, no question about it.  --TX

Thanks. Problem is I don't have access to the ASA as the IP has changed.  I am not physically where the ASA is.

Oh, you can't get to it on the WAN interface, so ssh / asdm aren't enabled to the WAN?

You can also go the same thing on the PIX, can you get to the PIX where the tunnel isn't working?  if so, you can do the same thing there, identical instructions, except for the "logging enable" command.  On PIX, that is "logging on".

Also try just removing and re-adding the "isakmp key xxx" command - bet you anything the problem is right there - if, indeed, this is a tunnel that was working fine until the WAN ip changed and you only made those few changes on the PIX.

Did you have access to the ASA before the IP changed?  If so, that access is still enabled, just log into the new IP.  It'll be the one you configured in the "isakmp key xxxx" address on your PIX.

Or you can call someone there, have them go to www.ipchicken.com, and tell you the IP it reports back.  If your ASA is configured with "global (outside) 1 interface) - the IP reported by IP chicken is the IP for remote management.

well we did not have outside access set up.  we managed it from within the tunnel.  So I am guessing that I will have to go there and console.

I do have access to both of the pix devices.  And yes those tunnels were in place before the ip change.  The ip's have not changed on the pix's so the tunnel group should not need to be changed on the ASA right?

OK, and you're not on site at the PIX location either?  Remember, if you're onsite where at the location with the PIX that's not working, you can do it from there too.

If you have to visit the site and console, you should also set up wan access so you can get to it remotely.

config t
crypto key generate rsa modulus 1024
ssh permit ipaddress 255.255.255.255 outside
wr mem

Then download a free ssh client like PuTty and you can ssh into your ASA as long as you're coming from the ip specified in the "ssh permit" statement.

I use PuTty on my phone with symbian OS and it works a treat.  I can log into all my equipment with my phone so I don't have to go into the office, wait 'till I get home, find a wifi hotspot, etc.  

But I still think if, when you get a chance, you re-enter the "isakmp key xxxxx" statement on the PIX that's not working, being extra careful not to have any typos in there and that the key is the same as the one entered in the tunnel-group on the hub ASA, you'll be golden.  --TX  

right, if the IPs on the PIXs hasn't changed, the tunnel-group on teh ASA is to be left alone.

Re-enter the "isakmp key" command on the PIX that's not working.  I bet it fixes your problem - if it doesn't, reset the pre-shared-key on teh hub ASA for the corresponding tunnel-group.  I bet anything that's the issue.

I do have access to both of the pix devices.  And yes those tunnels were in place before the ip change.  The ip's have not changed on the pix's so the tunnel group should not need to be changed on the ASA right?

I do have access to both of the pix devices.  And yes those tunnels were in place before the ip change.  The ip's have not changed on the pix's so the tunnel group should not need to be changed on the ASA right?

Thanks a lot for your help.