Need Help with Tunnel Endpoint Change on Cisco Pix

[Methodman85]

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.

[zebulebu]

Originally Posted by Methodman85

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.

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...

[Methodman85]

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?

[Spice_Weasel]

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

[Methodman85]

Originally Posted by Spice_Weasel

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

[Spice_Weasel]

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

[Methodman85]

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