What do I need to do to make a change to my crypto map?

I have an established site-to-site VPN "router" connection between my VPN router and another VPN router located at a business partner. I need to make a change on my crypto map to allow new encryption traffic to my Intranet. Do I necessarily need to wait for the business partner so we can both make the simultaneous change together? Or can I just change my crypto map and have the business partner change their crypto map whenever they get around to doing so? I want to ensure that I don't create an issue or lose my connection with the established VPN tunnel. I don't want to experiment on a production VPN connection.

    Requires Free Membership to View

    Login

I'll assume that you're using IPsec to tunnel between your router and your partner's router, that you're currently using one kind of encryption for all traffic (say, 3DES), and that you'd like to start using another kind of encryption for all traffic (say, AES).

When IPsec tunnels (security associations, or SAs) are created, the routers (security gateways) at both ends exchange a list of acceptable encryption algorithms for each SA. It is possible for you to add another encryption algorithm to your router's crypto map (IKE proposal) and have your business partner's router continue to select the algorithm you are now using the next time the SA is re-keyed or re-established. Nothing is likely to happen immediately after you update the crypto map -- if something goes wrong, it probably won't occur until the existing SA's lifetime expires. If nothing goes wrong, you still won't see the newly-added algorithm being used until your business partner updates his router's crypto map and the SA is (again) re-keyed or re-established.

What could go wrong? If both routers are the same version of the same product, one of you may "fat finger" the update -- that is, make a mistake in the configuration like removing 3DES from your map when adding AES, or adding AES with a different key length or integrity option, etc. As you probably know from your initial tunnel setup, it's critical that at least one proposal match exactly, and some trial-and-error to reach that point is common. For this reason, it's always a good idea to back up your existing config, make your change at an off-hour, test your change (e.g. by resetting the SA and verifying you can send traffic again), and be prepared to roll back if you fail. Yes, that's disruptive and not a great idea to try on your production VPN during business hours.

If you and your business partner have different routers or use different versions of software from the same vendor, there's also the possibility that interoperability problems will crop up when you first use a new feature. In your case, any interoperability problem is most likely to occur when your business partner changes his router's crypto map because, until that happens, you will probably continue to negotiate the same old algorithm. Again, you should arrange to test this change off-hours and be prepared to rollback both ends if needed. You should also make sure that the tunnel can be re-initiated from BOTH ends -- when you have a proposal mismatch problem, it's not unusual for a tunnel to work when initiated in one direction, but not when initiated in the other. While you might be able to make the change successfully without coordinating a test time with your business partner, it's probably not a good idea.

This was first published in January 2005

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top