12/10/2002 -- In the previous article (click here), we covered encryption, tunnels and how IPsec works. This time, we're going to get hands-on. Implementing IPSec on a Cisco device will vary in complexity, depending on what device you are configuring. This article will look at the IOS router, PIX firewall and VPN Concentrator. Each of these devices has a mechanism to configure IPSec via the command line or a GUI. Because training primarily concerns itself with the command line for the router and firewall, and with the GUI for the Concentrator, that's what we'll focus on.

The primary difference in configuring IPSec on these three devices is getting the instructions into the device. Routers have many different configuration modes in global configuration mode, while the PIX only has global configuration mode. This means that while the interfaces look the same, the commands used will be noticeably different between the two. While it is possible to configure the Concentrator via its command line, don't expect it to look anything like a router. Cisco purchased the VPN Concentrator from Altiga, and while they've made some modifications to the GUI, which is the primary configuration environment, little is normally configured in the Concentrator's command line environment (although everything that can be done with the GUI can be done in the command line).

It should go without saying, but I'll say it anyway: Design occurs before implementation. In other words, gather all the necessary data before you begin configuring. It's a heck of a lot easier to look at a sheet with device names, interfaces and IP addresses to find the right one than if everything is done in a disorganized manner. There are many configuration issues that will break an IPSec tunnel; minimize those that you have control over.

General Options
In some cases, the PIX doesn't have the same number of options available to it as the IOS router or Concentrator. You will need to decide how you're going to build the VPN tunnel, how you're going to protect the tunnel coming up and how to determine what traffic will be permitted to cross the tunnel. The following table lists the popular options that each device supports. We'll work with these for consistency.

IOS IPSec Configuration
The easy thing about configuring IPSec on a router is that everything is compartmentalized. The difficult part is knowing exactly what mode you have to be in to accomplish a certain task. Some of the modes are intuitive, while others aren't.

There are two modes you will have to become familiar with, in addition to global configuration mode. The first mode is where you configure IKE: ISAKMP configuration mode. Here, you need to establish a priority number for an IKE policy. The more important the policy, the lower the number. Numbering runs from 1 through 10000. Once in this mode, you can build the IKE policy by using the commands listed below.

If pre-shared keys is the method that will be used for IKE authentication, the key needs to be configured. To set up the key, the key must be kinked with the peer device. The first thing to do is decide how the peer will be identified, with an IP address or via host name. The second thing is to link the key to the peer.

router(config)# crypto isakmp identity {address | hostname}

router(config)# crypto isakmp key keystring {address | hostname} {IP_address | hostname}

The router starting the encryption process will send its policies to the peer for that device to choose which policies to use. If the highest priority policies that match both use pre-shared keys, that's what will be used. There is a default policy that takes effect if no other policies match between the peers. When configuring the custom policies, it isn't necessary to specify every detail. A new policy uses the default template and the items that are configured are changed from the default. It is impossible to have an incomplete policy. The default policy has the following configuration:

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

Once IKE has been configured, it's time to decide what type of traffic can cross the tunnel. Access lists will determine what traffic can cross as well as what traffic brings the tunnel up. An extended access list is best, to be able to differentiate between IP protocols and applications. As with every access list, remember that the access list number groups statements into a single list. Define the traffic you want to allow across and use the same access list number with each statement.

Access-list number (permit | deny) protocol source_add source_mask operator operand dest_add dest_mask operator operand

The source and destination IP address should be self-explanatory. The mask used is not a subnet mask but a wildcard mask. The protocol can be the entire IP protocol suite, TCP, UDP, OSPF, ESP, etc. If the protocol has a port or message type, it can be specified using the operator and operand. Operator can be used to give a range or a specific port. EQ for equals, GT for greater than and LT for less than have been around for a while. Newer IOS versions have additional options available. The Operand is the port number to be used as a reference. So, LT 1024 means all ports less than 1024.

After traffic has been determined, there still remains the task of tunnel configuration. IPSec has its own mode for tunnel configuration, this is the second mode that you need to become familiar with. Crypto map configuration mode is a series of If-Then statements. If a packet matches the traffic defined in a specific access list, then set the tunnel to certain parameters. The initial statement needs to specify if the keys will be learned with IKE protection or if they are manually configured. "ipsec-isakmp" is recommended in most situations.

router(config)# crypto map CM_name policy_number ipsec-isakmp
router(config-crypto-map)# set peer peer
router(config-crypto-map)# set transform-set TS_name
router(config-crypto-map)# match address access_list_number
router(config-crypto-map)# set security-association lifetime (seconds seconds | kilobytes kilobytes)

When configuring the tunnel lifetime, newer IOS versions allow both a period of time and an amount of data to determine how long it stays up. The default amount of time is one day. If using both methods, don't set the seconds value too high because if there isn't much data crossing, it may take a long time for the tunnel to decide to use new keys. One day is a decent choice, while making it shorter is desirable.

The tunnel also needs to know how to protect the traffic. A transform set is used to define exactly how ESP and AH can be used. A transform set is made up of at least one transform but no more than three. Only one transform in a category can be used. For instance, a transform set may have only one ESP encryption transform. The transform set also needs to have a name for identification.

router(config)# crypto ipsec transform-set TS_name transform1 transform2 transform3

Finally, everything needs to be placed on an interface. Until this is done, the tunnel isn't active and will not come up. The name used is the same as the one used to create the crypto map.

interface Ethernet 0/1
crypto map CM_name

There is no need to link the IKE configuration to the IPSec configuration. The router will use the highest priority policy that matches on both sides, to protect any IPSec tunnel it has to create.

PIX IPSec Configuration
The PIX firewall uses a different operating system than the IOS router, but the method of inputting commands is similar. The main thing that needs to be remembered is that the PIX doesn't have the additional configuration modes; everything must be configured from global configuration mode.

Before IKE negotiation can occur, the IKE process must be running on the firewall interface that will be terminating the tunnel. It used to be that only the Outside interface could terminate encrypted tunnels, but that's no longer true with the current versions of software. IKE is enabled by default but it may be turned off, which is a good thing to do on interfaces that aren't terminating tunnels. To ensure it's enabled, use the following command:

Pix(config)# isakmp enable interface_name

Once you've made sure IKE can operate on the interface, it's time to configure IKE. Each of these commands begins with the same command. You need to provide a policy number that will prioritize this configuration, as you needed to do with the router. Once you're figured out what that policy number will be, you don't enter a specific configuration mode. Instead you will provide more information on each line.

Pix(config)# isakmp policy priority encryption des | 3des
Pix(config)# isakmp policy priority hash md5 | sha
Pix(config)# isakmp policy priority authentication pre-share | rsa-sig
Pix(config)# isakmp policy priority group 1 | 2
Pix(config)# isakmp policy priority lifetime seconds

You will also need to provide the key that will be used for handshaking with the remote peer, if a pre-shared key was selected, as well as the IP address or hostname of the remote peer. Before applying the addressing though, you must state which will be used; an IP address or hostname. The key is configured on the same line as the addressing for the remote peer. Once you've stated what they will be, state if an IP address or hostname is used and what the value is. If need be, you can also use a local host table for name resolution.

Pix(config)# isakmp identity address | hostname
Pix(config)# isakmp key keystring (address ip_address | hostname peer_hostname)
Pix(config)# name ip_address name

Once IKE has been configured, you can view it by either looking in the config file or you can issue the show isakmp policy command. Using this command will show every policy configured on the PIX, you can limit the display by specifying a particular policy, as well as the default policy that is used as the template.

Now, IPSec may be added. There are two steps to configuring IPSec, configuring the tunnel and configuring what you want to be able to cross the tunnel. The tunnel is configured with a transform set. Identify what AH and ESP transforms you wish to use to protect the data as it's moving across. You may use up to three ways of protecting the data crossing the network, one from AH and two from ESP. Use an access list to identify what type of traffic may cross the secure tunnel. You can also specify how long a tunnel will remain up before needing to renegotiate the keys.

Pix(config)# crypto map map-name seq-num ipsec-isakmp
Pix(config)# crypto map map-name seq-num match address access-list-name
Pix(config)# crypto map map-name seq-num set peer hostname | ip-address
Pix(config)# crypto map map-name seq-num set transform-set transform-set-name
Pix(config)# crypto map map-name seq-num set security-association lifetime seconds seconds | kilobytes kilobytes

There are some commands which will apply globally. Each transform set can be configured individually and used in several crypto map configurations. Access lists can also be used by several crypto maps, but care is needed here because routing doesn't always occur in the fashion you think it will. A new default tunnel lifetime can be configured if the default of 28,800 seconds isn't desirable.

Pix(config)# crypto ipsec transform-set set_name transform_1 transform_2 transform_3
Pix(config)# access-list 101 permit ip any any
Pix(config)# crypto ipsec security-association lifetime (kilobytes kilobytes | seconds value)

Concentrator IPSec Configuration
The VPN Concentrator can be configured through a menu-driven, text-based interface but is usually managed via the browser based GUI. The Concentrator follows the same rules for configuring IPSec as the router and PIX firewall do. Because the Concentrator uses a GUI, knowing where to configure a property is important because you rely on visual clues. There are number of options available for client to Concentrator tunnels, we'll focus here on LAN-to-LAN tunnels.

The Concentrator normally has IPSec configured under Configuration | Policy Management but that's not necessary here because a LAN-to-LAN configuration is used to connect two networks together, as opposed to connecting a client to the Concentrator.

LAN-to-LAN configuration begins at Configuration | System | Tunneling Protocols | IPSec. The figure below shows links to four configuration areas. The first is to configure a LAN-to-LAN tunnel, the second is to modify the IKE parameters supported on the Concentrator, the third is to configure IPSec tunneled over a TCP connection and the fourth allows modification of IPSec tunnel parameters.

Figure 1. Configuation window. (Click image to view larger version.)

Clicking the LAN-to-LAN link takes you to LAN-to-LAN configuration, as shown in the figure blow. This is a long screen of options that need to be configured. You need to configure the remote peer, the tunnel method, if the devices will use a pre-shared key or certificates, etc. The "Authentication" and "Encryption" pull down menus allow you to configure how the IPSec tunnel will be built while the "IKE Proposal" pull down menu lets you choose the IKE method to be used.

Figure 2. LAN-to-LAN configuration. (Click image to view larger version.)

You'll also need some way of determining what network is on the other side of the tunnel, that can be determined a bit further down. A routing tab allows you to determine how the remote networks are learned. Autodiscovery exists to let the Concentrators inform each other of the networks directly connected. This works well in small settings but if there is a routed network, the network address and mask should be used instead. If there are several networks, a Network List can be configured from the Policy management section to specify a number of available networks.

Final Notes...
IPSec may be standards-based, but each vendor has its own method of implementation based on the available equipment. And even within a single vendor, product lines may differ, as has been shown here. Fortunately, most of the features supported on the various Cisco products can talk between products.

Questions? Comments? Post 'em below!