Multiple IPsec VPNs between PIX

OK... I did some more reading - and I found the answer: When modifying a crypto map, it should be done in this order:

1. input the command "no crypto map MYMAP interface outside"

1. make your changes to your crypto map

2. input the command "crypto map MYMAP interface outside"

It seems that the interface needs to be "re-mapped" to the crypto map for the new changes to take effect.

BTW, I also tried the above steps in the following order: 2, 1, 3. This also worked.

That's not actually necessary for PIX 6, but you do need to "clear ipsec sa". Removing the crypto map from the interface would have the side effect of clearing the SA's.

Do I understand correctly then that "clear ipsec sa" would "reset" the VPN tunnel and automatically restart it with the new changes?

Also, when I did "no crypto map...", BOTH VPN tunnels were torn down and rebuilt. Is there a way I can do this so that only the tunnel I made changes to is torn down and reset?

Thanks

Yes.

No, if you "no crypto map", it is going to tear down all the tunnels on that interface. You could remove individual crypto map policies, but (in PIX 6 at least) there could still be hold-overs not cleaned up. "clear ipsec sa" gets rid of the holdovers. There are ways to clear specific SAs, but I keep forgetting them (and I haven't worked on a PIX for over a year now.)

One last question Walter,

I've read several times that making changes to a crypto map without removing the crypto map from the outside interface first can cause the PIX to lock up, or at least, stop passing any traffic at all. This is why I did the no crypto map first. As far as you know, is this a valid concern? Or is this not applicable to IOS 6.x. Thanks again.

I have not heard that, but it could be that it is true.

When I was writing my configuration generator, I did manipulate crypto maps, but that was for a different reason. My configuration generator had to produce a configuration that could be pushed in over a VPN link, and naturally if you munge your active crypto ACLs you end up munging the VPN doing the update right out from underneath you, cutting off the tftp copy. The mechanism that reduces this risk to the smallest possible window is to construct complete new ACLs (with different names) and a complete new crypto map (with a different names), and then enable the new crypto map on the interface (and do this as late in the configuration as possible). This results in the entire crypto infrastructure being updated simultaneously (but, alas, not instantaneously), so you are never left with an inconsistant state. You -might- lose communications at that point, but because the complete new crypto infrastructure ins in place, you can regain communications.

(My configuration generator went further than that; after enabling the new crypto infrastructure under the new names, it would proceed to tear down the old names, then it would rebuild the old names with the new content, and then would enable the old crypto map name on the interface. As this is now just a rename with identical contents, I never lost communication at this point. Then the configuration generator tore down the temporary names. By doing things this way, downtime on the link are minimized, the risks associated with downtime on the link are minimized (can always get communications back), and because the configuration is left with well known names, the configuration generator does not have to guess or probe to find out the names currently in use.)

Thanks for your help and insight. much appreciated.