Need Help with Tunnel Endpoint Change on Cisco Pix

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Hello Everyone,

One of our customers is making a VPN tunnel endpoint change (New endpoint and IP address). The old endpoint will no longer be operational by the end of the month. The problem is that my manager of IT is on leave, cannot be contacted, and will not be back before then.
So it falls in my hands to make the change. I'm a Cisco noob, and I was wondering if someone could help me with the procedure.
Everything else will be remaining the same on the tunnel, I just need to change the IP address to reflect the new endpoint.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

If you read my earlier post - ignore it - I jumped the gun a bit! You should just be able to change the crypto map, disable ISAKMP then re-key and, with the new key, re-enable ISAKMP. That ought to do the trick - though I've not used a PIX for aeons so someone with mor erecent experience might be able to correct that if its wrong

PS: If you've got a non-PIX endpoint at one end of the tunnel you might have problems - PIX is (or at least was a couple of years ago) notrious for having a hissy fit with other vendors' kit...

 

Thanks for your reply! Please bear with me.

I need help understanding what I see in the config.

I see:

access-list Client1 permit ip 10.11.4.40 255.255.255.248 10.14.0.0 255.255.192.0 ->Is Client1 now a variable defined here? An access list entry that can be referenced for other use?

crypto ipsec transform-set Client esp-3des esp-md5-hmac -> The "Client" here, is this a seperate from the access-list "Client1". Is this the name for the VPN tunnel?

crypto map ibm 110 ipsec-isakmp -> What does this line do?

crypto map ibm 110 match address Client1 -> "Client1" from the access-list is referenced here, what does this do?

crypto map ibm 110 set peer 209.197.5.36 -> This is the old endpoint.

crypto map ibm 110 set transform-set Client Reference to "Client" here, what does this do?

Also, you say disable isakmp. Will that disable all the other tunnels as well, will I have to generate a new key for all of them?

 

Creating a ipsec connection on the pix requires a few things to be configured - among them an access-list to select the traffic to be sent to the remote side, an isakmp policy, a transform set, and a cryto map to tie the bits together.

access-list Client1 permit ip 10.11.4.40 255.255.255.248 10.14.0.0 255.255.192.0 <-- this the access-list that selects traffic that should be sent through the ipsec tunnel. There should be no need to change this unless there have been changes to the internal networks on either side.

crypto ipsec transform-set Client esp-3des esp-md5-hmac <-- This is the transform set for the connection. This should not need to be changed unless you and your client have decided to use a different transform set.

crypto map ibm 110 match address Client1 <-- This line specifies the access-list, above, that selects traffic to encrypt.

crypto map ibm 110 set transform-set Client <-- This line specifies the transform set to use.

Basically, you have a crypto map called ibm, and you will need to change the peer ip address and likely a pre-shared key used for the ipsec connection. If you are using a pre-shared key look in the config for a line that references a psk for that peer, e.g.:
sh run | grep <old-ip-address>

- and look for a line something like:

isakmp key ******** address <old-ip-address> netmask 255.255.255.255 no-xauth no-config-mode

Make sure you and your client agree on the pre-shared key to be used for the new connection!

In short, when you are ready to change over to the new peer, have everything ready and here is a brief outline of the process:

- First remove the existing crypto map from the interface, e.g. "no crypto map ibm interface outside"
- Then enter the pre-shared key for the new peer ip address, e.g.:
"isakmp key astrongkey address 1.1.1.1 netmask 255.255.255.255 no-xauth no-config-mode"
Note the PSK is shown as ******** in the config, make sure you enter it correctly!
- Then change the peer ip address in the crypto map, e.g. "no crypto map ibm 110 set peer <old-ip-address>" then "crypto map ibm 110 set peer 1.1.1.1"
- Finally put the crypto map back on the interface, e.g. "crypto map ibm interface outside"

Then, send some traffic to the remote site and see if the connection comes up.
show cry isa sa <-- this will show the isakmp status, QM_IDLE indicates an established connection.
show cry ips sa <-- check for traffic being encapsulated and de-encapsulated, indicating ipsec traffic is flowing between the sites. I often use "sh cry ips sa | grep ident|pkts" to quickly check for encrypted traffic flow.

But, be ready for troubleshooting, and triple check all commands for typos!

Spice_Weasel

 

Amazing stuff! Thanks so much for breaking this down for me!

So from login to finish.

>en
>config t
>int ethernet0 -> Not sure if this is needed.
>no crypto map ibm interface outside -> Will disable all of the other tunnels as well? Do I need to specify?
>isakmp key <astrongkey> address 66.34.134.89 netmask 25.255.255.255 mp-xauth no-config-mode
>no crypto map ibm 110 set peer 209.197.5.36
>cypto map ibm 110 set peer 66.34.134.89
>crypto map ibm interface outside

 

You can only have one crypto map applied to each interface. If you have multiple ipsec connections they are defined as seperate sequence numbers on the crypto map, for example you have sequence 110 that specifies how to connect to the client. Presumably there are other sequence numbers on the crpto map ibm for connections to other clients.

That means that removing the crypto map ibm from the interface WILL affect all other connections defined by that crypto map. The interruption should be brief but there will be some (likely very short) interruption in service, this needs to be considered. In my experience this interrruption is usually very limited as the other connections should re-establish right away, but it is something to take into consideration.

Your procedure would look something like this:

First, make sure you have all the info you will need - pre-shared key, etc. Go through the existing config. Run the show commands below so that you know what connections are established. In particular, check how the pre-shared key for the client is set, my example above had no-xauth and no-config-mode set, quite likely yours is different.

en
conf t
isakmp key <astrongkey> address <new ip address> net 255.255.255.255
no crypto map ibm interface outside
no cry map ibm 110 set peer <old ip address>
cry map ibm 110 set peer <new ip address>
cry map ibm int outside

Then, trigger some traffic to bring up the tunnels, and check the status of the connections:

"sh cry isa sa" and "sh cry ips sa"

tt67-cfw-2# sh cry isa sa
Total : 1
Embryonic : 0
dst src state pending created
10.12.34.56 10.34.56.78 QM_IDLE 0 0

tt67-cfw-2# sh cry ips sa

interface: outside
Crypto map tag: vpn-map, local addr. 10.34.56.78

local ident (addr/mask/prot/port): (192.168.56.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.11.0/255.255.255.0/0/0)
current_peer: 10.12.34.56:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 72377570, #pkts encrypt: 72377570, #pkts digest 72377570
#pkts decaps: 51024941, #pkts decrypt: 51024941, #pkts verify 51024941
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 6, #recv errors 0

local crypto endpt.: 10.34.56.78, remote crypto endpt.: 10.12.34.56
path mtu 1500, ipsec overhead 56, media mtu 1500
current outbound spi: c05b4161
... plus lots more output! I often use "sh cry ips sa | grep ident|pkts" in order to easily check that packets are being encrypted and decrypted for each connection.

"sh cry map" will give you a summary of your crypto map.



Spice_Weasel

 

So how do I know specifically how the shared key is setup.

On the show config the line reads "isakmp key ******** address 209.197.5.36 netmask 255.255.255.255"
That's it.

So how do I know if I need to add "mp-xauth no-config-mode" or anything else to the line ">isakmp key <astrongkey> address 66.34.134.89 netmask 25.255.255.255" ?

Thanks again!


PIX01# sh cry ips sa


interface: outside
Crypto map tag: ibm, local addr. 129.66.178.132

local ident (addr/mask/prot/port): (10.11.4.40/255.255.255.248/0/0)
remote ident (addr/mask/prot/port): (10.14.0.0/255.255.192.0/0/0)
current_peer: 209.197.5.36:500
PERMIT, flags={}
#pkts encaps: 324364, #pkts encrypt: 324364, #pkts digest 324364
#pkts decaps: 212453, #pkts decrypt: 212453, #pkts verify 212453
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 129.66.178.132, remote crypto endpt.: 209.197.5.36
path mtu 1500, ipsec overhead 56, media mtu 1500
current outbound spi: cf7ca9c3

inbound esp sas:
spi: 0xbad687c1(3134621633)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 29, crypto map: ibm
sa timing: remaining key lifetime (k/sec): (4607988/3117)
IV size: 8 bytes
replay detection support: Y


inbound ah sas:


inbound pcp sas:


outbound esp sas:
spi: 0xcf7ca9c3(3481053635)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 30, crypto map: ibm
sa timing: remaining key lifetime (k/sec): (4607989/3113)
IV size: 8 bytes
replay detection support: Y


outbound ah sas:


outbound pcp sas:

 

Since your existing pre-shared key statement does not have the no-xa and no-conf set then your new psk should not need them. Basically, no-xa disables extended authentication for that peer. For example, you might use radius, tacacs+, etc. to authenticate connections, no-xauth would exempt a particular peer from extended authentication. No-config-mode exempts a peer from ike mode configuration.

Configuring a pre-shared key is easy - for example, if your psk is qwerty and the peer is 10.11.22.33, you would enter:

isakmp key qwerty address 10.11.22.33 netmask 255.255.255.255

Naturally, use a strong key.

You should know the psk that you will be using for the connection with the client. It should be (securely) documented - if you need to recover the key check a tftp of the pix config for the key. I usually treat an address change as essentially a new connection and set a new psk with the net admin at the other side.

Making changes to a production system, particularly one with multiple ipsec connections, should be done carefully. If there are problems it will be difficult to troubleshoot without experience. It seems in your case that you need to do this fairly soon, without being able to wait for the IT manager, so I would suggest taking the time to check the Cisco docs as much as possible. And, do the changes locally, and test thoroughly after making the changes.

Spice_Weasel

 

Yeah this has to be done before the end of the month. Next week Tuesday morning at 2:00am to be exact.

We have a redundant tunnel on Checkpoint firewalls.

The plan is to:

- Make the change on the Checkpoints first which is much easier for a noob like me thanks to GUI
- Test the traffic on the redundant tunnel
- Then make the change on the main

So at least the backup will be there while I trouble shoot and cry.

I'm just curious; what would happen if I just did the following. Without bringing down the crypto map first?

>en
>config t
>no crypto map ibm 110 set peer 209.197.5.36
>cypto map ibm 110 set peer 66.34.134.89
>isakmp key <astrongkey> address 66.34.134.89 netmask 255.255.255.255

And yes I plan to read my ass off until that time! Any recommendations?

 

It is possible to just change the peer ip address on the crypto map entry without removing the map from the interface, then clear the ipsec sa for that peer. It is recommended to remove the map to ensure that there are no problems. However, I have sometimes changed peer statements directly and not had any problems. But the best practice for the pix is to remove the map, edit it, and put it back on the interface. But many people take the shortcut of editing it without removing it, but keep in mind there is a chance of unforeseen problems.

Some reading to get you started - I find cisco docs to be good, search around their site, there are plenty of sample configs to help make things a bit clearer.

Pix configuration guides:
http://www.cisco.com/en/US/products...stallation_and_configuration_guides_list.html

Pix command references:
http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_command_reference_list.html

Spice_Weasel

 

Thanks Spice_Weasel!
I think it might be time for me to take a break from Microsoft and get more into networking.
I have a question about the cisco path.
I would like to understand networking better on a whole. How vendor neutral is cisco training?
Like would studying for the CCNA teach me mostly just how to configure Cisco switches and routers, or would it help me better my understanding of networks in general; stuff that can be applied in any situation, cisco or not?

 

Naturally the CCNA is Cisco specific, but a large part of the material covered in the CCNA is vendor-neutral, and I think would be quite useful to any IT professional. Also, even though the configuration and troubleshooting is Cisco specific, much of what you would learn is useful with other vendors - spanning tree, vlans, rip/ospf/etc. are common to every vendor, and although vendors may not implement them in the same way, the core concepts are pretty common across the industry. I think command line experience is also handy, as many vendors have similar command lines; if you are experienced with IOS you can hop onto an HP, Foundry, etc. with a small learning curve. Of course, if you learn the JUNOS command line, all others will seem inferior ;)

In many ways networking is more homogenous than with OS'es - if you are a good network engineer you can adapt to different vendors more easily than getting an MSCE to admin a RedHat box, for example, and in that sense the CCNA is a good goal to work towards to demonstrate networking compentancy.

But the key is experience and understanding the concepts. If you don't use the knowledge it will fade away - I have met plenty of CCNA's who haven't touched a router since they got the cert and would be lost doing any real world tasks.

Spice_Weasel

 

Yeah if you don't use this stuff you definitely loose it pretty quickly!
With my manager gone for the last 8 weeks I'm starting to get more and more networking requests that would normally go to him. With him taking care of the networking production side of things I was left to focus on the corporate Microsoft side of things which now seem MUCH less important.

I've herd good things about TCP/IP Illustrated volume 1 book. I think I'll start by reading that and then get into the Sybex CCNA study guide 6th edition.
There's some spare cisco equipment here for me to practice on as well.

Thanks for all your help

 

The switch-over went through perfectly. Took about 45 minutes including testing, was in bed by 3am instead of 6am as I had anticipated (I always expect the worse).
Anyways thanks again Spice_Weasel and zebulebu