Configuring IPSec

The process of setting up a VPN can seem daunting; in fact, it is probably the most complex task you will perform in achieving your CCNP certification. The reason is that there are about as many commands and options to use as terms and definitions we just discussed. The trick is to break it down into manageable chunks. The four major tasks are preparing for IKE and IPSec, configuring IKE, configuring IPSec, and testing and verification. As we begin to look at the IPSec commands, it is important to note that we will not examine all the different options available. We focus on the most used and tested choices.

Task 1: Preparing for IKE and IPSec

Configuring IKE and IPSec can be complicated, but you can resolve a number of issues before the deployment with careful planning. You need to design the different policies to be used, ensure that current configurations work, and ensure that they will be compatible in the future.

Step 1: Determining IKE (IKE Phase 1) Policy

One of the most important steps is planning. A properly planned out policy helps eliminate needless troubleshooting and frustration. The goal is to minimize or eliminate misconfiguration. There are a number of items to examine:

Determine the key distribution method How your keys are distributed is usually decided by the number and locations of your IPSec peers. With small networks, using manually configured preshared keys might be easiest; for a large number of peers, using a CA is the best choice because it scales more easily and is easier to manage.
Determine the authentication method Your authentication method is based on your key-distribution choice. You use preshared keys for a manual environment but RSA signatures or nonces in a CA configuration. Preshared keys are covered on the exam and throughout this text.
Identify the IPSec peer's IP addresses and host names You need to identify either through hostnames or IP addresses all the peers and preshared keys that will be in use.
Determine ISAKMP policies for peers An ISAKMP policy is a combination of all the security parameters in IKE negotiation. You should determine the policies ahead of time. Any one device can have a number of policies, but you can only build a secure channel if there is a match. We examine the policies in Task 2, Step 2.

Step 2: Determining IPSec (IKE Phase 2) Policy

Once again, a key step is planning. This time, however, you are planning for IPSec. Properly planned, it helps in configuring and troubleshooting. The goal is still to minimize or eliminate configuration errors. There are a number of steps:

Determine the IPSec algorithms Determine the type of security that will be applied to the protected data. You might need to choose it based on performance, strength, and laws.
Select transforms and transform sets The IPSec algorithms are known as transforms and transform sets. These are your AH and ESP choices. AH is rarely used because it is not compatible with NAT or port address translation (PAT), and its functionality has been added to other ESPs. We look at the options in Task 3, Step 1.
Identify IPSec peer details Identify the hostnames or IP addresses of all the peers.
Identify IPSec peer details Identify which networks, hosts, and applications should be protected between the local and remote peers.
Choose manual or IKE-built SAs You can use either manually created SAs or IKE-established SAs. The preferred and covered method is the IKE SAs.

Step 3: Checking the Current Configuration

You need to examine the routers' current configurations to see whether there has been a previous IPSec deployment. The idea is that you don't want to reinvent the wheel if you don't need to. You can save time if you can use previously configured IKE and IPSec policies. At the least, you need to know that they exist so you can plan accordingly. Some of the commands you use are show running-config, show crypto isakmp policy, show crypto map, and show crypto ipsec transform-set. We look at these commands later in the "Verifying IKE Configuration" and "Verifying IPSec Configuration" sections.

Step 4: Ensuring That the Network Works Without Encryption

This step might sound like an obvious guideline, but you would be surprised how many people wonder whether they were able to reach the intended network before encryption was set up. It is important to see whether you can ping, Telnet, log in, and so on before you set up IPSec. If it worked before and it doesn't now, you know where to start troubleshooting. If it doesn't work now and you don't know whether it did before, where should you start to look for a cause?

Step 5: Ensuring That Access Control Lists Are Compatible with IPSec

IKE and IPSec use different ports and protocols to work. You need to make sure any access control lists (ACLs) allow those specific settings through. Specifically, ISAKMP uses UDP port 500, ESP uses IP protocol number 50, and AH uses IP protocol 51.

Task 2: Configuring IKE

At this point, we are ready to start the configuration of the router; specifically, we start with setting up IKE. This task includes enabling ISAKMP and configuring policies, preshared keys, and verification.

Step 1: Enabling or Disabling IKE

The first step to configuring IKE is to enable it. ISAKMP or IKE is enabled from global config mode, and the command is simply crypto isakmp enable. To disable, just add no in front of the command:

 RouterA(config)#crypto isakmp enable

On newer releases of IOS, ISAKMP is enabled by default so it does not show up in your configuration files unless it is disabled.

Step 2: Creating IKE Policies

The next thing is to configure an IKE policy. Remember, you need to have matching policies on each peer. From config mode, you enter crypto isakmp policy priority to go into a sub-config mode (config-isakmp), as shown in Listing 13.1.

Listing 13.1 IKE policy configuration example

 RouterA(config)#crypto isakmp policy 50 RouterA(config-isakmp)#encryption des RouterA(config-isakmp)#hash md5 RouterA(config-isakmp)#authentication pre-share RouterA(config-isakmp)#group 2 RouterA(config-isakmp)#lifetime 86400 RouterA(config-isakmp)#exit RouterA(config)#

The priority setting is configurable between 1 and 10,000. Now that you have seen the command, let's examine the different policy settings in Table 13.1.

Table 13.1. IKE Policy Parameters
Parameter	Choice	Keyword	Default
Encryption algorithm	DES 3DES	des 3des	DES
Hash algorithm	MD5 SHA-1	md5 sha	SHA-1
Authentication method	Preshared keys RSA nonces RSA signatures	pre-share rsa-encr rsa-sig	RSA signatures
Key exchange (D-H)	768-bit D-H 1024-bit D-H	1 2	768 bit
IKE SA lifetime	60 to 86,400 seconds (sec)	#	86,400 sec (1 day)

If you have not specified any ISAKMP policies, the default settings from the table are used. If you create a policy and only define some settings, the default settings are used for the undeclared values. Earlier, we mentioned that each peer must negotiate with the other peer to find a matching policy. Policies have a number, and the lower-numbered policies are tried first until there is a match. Take the time to plan out the policies and their numbers so you get the desired results.

Step 3: Configuring ISAKMP Identity

During IKE negotiations, peers authenticate each other using the preshared key and the ISAKMP identity. The identity can be either an IP address or a hostname; the IP address is the default. If you use hostnames, you either need to have DNS set up or a host entry configured on your router. The command to set the identity is crypto isakmp identity {address | hostname}:

 RouterA(config)#crypto isakmp identity address

Once again, because address is the default, it is not displayed in configuration files. If you use hostname, however, you can see it.

Step 4: Configuring Preshared Keys

You now need to configure the preshared keys that IKE will use for authentication. The command has two options based on address or hostname. Also, the preshared key must be identical on each peer. The command is crypto isakmp key keystring address peer-address or crypto isakmp key keystring hostname peer-hostname:

 RouterA(config)#crypto isakmp key secret123 address 172.16.1.5 RouterA(config)#crypto isakmp key passwd58 hostname RouterC

The preshared keys are only if the negotiated IKE policy declares their use. It is recommended as a security precaution to use different passwords for different peers, but remember that each side's password needs to match.

Preshared keys might be the easiest, but they don't scale nearly as well as a CA.

Step 5: Verifying IKE Configuration

The easiest step in the process, verification, is the last one, assuming everything is correct. You can only verify some of your settings by viewing your running-config because defaults do not appear. You can, however, view your policies in their entirety by typing show crypto isakmp policy:

 RouterA#show crypto isakmp policy Protection suite of priority 50         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).         hash algorithm:         Message Digest 5         authentication method:  Pre-Shared Key         Diffie-Hellman group:   #2 (1024 bit)         lifetime:               86400 seconds, no volume limit Default protection suite         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).         hash algorithm:         Secure Hash Standard         authentication method:  Rivest-Shamir-Adleman Signature         Diffie-Hellman group:   #1 (768 bit)         lifetime:               86400 seconds, no volume limit RouterA#

Notice that you see the policy you configured, number 50, and the default. If you had set up a number of other policies, they would be listed as well. Remember that IKE negotiates using the lowest-numbered policy first and then continues higher. If no policies match, then the default policy is attempted. If it doesn't match, an IKE SA is not built, and that was the whole purpose.

Make sure you can describe some of the features and benefits of IKE/ISAKMP.

Task 3: Configuring IPSec

The next major task is to configure the IPSec parameters that were defined in the planning stages. These settings include the transform sets, SA lifetimes, access lists, and crypto maps. After you define and configure them, you then apply them to an interface.

Step 1: Configuring Transform Sets

A transform set defines the combinations of IPSec algorithms for encryption and authentication. Transform sets work like IKE policies in that you need to have matched sets on each peer. Transform sets are negotiated in IKE Phase 2. A transform set describes authentication (such as AH), encryption (such as ESP), and mode (tunnel versus transport). The syntax for creating a transform set is crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]. It is quite common to have a transform set and only one transform defined:

 RouterA(config)#crypto ipsec transform-set secure esp-3des esp-sha-hmac RouterA(cfg-crypto-trans)#exit

Remember from earlier discussions that an AH is not used very often because AH functionality was added to some of the ESP transforms. Table 13.2 lists the different options. You can specify up to one AH, one ESP encryption, and one ESP authentication.

Table 13.2. Supported Transforms
Transform	Explanation
ah-md5-hmac	AH transform; authentication based on MD5.
ah-sha-hmac	AH transform; authentication based on SHA.
esp-des	ESP transform; encryption based on a 56-bit cipher.
esp-3des	ESP transform; encryption based on a 168-bit cipher.
esp-md5-hmac	ESP transform; authentication based on MD5. Must be used with esp-des or esp-3des.
esp-sha-hmac	ESP transform; authentication based on SHA. Must be used with esp-des or esp-3des.
esp-null	ESP transform; specifies that there is no encryption. Not recommended for a production environment.

Step 2: Configuring Global IPSec Lifetimes

The lifetime of an SA is governed by the command crypto ipsec security-association lifetime {seconds seconds | kilobytes kilobytes}. The seconds value can be anywhere from 120 to 86,400; the default is 3600 sec. The kilobytes can be anywhere from 2560 to 536,870,912; the default is 4608. The settings allow the SAs to be refreshed at regular controlled intervals. The longer an SA is established, or the more data that passes through, the more vulnerable it is. With the defaults, the parameters are recalculated and you are more secure. Cisco recommends that you use the defaults.

Step 3: Creating Crypto ACLs

The purpose of a crypto access list is to specify what traffic should be protected and what traffic is allowed in the clear. With crypto access lists, a permit means encrypt and deny means do not encrypt. The lists are symmetrical, so you need a mirrored ACL on each router. The syntax is the same as that for a traditional access list. You usually employ extended access lists for greater control over the encryption:

 RouterA(config)#access-list 100 permit tcp host 192.168.1.5 host 192.168.2.10

Later when the ACL is applied, it specifies that all traffic between the two hosts using TCP needs to be encrypted.

ACLs used for crypto maps specify what should or shouldn't be encrypted. They do nothing about restricting traffic, with the exception of denying received traffic that should've been encrypted. Remember, they are symmetrical with the VPN peer.

Step 4: Creating Crypto Maps

Crypto maps are the glue for putting together all the various IPSec configurations. Just like the ISAKMP policies configured to build the IKE SAs, the crypto map defines the IPSec SAs. You specify a number of things, such as the method of SA establishment, the type of transform sets applied, the type of traffic to be encrypted or not, the identity of the peer and where the traffic should be sent, the local address to be used for the IPSec traffic, and any other parameters that might be necessary in defining an IPSec SA.

You can have only one crypto map per interface, which should not be a problem; inside each crypto map, you can define groups of settings that are applicable to different peers. The different groups are defined by sequence numbers, and once again, lower sequence numbers are negotiated first. We examine first the crypto map command and its three main options and then its sub-config mode. The command looks like crypto map map-name seq-num [cisco | ipsec-manual | ipsec-isakmp]. Table 13.3 describes the parts of the command.

Table 13.3. The crypto map Command
Parameters	Explanation
map-name	The name you assign the crypto map.
seq-num	The number assigned to the crypto map entries. Remember that the number is used as a grouping and that lower numbers are negotiated first.
cisco	Indicates that Cisco encryption technology (CET) should be used instead of IPSec, which is the default. Newer IOS releases have it removed from the command, so CET encryption is now end-of-life, IPSec being its replacement.
ipsec-manual	Specifies that IKE will not establish the IPSec SAs.
ipsec-isakmp	Specifies that IKE will establish the IPSec SAs.
dynamic	Specifies that a preexisting crypto map be used. If you use this option, no additional configuration is necessary because the parameters are pulled from the referenced crypto map.
dynamic-map-name	The name of the crypto map to be used as a template.

Once you enter the crypto map command, the router prompt changes and places you in config-crypto-map mode, as shown in the example. Following the example, we cover the options in this new mode:

 RouterA(config)#crypto map myfirstmap 10 ipsec-isakmp RouterA(config-crypto-map)#

Now that you have seen the beginnings of the crypto map command, you need to look at how the command works and its syntax. Table 13.4 shows just that. Note the match and set options.

Table 13.4. The config-crypto-map Command
Command	Explanation
match address [access-list number \| name]	Specifies the access list that defines the traffic which should be encrypted. It is the access list you built in the preceding step. You can call it by a number or name, depending on how it was built.
set	Used to define the peer, PFS, SA lifetime, and transform set.
peer [address \| hostname]	Defines the peer to be used by IPSec.
pfs [group1 \| group2]	Specifies D-H group 1 or group 2.
security-association lifetime	Sets the lifetime in sec or KB.
transform-set [set-name(s)]	Defines the transform set that will be used to protect your data. (You can have up to six sets.)
no	Used to remove any set or match commands.
exit	Exits the crypto map configuration mode.

Now that you have seen the parameters that you can control inside the crypto map command, let's examine a working example from start to finish, as shown in Listing 13.2. Notice that the configuration starts with either the set or match keywords. Also, you can use the no option to remove a setting.

Listing 13.2 Crypto map example

 RouterA(config)#crypto map myfirstmap 10 ipsec-isakmp RouterA(config-crypto-map)#match address 100 RouterA(config-crypto-map)#set peer 172.16.1.5 RouterA(config-crypto-map)#set pfs group2 RouterA(config-crypto-map)#set security-association lifetime seconds 86400 RouterA(config-crypto-map)#set transform-set secure RouterA(config-crypto-map)#exit RouterA(config)#

In the section "Testing and Verifying IPSec," you can see the show crypto map command used to verify the settings.

Step 5: Configuring IPSec Crypto Maps

Once again, the last step is one of the easiest. Now that you have built your crypto maps, you need to apply them. You enter into interface configuration mode and enter the command crypto map map-name:

 RouterA(config)#int serial 2/1 RouterA(config-if)#crypto map myfirstmap

That's it. You should now have a crypto map applied to the correct interface, and at this point, you should be ready to test your shiny brand new IPSec VPN.

Task 4: Testing and Verifying IPSec

You can use a number of commands to test and verify that IPSec is up and running. We have looked at a few to get to this point and have a few more to discuss. The fact that you are able to communicate to a peer doesn't mean that all is secure; how do you know that the conversation you are having is encrypted? We review a couple commands and introduce you to a few others, not only for troubleshooting a broken VPN, but also to verify that one is working as it should.

We hope that you tested that you had connectivity before you set up encryption. If you didn't, you're on your own. Remember that IPSec doesn't happen all at once and that it is a multistep process. That aids us in troubleshooting.

The first step is to examine the IKE policies with a show crypto isakmp policy. You need to check that you have matching options on each peer:

 RouterA#show crypto isakmp policy Protection suite of priority 50         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).         hash algorithm:         Message Digest 5         authentication method:  Pre-Shared Key         Diffie-Hellman group:   #2 (1024 bit)         lifetime:               86400 seconds, no volume limit Default protection suite         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).         hash algorithm:         Secure Hash Standard         authentication method:  Rivest-Shamir-Adleman Signature         Diffie-Hellman group:   #1 (768 bit)         lifetime:               86400 seconds, no volume limit RouterA#

ISAKMP policies are negotiated by priority number, from lowest to highest. If a match isn't found, the default policy is tried.

Next, check whether an ISAKMP SA has been established, using the show crypto isakmp sa command:

 RouterA#show crypto isakmp sa dst             src             state           conn-id    slot 172.16.1.5    172.16.1.1     QM_IDLE         47     5 RouterA#

From the output, you can see that you have an SA for IKE; the IDLE specifies that it's built but waiting. The next thing to check is that you have matching transform sets on each peer. To view your configured transforms, enter show crypto ipsec transform-set. You will see something similar to the following based on the transforms you have configured:

 RouterA#show crypto ipsec transform-set Transform set secure: { esp-des esp-sha-hmac  }    will negotiate = { Tunnel,  }, RouterA#

If you verified that you have matching transforms, you should check whether an IPSec SA has been established. Type show crypto ipsec sa. The command output has been truncated, but the important pieces are at the top, specifically the crypto map in use and the IP addresses for the peers. You can also see a packet counter for the number of packets encrypted and decrypted:

 Router# show crypto ipsec sa interface: Ethernet0     crypto map tag: router-alice, local addr. 172.16.1.1    local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/0/0)    remote ident (addr/mask/prot/port): (172.16.1.5/255.255.255.255/0/0)     current_peer: 172.16.1.5     PERMIT, flags={origin_is_acl,}     #pkts encaps: 10, #pkts encrypt: 10, #pkts digest 10     #pkts decaps: 10, #pkts decrypt: 10, #pkts verify 10     #send errors 0, #recv errors 0      local crypto endpt.: 172.16.1.1, remote crypto endpt.: 172.16.1.5      path mtu 1500, media mtu 1500      current outbound spi: 20890A6F

The next command to use will verify your crypto maps. Earlier, we mentioned that you can have only a single map per interface but that a map could have multiple entries. In the example produced by the show crypto map command, you can see that we have a map built called myfirstmap and that it has two sets of parameters. The first one, number 10, connects to the 172.16.1.5 address with its specific parameters. The second policy goes to a different address with slightly different security parameters:

 RouterA#show crypto map Crypto Map "myfirstmap" 10 ipsec-isakmp         Peer = 172.16.1.5         Extended IP access list 100             access-list 100 permit tcp host 192.168.1.5 host 192.168.2.10         Current peer: 172.16.1.5         Security association lifetime: 4608000 kilobytes/86400 seconds         PFS (Y/N): Y         DH group:  group2         Transform sets={ secure, }         Interfaces using crypto map myfirstmap: Crypto Map "myfirstamp" 20 ipsec-isakmp         Peer = 172.16.20.5         Extended IP access list 110             access-list 110 permit tcp host 192.168.1.5 host 192.168.7.10         Current peer: 172.16.20.5         Security association lifetime: 4608000 kilobytes/3600 seconds         PFS (Y/N): Y         DH group:  group1         Transform sets={ secure, }         Interfaces using crypto map myfirstamp: RouterA#

A command that is not covered or tested but is quite interesting is the show crypto engine connections active. It gives you a packet counter for encrypted packets as well as the algorithms that are in use. If you're still unable to get your VPN up and working, it must be time for the debug commands. The two debug commands that are covered are debug crypto isakmp and debug crypto ipsec. Each will show you the different steps that are happening during negotiations. They produce pages of output, so remember that debug commands can have an adverse effect on your network and should only be used appropriately. After issuing the debug commands, you will most likely want to force the SAs to be reestablished. Enter a clear crypto sa command, which will disrupt anyone using the VPN tunnel until it is reconnected but will cause the SAs to be reestablished.

ISAKMP Error Messages

There are two common messages that you might receive if ISAKMP is having problems:

 %CRYPTO-6-IKMP_SA_NOT_AUTH: Cannot accept Quick Mode exchange ...  SA is not authenticated!

This message indicates that the other side tried to negotiate ISAKMP without being authenticated. You need to examine the peer router. The next error message follows:

 The %CRYPTO-6-IKMP_SA_NOT_OFFERED: Remote peer %15i responded with attribute ...  not offered or changed.

This message indicates that you where unable to negotiate a matching ISAKMP policy and that the other side responded with a policy not requested.