In another life, I was a professional musician and played guitar in a band. I didn’t study a lot of music theory, but I did know a lot about making music and performing it live. In the last chapter, I

went over all the theory behind IKE and IPSec with you. Now, I’m going to build upon that material by showing you what to do with it. In this chapter, you’re going to learn how to configure IKE and IPSec, because while understanding theory is good, you had better know how to implement it when showtime comes!

Everybody has different strengths and weaknesses. Some people struggle with the theory part of this material but fly through the application, while others experience the opposite. Some of you are just loving every minute of it, handling both the concepts and their implementation with ease. But no matter which category you fall into, the fact remains that you simply have to know this stuff—both in theory and in practice—if you want to pass the test and be capable of actually working with the technologies competently.

And that’s exactly the goal of this chapter—to pull together theory and execution and integrate them into one tight package. I’ve got to be honest with you though; achieving this goal is going to take awhile. This chapter is one of the longest in this book!

Configuring Cisco IOS IPSec for Pre-Shared Keys Site-to-Site

IPSec for pre-shared keys is the easiest of all of the IPSec implementations. Implementing IPSec requires that you configure an IKE policy, pre-shared keys, and IPSec, but it’s not very scalable because you’ve got to manually configure the pre-shared keys on the devices, plus manage them. This can become fairly tangled and messy in large networks. Hear that big sucking sound? Those are the man-hours being consumed if you use IPSec for pre-shared keys on a large network! It’s not exactly cost-effective—go for another option in a larger environment. In the next section, you’re going to learn the configuration tasks for IPSec and how to plan your approach to implementing IPSec so you can configure it correctly the first time.

By the time you’re done with this section, you’ll be able to implement site-to-site IPSec for pre-shared keys, so let’s get going!

Preparing for IKE and IPSec

Before you get into configuring IPSec utilizing pre-shared keys, you need to plan out your approach. Think of it as a football game—you don’t just show up at the field and play. You show up with a decided strategy to win the game, complete with a book of plays you plan to use depending on the circumstances and your opponent. You’ve also done your research, so you’re packing detailed notes on all their codes and signs. It’s pretty much the same thing for IPSec. You don’t just start configuring IPSec without first coming up with a solid plan of attack.

Here are five questions you need to answer that will help you develop a plan:

Can the devices you want to peer already ping each other? If not, you need to verify network connectivity. If yes, move on to the next question.

Does existing packet filtering currently allow IPSec traffic? If not, update the access lists to allow IPSec traffic. If yes, move on to the next question.

What’s the current configuration of the device? Knowing this will allow you to establish two things—the crypto map name already in use and interfaces that currently have crypto maps applied to them. Time to move on to the next question.

What IKE policy do you want to enforce between the devices that you’re going to peer? Asking yourself this question will make you think about the message-encryption and hash algorithms, the authentication method, and the key exchange parameters. These decisions should directly correspond with what you’ve outlined in your corporate security policy. That done, you’re ready for the next question.

What type of IPSec policy do you want to enforce between the devices with which you wish to peer? To answer this one, you’ll have to think about two factors: the IPSec mode you’re going to use and which IPSec transforms to use.

Okay, great—now that you’ve answered these questions (and documented your answers, of course), you’re ready to rock! The first step in configuring IPSec utilizing pre-shared keys is to configure IKE on each device.

244 Chapter 8 Cisco IOS IPSec Pre-Shared Keys and Certificate Authority Support

Configuring IKE

Once your IKE policy has been identified, configuring IKE is relatively simple. Configuring IKE with pre-shared keys is a four-step process:

1.Enable IKE.

2.Create the IKE policy.

3.Configure the IKE identity and pre-shared keys.

4.Verify IKE operation.

Enabling IKE

To configure IKE, it’s got to be enabled first. You enable IKE by entering the following command in global configuration mode:

crypto isakmp enable

Once the preceding command has been entered, IKE will be enabled on the device. If you ever need to disable it, enter the following command, also in global configuration mode:

no crypto isakmp enable

Don’t use the no crypto isakmp enable command lightly—disabling all IKE operation on a device can have serious ramifications.

Creating the IKE Policy

With IKE enabled, you now need to create the IKE policy. Doing this requires you to have already answered the following questions:

What priority will you give the policy? Lower numbers indicate a higher priority in the policy and vice versa. This is critical when a device has multiple IKE policies configured.

What type of message encryption will you use? The default is DES, but you can change it to 3DES if you have the right feature set.

What message hash will you use? The default is sha, but you can change it to MD5.

What authentication method do you want to use? The default is rsa-sig, but it can be changed to pre-shared or rsa-encr. The example in this book will use pre-shared keys.

What Diffie-Hellman group do you want to use? The default is 1, but it can be changed to 2. Group 1 is 768-bit Diffie-Hellman; group 2 is 1024-bit Diffie-Hellman.

What lifetime would you like to set for the IKE Security Association (SA)? The default is 86,400, but that can be changed.

Don’t forget that the policy you have set on one device must be the same as the policy you set on the devices you wish to peer with. The exceptions are: first, the priority given to the policy, which is locally significant; and second, the lifetime that’s negotiated during IKE phase 1.

To create the IKE policy, enter the following command in global configuration mode, where priority is a value between 1 and 10,000.

crypto isakmp policy priority

Once you enter this command, the IKE policy is created with all the default values, and the router is placed in IKE policy configuration mode. All of the configuration in this section is accomplished while in this mode.

Next, you need to specify which message-encryption algorithm to use by entering the following command:

encryption {des | 3des}

After configuring the message-encryption algorithm, you configure the message hash by entering the following command:

hash {sha | md5}

Now you configure the authentication method by entering the following command:

authentication {rsa-sig | rsa-encr | pre-share}

Because this section discusses only pre-shared keys, you need to use the pre-share keyword. Next, you configure the Diffie-Hellman group by entering the following command:

group {1 | 2}

All right, hang in there. You’re in the home stretch! To finish this off, you configure the IKE SA lifetime by entering the following command, where seconds is a value between 60 and 86,400:

lifetime seconds

Entering the commands discussed in this section is all you need to do if you want to change the default value or change a value that’s already been configured. If you want to create a new IKE policy or enter IKE policy configuration mode, you’ve got to enter the crypto isakmp policy priority command.

246 Chapter 8 Cisco IOS IPSec Pre-Shared Keys and Certificate Authority Support

Configuring the IKE Identity and Pre-Shared Keys

Okay, your IKE policy has been created and configured on all of the devices—nice! Now it’s time to set the IKE identity and configure the pre-shared key that is used during IKE negotiations to authenticate peers.

Because you’re reading this book, you probably know that a device can use either the router’s IP address or the router’s hostname for its identity. By default, devices use their IP address as their IKE identity. This is important because unless you want to set the device to use its hostname instead, or the device is already using the hostname and you want to change it back to use the device’s IP address, you don’t need to configure a thing. To accomplish one of these tasks, just enter the following command in global configuration mode:

crypto isakmp identity {address | hostname}

If you choose to use a device’s hostname for IKE identity, make sure a DNS server is available for name resolution. Your other option is to manually enter the hostname of the device in the hostname table of all devices you wish to peer with.

Once you’ve nailed the IKE identity, it’s time to configure the pre-shared key. But first, you need to determine which pre-shared key to use on all the devices you wish to peer. When you’ve made your decision, enter the following command in global configuration mode on each device, where keystring is the pre-shared key you want to use, peer-address is the IP address of the remote device, and peer-hostname is the hostname of the remote device:

crypto isakmp key keystring {address peer-address | hostname peer-hostname}

This command needs to be entered on a device for each device it wishes to peer with.

Use the address keyword if the remote peer is using an IKE identity of the address. Use the hostname keyword if the remote peer is using an IKE identity of the hostname.

I know, I know! That was a ton of input, so let’s take a second to put it all together visually. The following graphic illustrates a potential network for setting up a VPN. Remember our corporate network example? You’ll be using it again for Exercise 8.1.

Word of advice: If you are taking the SECUR exam, which is probably a sure bet because you’re reading this book, it would be wise to set up some routers and configure the next lab!

E X E R C I S E 8 . 1

Setting Up a VPN Using IKE

In this exercise, I’m going to guide you through configuring IKE using a VPN between the Lab_A device and the Lab_B device with the following parameters:

Lab_A interface Serial 0/0 with IP address 10.1.1.1 /24

248 Chapter 8 Cisco IOS IPSec Pre-Shared Keys and Certificate Authority Support

E X E R C I S E 8 . 1 ( c o n t i n u e d )

Lab_B interface Serial 1/0 with IP address 10.1.1.2 /24

Lab_A IKE policy priority equals 2

Lab_B IKE policy priority equals 2

3DES message encryption

MD5 message hash

Authentication method is pre-share

Default Diffie-Hellman group for both devices

Default IKE SA lifetime for both devices

IKE Identity is address for both devices

Pre-shared key is cisco

Enter the following commands to create your IKE policies:

Lab_A#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Lab_A(config)#crypto isakmp enable

Lab_A(config)#crypto isakmp policy 2

Lab_A(config-isakmp)#encryption 3des

Lab_A(config-isakmp)#hash md5

Lab_A(config-isakmp)#authentication pre-share

Lab_A(config-isakmp)#exit

Lab_A(config)#crypto isakmp key cisco address 10.1.1.2

Lab_A(config)#^Z

Lab_A#

Lab_B#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Lab_B(config)#crypto isakmp enable

E X E R C I S E 8 . 1 ( c o n t i n u e d )

Lab_B(config)#crypto isakmp policy 2

Lab_B(config-isakmp)#encryption 3des

Lab_B(config-isakmp)#hash md5

Lab_B(config-isakmp)#authentication pre-share

Lab_B(config-isakmp)#exit

Lab_B(config)#crypto isakmp key cisco address 10.1.1.1

Lab_B(config)#^Z

Lab_B#

Did you notice that the Diffie-Hellman group command and the lifetime command weren’t entered? That’s because the default settings were used, so you didn’t need to use those commands.

Once the configuration is complete, you must always be able to verify what you have configured. The next section will explain how to do this.

Verifying the IKE Policy

Now that the IKE policies have been configured, you need to verify that the device accepted them. You do this via the show crypto isakmp policy command, which displays the IKE policies currently configured on a device. With this in mind, let’s verify the IKE policies on the Lab_A and Lab_B devices:

Lab_A#show crypto isakmp policy