Configure IPSec Encryption Tasks

Step 1-1 Identify IPSec Peers

An important part of defining a comprehensive IPSec policy is to identify the IPSec peer pairs that must be configured. In the chapter scenario, expanded in Figure 10-2, each remote site will connect only to the Main Office router and, therefore, requires only simple configuration. The Cisco router at the Main Office must be configured for peer communications with each of the remote sites and telecommuter(s). Each peer must support IPSec. Because many different types of peer devices exist, it’s important to identify all potential peers and determine their VPN capabilities. Possible peer devices could include, but aren’t limited to, the following:

• Cisco routers

• Cisco Secure PIX Firewalls

• Cisco Secure VPN 3000 Concentrators

• Cisco Secure VPN 3002 Hardware Client device

• Cisco Secure VPN Software Client

• Other vendor IPSec products that conform to IPSec standards

• CA servers

  
  Figure 10-2: Chapter scenario network showing peer connections

It’s important to recognize that IPSec features supported and default settings can vary between Cisco product families, as well as versions of the operating system (OS) being used. This is most important for the Main Office router in the scenario because it must be able to establish common IKE and IPSec policies with each remote device. This also demonstrates why many companies limit the number of devices supported by defining standards for telecommuters or branch offices.

The result of this analysis might be a table like the following:

Step 1-2 Determine the IKE (IKE Phase 1) Policies

IKE is a hybrid protocol that implements the Oakley key exchange and the Skeme key exchange inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. (ISAKMP, Oakley, and Skeme are security protocols implemented by IKE.)

The purpose of IKE Phase 1 is to authenticate the peers and negotiate a secure session between those peers. This creates a stable platform for IKE Phase 2 to negotiate the IPSec tunnel. The word “negotiate” makes this sound like a complex process, which might involve contentious arguments late into the night. In reality, at each phase, the session instigator submits one or more security policies, which will then be compared by the destination peer against its preconfigured security policies. If a match is found, a session is then established. If no match is found, the session is terminated. From a practical standpoint, if a VPN session can’t be established between the two peers, then one of the devices must be configured to include a set of policies acceptable to the other.

The objective here is to develop one or more IKE security policies based on the overall company security policy. Each policy will require decisions about five security options: authentication method, encryption algorithm, hashing algorithm, Diffie-Hellman group, and SA lifetime. This can make IKE seem more complicated than it is. To get some perspective, we aren’t configuring a connection to an unknown or an untrusted entity. Instead, we’re connecting a branch of the company to the main office system. Chances are both are governed by the same security policy so, while some choices must be made, the list of possibilities shouldn’t be infinite.

In many cases, the decision could be that 3DES will be the encryption, MD5 will perform hashing functions, preshared keys will be used for authentication, and so forth, and that would be configured on each router. So, why have multiple policies with different option combinations? The answer depends on the router and the number of VPN connections that it needs to support. In our example, if each branch only connects to the main office, then they only need the policy that matches the main office router.

The main office router could need a couple of IKE policy choices because all branch offices might be unable to support the same policy. This might not be a vendor or a product platform issue, but a legal issue. While all the North American branches can be configured with 3DES encryption, export controls could prevent the foreign branches from using anything but DES. So, a second policy needs to be available for those connections.

Step 1-3 Determine the IPSec (IKE Phase 2) Policies

Once the choices are made for IKE Phase 1, it’s time to turn to those parameters required to complete IKE Phase 1. This is where the IPSec tunnel is negotiated and, ultimately, the IPSec SAs established. As in Phase 1, the goal is to define one or more sets of IPSec security parameters defining the IPSec security policy, based on the overall company security policy.

The information gathered is required in Task 3 when IPSec is configured. To facilitate that process, gather the following information into a table similar to the one developed for Phase 1 for each peer for which sessions will be established.

Most of the choices to be configured, such as peer address and host name, are straight-forward. The transforms or, if necessary, the transform sets, involve determining the security features required, and then striking a balance between security level and performance implications. Chapter 9 introduced Transforms and Task 3, later in this chapter, looks at configuring them.

The following table might represent the IPSec values for the chapter scenario:

Step 1-4 Check the Current Configuration

It’s important to check the current Cisco router configuration to see if any existing IPSec policies are configured that could be useful for, or interfere with, the new IPSec policies. If appropriate, previously configured IKE and IPSec policies can be used to save configuration time. This section looks at three commands useful in discovering existing IKE and IPSec policies.

Rtr2#show run
!
hostname Rtr2
!
enable secret 5 $1$ojfF$eAp7xa0hU4E678XaibAQa
! 
crypto isakmp policy 1
 hash md5
 authentication pre-share
crypto isakmp key test_key1 address 10.0.1.21 
!
crypto ipsec transform-set trans1 esp-3des 
crypto ipsec transform-set trans2 ah-md5-hmac esp-des 
crypto ipsec transform-set trans3 esp-sha-hmac esp-null
!
crypto map test_map1 1 ipsec-isakmp ?
 set peer 10.0.1.21
 set security-association lifetime seconds 43200
 set transform-set trans1 trans2 trans3
 match address 101
!
interface Ethernet0
 ip address 192.168.130.1 255.255.255.0
 no mop enabled
!
interface Serial0
 ip address 10.0.50.2 255.255.255.252
 no ip mroute-cache
 no fair-queue
 crypto map test_map1
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.0.50.1
access-list 101 permit tcp 192.168.130.0 0.0.0.255 192.168.0.0 0.0.127.255
dialer-list 1 protocol ip permit
!

Rtr1#show crypto isakmp policy
Protection suite of priority 100
 ???????encryption algorithm: ??DES - Data Encryption Standard (56 bit keys).
 ???????hash algorithm: ????????Secure Hash Standard
 ???????authentication method: ?Pre-Shared Key
 ???????Diffie-Hellman group: ??#2 (1024 bit)
 ???????lifetime: ??????????????43200 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
Rtr1#

Rtr1#show crypto map
Crypto Map "testmap" 50 ipsec-isakmp
 ???????Description: VPN Link to branch office in Tacoma, WA
 ???????Peer = 10.0.50.2
 ???????Extended IP access list 125
 ???????????access-list 125 permit tcp 192.168.0.0 0.0.127.255 192.168.130.0
 ?0.0.0.255
 ???????Current peer: 10.0.50.2
 ???????Security association lifetime: 2300000 kilobytes/1800 seconds
 ???????PFS (Y/N): Y
 ???????DH group: ?group2
 ???????Transform sets={ CPU-HOG, }
 ???????Interfaces using crypto map testmap:
 ???????????????????Serial0
Rtr1#

Rtr1# show crypto ipsec transform-set 
Transform set MD5-DES: { esp-des esp-md5-hmac ?}
 ??will negotiate = { Tunnel, ?},

Transform set DES-ONLY: { esp-des ?}
 ??will negotiate = { Tunnel, ?},

 Transform set CPU-HOG: { ah-md5-hmac ?}
 ??will negotiate = { Tunnel, ?},
 ??{ esp-des esp-md5-hmac ?}
 ??will negotiate = { Tunnel, ?},

Transform set AH-ONLY: { ah-sha-hmac ?}
 ??will negotiate = { Tunnel, ?},
Rtr1#

Step 1-5 Ensure the Network Works Without Encryption

All peer-to-peer connectivity must be verified before configuring IPSec encryption. Basic troubleshooting techniques become more difficult, if not impossible, once encryption is in place.

While the router ping command can be used to verify basic connectivity between peers, equally important is that all important applications and related data are confirmed to be accessible. This can only be accomplished by testing those applications before beginning IPSec configuration.

Skipping this step can lead to wasted time trying to debug IPSec configuration only to discover eventually that the underlying connectivity was never tested. A simple rule of thumb is this type of mistake is always exposed when it can embarrass you the most.

Step 1-6 Ensure Access Control Lists Are Compatible with IPSec

Make certain any existing access lists on VPN device and perimeter router don’t block IPSec traffic. Perimeter routers frequently implement restrictive security policies using ACLs. These policies often deny all inbound traffic that isn’t responding to a specific outbound request. This restriction often blocks inbound IPSec traffic necessary to establish a VPN session.

Specific permit statements must be added to the inbound ACL to allow IPSec traffic. The following ports and protocol access should be left open:

• IKE/ISAKMP UDP port 500/keyword: isakmp

• Encapsulating Security Payload (ESP) IP protocol number 50/keyword: esp

• Authentication Header (AH) IP protocol number 51/keyword: ahp

The first step is to use the show access-lists command to determine if any ACLs will block IPSec traffic.

Assuming an inbound ACL is causing problems, it must be edited, placing entries at the beginning to permit IPSec traffic. The following shows an example of the lines that should be added to Rtr2’s existing ACL 110.

Rtr2# show running-config 
! 
interface Serial 0 
 ip address 10.0.50.2 255.255.255.252 
 ip access-group 110 in 
! 
access-list 110 permit ahp host 10.0.1.21 host 10.0.50.2 
access-list 110 permit esp host 10.0.1.21 host 10.0.50.2 
access-list 110 permit udp host 10.0.1.21 host 10.0.50.2 eq isakmp 
 ???---balance of ACL statements---

Step 2-1 Enable or Disable IKE

The first step in configuring IKE is to make sure IKE is globally enabled. While IKE is enabled globally by default, the crypto isakmp enable command makes sure the feature is on. Use the no form of the command to disable IKE. Because IKE is a global mode command, it needn’t be enabled or disabled for individual interfaces. Some circumstances might warrant using an ACL entry to block ISAKMP access (UDP port 500) on interfaces not being used for IPSec to reduce the chances of a denial of service (DoS) attack. The command syntax and an example follow.

Rtr2(config)# crypto isakmp enable Rtr2(config)# no crypto isakmp enable

Step 2-2 Create IKE Policies

Now, it’s time to define a suite of ISAKMP (IKE) policy details gathered during the planning task, Task 1, Step 2 (repeated in the following with defaults in italics). The goal is to create a suite of IKE policies, so you can establish IKE peering between two IPSec endpoints.

Using the scenario example, Rtr2 only needing to connect to Rtr1, might be configured with only the preferred (most secure) set of parameters because that set will also be on Rtr1. On the other hand, Rtr1, needing to peer with various devices both domestically and internationally, might need multiple policies to accommodate the different peers. The trick is to configure the policies, so the preferred policy is evaluated by the peer first, and then the second and third choices. This ensures the agreed policy is always the highest mutually agreeable choice.

Rtr1#conf t
Rtr1(config)#crypto isakmp policy 100
Rtr1(config-isakmp)#authentication {pre-share | rsa-encr | rsa-sig}
Rtr1(config-isakmp)#encryption {des | 3des} ?(depending on feature set)
Rtr1(config-isakmp)#hash {md5 | sha}
Rtr1(config-isakmp)#group {1 | 2}
Rtr1(config-isakmp)#lifetime <60 to 86400 seconds>

Rtr1(config)#crypto isakmp policy 100
Rtr1(config-isakmp)#authentication pre-share ?
Rtr1(config-isakmp)#encryption 3des
Rtr1(config-isakmp)#hash sha
Rtr1(config-isakmp)#group 2
Rtr1(config-isakmp)#lifetime 43200
Rtr1(config-isakmp)#exit

Rtr1#conf t
Rtr1(config)#crypto isakmp policy 200
Rtr1(config-isakmp)#authentication pre-share
Rtr1(config-isakmp)#group 2
Rtr1(config-isakmp)#lifetime 43200
Rtr1(config-isakmp)#crypto isakmp policy 300
Rtr1(config-isakmp)#authentication pre-share
Rtr1(config-isakmp)#hash md5
Rtr1(config-isakmp)#exit

Rtr1#show crypto isakmp policy
Protection suite of priority 100
 ???????encryption algorithm: ??3DES - Triple DES (168 bit keys).
 ???????hash algorithm: ????????Secure Hash Standard
 ???????authentication method: ?Pre-Shared Key
 ???????Diffie-Hellman group: ??#2 (1024 bit)
 ???????lifetime: ??????????????43200 seconds, no volume limit
Protection suite of priority 200
 ???????encryption algorithm: ??DES - Data Encryption Standard (56 bit keys).
 ???????hash algorithm: ????????Secure Hash Standard
 ???????authentication method: ?Pre-Shared Key
 ???????Diffie-Hellman group: ??#2 (1024 bit)
 ???????lifetime: ??????????????43200 seconds, no volume limit
Protection suite of priority 300
 ???????encryption algorithm: ??DES - Data Encryption Standard (56 bit keys).
 ???????hash algorithm: ????????Message Digest 5
 ???????authentication method: ?Pre-Shared Key
 ???????Diffie-Hellman group: ??#1 (768 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
Rtr1#

Step 2-3 Configure Preshared Keys

IPSec peers authenticate each other during IKE negotiations using the preshared key and their IKE identity. The IKE identity can either be the device IP address or the host name. The router IOS defaults to the IP address and doesn’t add a line to the configuration, unless the host name option is used.

To use the host name identity method, use the global crypto isakmp identity command. The no form of this command resets the default value (address). The command syntax is as follows:

Rtr1(config)#[no] crypto isakmp identity {address | hostname}
Rtr1(config)#crypto isakmp identity hostname

Using the host name identity method makes the most sense if a DNS server is available on the network to resolve the name. If not, the following example shows using an IP Host command entry on the router to handle the name resolution:

Rtr1(config)#ip host Rtr2.domain.com 10.0.50.2

Use the global crypto isakmp key command to configure a preshared authentication key whenever you specify preshared keys in an ISAKMP policy. Use the no form of the command to delete a preshared authentication key. The command syntax for both the address and the host name option is as follows:

Rtr1(config)#[no] crypto isakmp key keystring address peer-address [mask]
Rtr1(config)#[no] crypto isakmp key keystring hostname peer-hostname

A given preshared key is shared between two peer devices. While it’s possible for Rtr1 in the scenario to use the same key with all remote peers, the more secure approach is to use different keys with each pair of peers.

The next example shows IKE and preshared key (cisco123) for Rtr1 and Rtr2 using the address identity method. The IKE policies are compatible. Because the hash algorithm SHA-1 is the default value, it needn’t be configured.

Rtr1(config)#crypto isakmp key cisco123 address 10.0.50.2 
Rtr1(config)#crypto isakmp policy 100
Rtr1(config-isakmp)#authentication pre-share ?
Rtr1(config-isakmp)#encryption 3des
Rtr1(config-isakmp)#group 2
Rtr1(config-isakmp)#lifetime 43200
Rtr1(config-isakmp)#exit

Rtr2(config)#crypto isakmp key cisco123 address 10.0.1.21 
Rtr2(config)#crypto isakmp policy 100
Rtr2(config-isakmp)#authentication pre-share ?
Rtr2(config-isakmp)#encryption 3des
Rtr2(config-isakmp)#group 2
Rtr2(config-isakmp)#lifetime 43200
Rtr2(config-isakmp)#exit

Because both devices are under the administrative policies of a single entity, it makes sense that the policy priority value might be the same on both devices. That isn’t a requirement, though, and it would be unlikely when the two peers are from different organizations. The important thing is the parameters are the same.

Step 2-4 Verify the IKE Configuration

Use the show crypto isakmp policy command to display configured and default policies. An example of IKE policy for Rtr1 is shown in the Step 2-2 section. The show running-config command can also be useful, but the parameters using default values are omitted for brevity.

Step 3-1 Configure Transform Set Suites

In Chapter 9, an IPSec transform was defined as a single IPSec security protocol—AH or ESP—with its associated security algorithms and mode. Technically, a transform is the list of operations done on a dataflow to provide data authentication, data confidentiality, and since IOS v12.2(8) data compression. Some of the supported transform choices are shown in Figure 10-3.

Figure 10-3: IPSec transform options

The actual transforms supported might vary by device type. VPN devices could support a slightly different group than the PIX Firewall. The following are transforms supported by the IOS-based devices:

AH Transforms—Pick up to one:

ESP Encryption Transforms—Pick up to one:

ESP Authentication Transform—pick up to one, but only if you also selected the esp-des or esp-3des transform (not esp-rfc1829):

IP Compression Transform—pick up to one:

The compression algorithm used in the comp-lzs transform is Lempel-Ziv-Stac (LZS) compression, the most widely accepted lossless compression algorithm at this time. Compression is implemented on Layer 3, like hardware encryption, and can considerably reduce bandwidth requirements to support IP Security (IPSec).

Rtr1#conf t
Rtr1(config)#crypto ipsec transform-set MD5-DES esp-md5-hmac esp-des
Rtr1(cfg-crypto-trans)#crypto ipsec transform-set DES-ONLY esp-des
Rtr1(cfg-crypto-trans)#crypto ipsec transform-set AH-ONLY ah-sha-hmac
Rtr1(cfg-crypto-trans)#crypto ipsec transform-set CPU-HOG ah-md5-hmac
 ?esp-md5-hmac esp-des
Rtr1(cfg-crypto-trans)#exit
Rtr1(config)#

Step 3-2 Configure Global IPSec Security Association Lifetimes

IPSec security associations that use the shared secret keys time out together, based on the SA lifetime configured. This section looks at configuring a global lifetime value to be used when a particular crypto map entry doesn’t have lifetime values configured. When a router receives a negotiation request from a peer, it uses the smaller of the lifetime value proposed by the peer or the locally configured global lifetime value for the new security associations.

Two lifetimes exist—a “timed” lifetime and a “traffic-volume” lifetime that can be configured. The SA and keys expire when the first of these lifetimes expires.

Any changes made to a global lifetime are only applied when the crypto map entry doesn’t have a lifetime value specified. The change isn’t applied immediately to existing security associations, but will be used in subsequent SA negotiations.

Use the global crypto ipsec security-association lifetime command to set the global lifetime. For a timed lifetime, use the seconds form of the command. The kilobytes form causes the security association to time out after the specified traffic limit (in kilobytes) has been protected. The lifetime values are ignored for manually established security associations installed using an ipsec-manual crypto map command entry. To reset a lifetime to the default value, use the no form of the command. The command syntax is as follows: