ISAKMP/IKE Phase 2 Data Connections

ISAKMP IKE Phase 2 Data Connections

This part of the chapter will discuss the components you need to configure for the Phase 2 data connections in an IPsec L2L session for your PIX/ASA security appliance. This includes specifying what traffic to protect and how it should be protected. If you've configured L2L sessions on routers, the process and commands described here will be nothing new to you.

Note

Please note that even though Cisco has added many IPsec enhancements in 7.0, the PIX/ASA still lags behind routers when it comes to deploying scalable L2L IPsec sessions. For instance, 7.0 doesn't support advanced QoS, GRE tunnels, or DMVPN. Therefore, I typically use the PIX/ASA with a small number of L2L sessions where I need advanced address translation configurations, or want to enhance the security of the IPsec implementation.

 

Specifying Traffic to Protect

ACLs are used to specify what traffic is to be protected for an IPsec session to a particular peer, commonly called a crypto ACL:

appliance(config)# access-list ACL_name_or_# {permit | deny}
 protocol_name_or_#
 src_IP src_subnet_mask [protocol_info]
 dst_IP dst_subnet_mask [protocol_info]

Any ACL command in the grouping that has a permit statement specifies traffic to be protected, whereas a deny or implicit deny statement specifies traffic that doesn't have to be protected. Unlike on an IOS router, PIX/ASA ACLs use a subnet mask to match on a range of addresses, whereas routers use a wildcard (inverted) mask. The source IP address/network specifies locations connected to the local PIX/ASA and the destination IP address/ network specifies locations connected to the remote peer.

Caution

As with IOS routers, you should be very careful about using the keyword any (0.0.0.0/0) for the source or destination address in a crypto ACL, because this includes broadcast and multicast addresses and can cause certain data transmissions to fail. Therefore, you should be as specific as possible concerning what traffic is to be protected.

 

Defining How to Protect Traffic

As with IOS routers, a transform set is used to specify how traffic is to be protected. How this is configured is similar to configuration for a Cisco IOS router. Here are the commands to create a transform set on a PIX/ASA:

appliance(config)# crypto ipsec transform-set transform_set_name
 transform1 [transform2 [transform3]]
appliance(config)# [no] crypto ipsec transform-set transform_set_name
 mode transport

Each transform set must have a unique name. Within each set, you define between one to three transforms: one for AH authentication, one for ESP authentication, and one for ESP encryption. Here are the valid transform names: ah-md5-hmac, ah-sha-hmac, esp-md5-hmac, esp-sha-hmac, esp-des, esp-3des, esp-aes (128-bit), esp-aes-192, esp-aes-256, and esp-null (no encryption). The default connection mode of the transform is tunnel. This can be changed with the mode parameter after you already have created a transform set (this is different from a router, where the mode is configured in the transform set's subcommand mode). You can use the show crypto ipsec transform-set command in 6.3 to view your configured transform sets. In 7.0, use the show running-config crypto command.

Note

Here are some important items concerning the use of transform sets on PIX/ASA security appliances:

• AES encryption was added in FOS 6.3.
• AH transforms are not supported in FOS 7.0.
• A transform of DES and SHA no longer is supported in any current versions of the FOS software.

Building Crypto Maps

As with IOS routers, the function of a crypto map is to bring all the necessary information together to build an IPsec session to a remote peer. And like IOS routers, security appliances support two types of crypto maps:

• Static Used for L2L sessions where the remote peer information is known.
• Dynamic Used for L2L sessions where most of the remote peer information is unknown, or for remote access sessions.

The following two sections will discuss the configuration of both of these, which is very similar to the configuration of crypto maps on IOS routers.

Static Crypto Maps

Static crypto maps are used for L2L sessions where the peer's IP address and the traffic to be protected is known. For each destination and session, a separate crypto map entry is used. There are two types of static crypto map entries: ISAKMP and manual. ISAKMP entries use ISAKMP/IKE to build a management connection, generate keying information for the management connection, build the data connections, generate keying information for the data connections, and refresh the keying information periodically for both sets of connections. Manual crypto map entries do not use ISAKMP/IKE. With these types of entries, no management connection is needed and you specify the connection information manually for the two unidirectional data connections, including any encryption and HMAC keys.

Creating a static crypto map entry that uses ISAKMP/IKE to build the IPsec session involves the following commands:

appliance(config)# crypto map map_name seq_# ipsec-isakmp
appliance(config)# crypto map map_name seq_# match address ACL_name
appliance(config)# crypto map map_name seq_# set peer IP_address
appliance(config)# crypto map map_name seq_# set transform-set
 trans_name1 [trans_name2...trans_name6]
appliance(config)# crypto map map_name seq_# set security-association
 lifetime {seconds seconds |
 kilobytes kilobytes}
appliance(config)# crypto map map_name seq_# set pfs
 [group1 | group2 | group5 | group7]
appliance(config)# crypto map map_name seq_# set connection-type
 {answer-only | originate-only |
 bidirectional}
appliance(config)# crypto map map_name seq_# set inheritance
 {data | rule}
appliance(config)# crypto map map_name seq_# set nat-t-disable
appliance(config)# crypto map map_name seq_# set phase1mode
 {main | aggressive [group1 | group2 | group5 |
 group7]}
appliance(config)# crypto map map_name seq_# set reverse-route
appliance(config)# crypto map map_name seq_# set trustpoint
 CA_name [chain]

The crypto map command creates a static crypto map. All entries in the map must use the same crypto map name, where each entry is given a unique sequence number within the crypto map. An entry represents a session to a remote peer. An entry might have multiple parameters associated with it, where the map name and sequence number are the same for the entry's parameters. As with Cisco routers, the lower the sequence number, the higher the priority, where sequence numbers can range from 110,000.

Note

Unlike with Cisco routers, there is no subcommand mode for the parameters for a particular entry; all crypto map commands on the PIX/ASA are global commands.

In the preceding code, note that the ipsec-isakmp parameter specifies that ISAKMP/IKE will be used to build and manage the Phase 1 and 2 connections (required).

The match address parameter specifies the ACL name of the traffic to be protected (required). The set peer command specifies the IP address or name (FQDN) of the remote peer (required). In 6.3, you can specify up to 6 peers by executing this command six times; with 7.0, this has been expanded to 10 peers. By specifying multiple peers, the first peer configured becomes the primary and the second and other peers are backup peers. The set transform-set parameter specifies the transform set name to use to protect the traffic to the remote peer (required); you can specify up to six transform sets, where the order you enter them is the order in which they're processed. Therefore, put the most secure one first.

All the remaining parameters in the previous code are optional. The set security-association lifetime parameter changes the default lifetime of the data connections. In seconds, the default is 28,800 seconds and the amount of traffic transmitted is 4,608,000KB. This value overrides the global value that is configured with the crypto ipsec security-association lifetime command (preface this command with show to see the configured global lifetime values).

The set pfs command enables Perfect Forward Secrecy (PFS), which uses Diffie-Hellman (DH) to share the keys instead of the existing management connection. Group 5 keys were added in FOS 6.3 and Group 7 in 7.0. Of the four types, Group 5 is the most secure.

The remainder commands in the previous command list were added in FOS 7.0. The set connection-type parameter specifies which end will initiate the IPsec session. For a hub device, you would set it to answer-only for each peer entry and for a spoke device, originate-only; if you don't care which side initiates the session, use bidirectional. However, if the originating end is acquiring its address dynamically, the originating end would specify originate-only and the remote end answer-only.

The set inheritance parameter controls how many SAs are created per peer; the default is rule, which creates one SA in each direction to the peerdata creates a separate set of SAs per address pair, where the addresses are devices (not the appliances) transmitting actual user data. Using the latter parameter can generate a lot of SAs and overhead on the appliances and should be used only with very security-sensitive applications with short lifetimes associated with them. This parameter can be used only by the initiator of the IPsec session.

NAT-T was introduced in FOS 6.3 and is enabled by default; the set nat-t-disable parameter allows you to disable it for a peer (entry). The set phase1 mode parameter specifies the mode to use when initiating an IPsec session with a peer. The default is main mode. If you specify aggressive mode, you can override the DH key group to use; otherwise DH key group 2 is used. The set reverse-route parameter enables RRI, where the appliance will place static routes in its routing table for the remote networks and then automatically advertise these, via OSPF, to any connected private network. Normally this is used with remote access clients but can be used with L2L sessions, assuming you've configured OSPF on your PIX and internal routing devices.

Last, note that the set trustpoint parameter specifies the CA to use for the particular peer. It is used only when the appliance initiates a session. This is necessary only if you are using more than one CA. The chain parameter specifies that the complete CA chain of certificates, in a hierarchical implementation, is sent to the remote peer (this is disabled by default). The responder side can implement this feature, but this requires the configuration of a tunnel group, which I'll discuss in Chapter 22, "PIX and ASA Remote Access Connections."

In FOS 6.3, you can use the show crypto map command to view the static crypto maps configured on your PIX/ASA. In 7.0, use the show running-config crypto command to see your crypto map and other crypto commands.

Note

A manual crypto map entry is used for a remote peer when there are ISAKMP/IKE compatibility issues with the two peers. This feature was added in FOS 6.3 and then removed in FOS 7.0. Because of this, I won't cover manual crypto map entries for PIX/ ASA security appliances.

 

Dynamic Crypto Maps

Dynamic crypto maps typically are used for remote access sessions; however, they also can be used for L2L sessions where the remote peer's information won't be known until it connects (for example, when the remote peer is assigned an IP address dynamically by the ISP). Dynamic crypto maps can be used only on a peer that will be accepting, not initiating, connections from peers; and in any configuration, one peer can use a dynamic crypto map, but the other peer must use a static crypto map.

Dynamic crypto maps and their configurations are very similar to those of IOS-based routers. A dynamic crypto map has multiple entries: typically one for L2L sessions and one for remote access users (or perhaps just one). The dynamic crypto map is then referenced within a static crypto map as an entry in the static map. When a remote peer builds a connection to your appliance and the dynamic map is used to build the session, the information about the session is placed in the static map as a temporary entry, and then removed upon termination of the connection.

Here are the PIX/ASA commands to create a dynamic crypto map:

appliance(config)# crypto dynamic-map map_name seq_# match
 address ACL_name
appliance(config)# crypto dynamic-map map_name seq_# set
 peer IP_address
appliance(config)# crypto dynamic-map map_name seq_# set
 transform-set trans_name1
 [trans_name2...trans_name6]
appliance(config)# crypto dynamic-map map_name seq_# set
 security-association lifetime
 {seconds seconds |kilobytes kilobytes}
appliance(config)# crypto dynamic-map map_name seq_# set pfs
 [group1 |group2 | group5 |group7]
appliance(config)# crypto dynamic-map map_name seq_# set
 nat-t-disable
appliance(config)# crypto dynamic-map map_name seq_# set
 reverse-route

As you can see from the above commands, configuring a dynamic crypto map is similar to configuring a static one. Each dynamic crypto map needs to have a unique dynamic crypto map name. In FOS 6.3, you can use the show crypto dynamic-map command to view the dynamic crypto maps configured on your PIX/ASA.

Tip

It is possible to use the same map name for a dynamic and static map, but this creates confusion for the novice administrator implementing a VPN. Typically I put the term "stat" in the name of the static map and "dyn" in the dynamic crypto map, like "statmap" and "dynmap," respectively.

Only one command parameter is required for the dynamic crypto map entry: set transform-set. All of the other parameters are optional and were discussed in the previous section. Once you've created your dynamic crypto map, like an IOS-based router, you need to reference it as an entry within your static crypto map:

appliance(config)# crypto map static_map_name seq_# ipsec-isakmp
 dynamic dynamic_map_name

Note

The sequence number for the reference should be the highest number (lowest priority) of all of the entries in your static map: you want your known peers to use the specific static entries and unknown peers to use the dynamic crypto map reference.

 

Activating a Crypto Map

Once you have created your static crypto map (and possible dynamic crypto map references), the static map won't be used until you activate it on the appliance's interface(s):

appliance(config)# crypto map static_map_name
 interface interface_name

The name of the interface is the logical interface name on the PIX/ASA, like "outside" or "inside" and not the physical interface name, like "ethernet0" or "ethernet1."

Data Connection Management Commands

There are various appliance commands you can use to monitor and maintain your IPsec sessions. Here are the show commands you can use:

• show isakmp sa Displays the management connections.
• show crypto ipsec sa Displays the data connections.

I'll discuss these commands and their output in more depth in Chapter 23, "Troubleshooting PIX and ASA Connections."

You can use the following commands to clear IPsec connections and sessions:

appliance(config)# crypto map map_name interface interface_name
appliance(config)# clear [crypto] isakmp sa
appliance(config)# clear [crypto] ipsec sa
 [{peer IP_address | map map_name |
 entry dest_IP protocol SPI_value}

The crypto map interface command will reinitialize the SA and security policy databases. The clear isakmp sa command tears down all of the Phase 1 management connections. The clear ipsec sa command deletes one or more Phase 2 data SAs. In FOS 7.0, the additional clear commands were added:

• clear configure crypto Deletes all IPsec commands: crypto maps, IPsec, and ISAKMP configurations.
• clear configure crypto ca trustpoint Deletes all certificate trustpoint configurations.
• clear configure crypto dynamic-map Deletes all dynamic crypto map configurations.
• clear configure iskamp Deletes all ISAKMP commands.
• clear configure isakmp policy Deletes a specific ISAKMP policy or all policies.

Differences between FOS 6 3 and 7 0

FOS 7.0 adds many features that the 6.3 and earlier FOS versions lacked; however, for the PIX novice who just started getting used to FOS 6.3 and then upgraded to 7.0, you'll see that the commands have not always been preserved from the older to the newer version. For example, if I want to view the Phase 1 management connections, in FOS 6.3 it's show iskamp policy; but in FOS 7.0 it's show running-config isakmp. Or if I want to configure a pre-shared key in 6.3, it's isakmp key. In contrast, in FOS 7.0 it's configured in a tunnel group with the pre-shared-key command.

These configuration differences make it very confusing for a novice, and also frustrating for an expert with PIXs, like myself: I'm constantly using the old-style 6.3 syntax on 7.0 appliances, and it's going to take me a while to become accustomed to the new syntax. On top of that, even though the 7.0 CLI is much more similar to an IOS CLI than version 6.3, there is still not a synchronization of the commands between the two platforms. For example, to delete management connections on a 7.0 appliance, you would use clear [crypto] isakmp sa; but on an IOS router you would use clear crypto isakmp, omitting the sa. I had hoped that Cisco would rectify this on the security appliances in 7.0, making it easy for IOS router experts, but alas, Cisco hasn't quite reached this point.