IKE Phase 2 is responsible for building two unidirectional data connections between the two peers. You need to perform the following things:
This section covers the basics of entering the commands to allow this process to occur.
The purpose of a crypto ACL is to define which traffic is to be protected by IPSec. Basically, a crypto ACL is an extended ACL with permit statements that define what traffic is to be protected. Whatever ACL you create on one peer must be mirrored on the other peer. For example, if you have the following statement on PeerA:
PeerA(config)# access-list 109 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
you must have this statement on PeerB:
PeerA(config)# access-list 110 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Notice that the addressing information is reversed on the two sides (the ACL number or name does not have to match). If you do not configure a mirrored crypto ACL, in most cases, the setup of the data connection will fail. One interesting thing to point out about the crypto ACL is that it is not applied to any interface on the router; instead, it is activated within a crypto map entry for the peer that the traffic is destined to.
Here are some rules that apply to incoming traffic for a crypto ACL:
If the traffic is supposed to be protected (specified in the crypto ACL) and it is not, the router drops the packets.
If the traffic is not supposed to be protected and it is not protected, the router forwards the traffic normally.
If the traffic is not supposed to be protected and it is IPSec traffic, the router forwards it normally (the router assumes that this IPSec traffic is for some other internal device).
These rules apply to outgoing traffic for a crypto ACL:
If the traffic matches a crypto ACL entry, the router applies the information in the appropriate crypto map entry, to protect it.
If the traffic does not match a crypto ACL entry, the router forwards the traffic normally.
CAUTION
I highly recommend that you not use the keyword any for the source or destination address in a crypto ACL entry. This causes the router to treat all traffic from the source or destination as protected traffic, which can cause connectivity problems. Therefore, be as specific as possible about the traffic that is protected. This also helps reduce the processing required on your router to deal with the encryption and decryption of traffic.
NOTE
If your router is handling NAT as well as IPSec connections, for outgoing traffic, router does NAT first and then the IPSec protection. Therefore, the crypto ACL should have the translated (global) address in the source address field of the ACL statement. For inbound traffic, the router handles the IPSec part first and then NAT (if necessary).
Whereas the crypto ACL defines what data traffic is to be protected, a transform set defines how the data traffic is to be protected. To create a transform set, use the following command:
Router(config)# crypto ipsec transform-set name_of_transform_set transform_#1 [transform_#2 [transform_#3] [transform #4]]] Router(config-crytpo-trans)# mode {tunnel | transport}
Each transform set must have a unique name. The following sections discuss the parameters that you can use to create your transform sets.
Following the name of the transform set, you can list up to four transforms. A transform defines the protection method. Table 19-1 lists the valid transforms that you can use in your transform set. The first column lists the security protocol. To make it more readable, I have divided the table into four sections of rows; you can choose one transform from each section to be a part of your transform set. For example, you cannot have both ah-md5-hmac and ad-sha-hmac because they are from the same security protocol. Here is another invalid one: ah-md5-hmac, esp-des, and esp-null. This is invalid because it has two ESP encryption algorithms. However, you could have esp-md5-hmac and esp-3des in the same transform set because they are different security protocols (from different sections of the table).
Security Protocol | Parameter | Description |
---|---|---|
AH integrity | ah-md5-hmac | AH packet integrity checking with MD5 |
AH integrity | ah-sha-hmac | AH packet integrity checking with SHA |
ESP integrity | esp-md5-hmac | ESP packet integrity checking with MD5 |
ESP integrity | esp-sha-hmac | ESP packet integrity checking with SHA |
ESP encryption | esp-null | ESP with no encryption |
ESP encryption | esp-des | ESP with DES encryption |
ESP encryption | esp-3des | ESP with 3DES encryption |
ESP encryption | esp-aes | ESP with AES encryption |
ESP encryption | esp-aes192 | ESP with AES 192 encryption |
ESP encryption | esp-aes256 | ESP with AES 256 encryption |
Compression | comp-lzs | Compression with Lempel-Ziv-Stac (LVS) |
With IPSec, you can use two connection modes to pass protected data: tunnel and transport. Figure 19-1 shows an example of these two modes. The bottom shows an example of transport mode. In transport mode, the real source and destination devices perform the protection: in this case, it is the two PCs (192.1.2.1 and 200.1.2.1). Looking at the IP header of these packets, you can see the source and destination's IP addresses. Transport mode typically is used for a small number of point-to-point protected connections.
However, if you need to protect traffic between two networks, transport mode does not scale well: tunnel mode is more useful in this situation. In tunnel mode, the actual source and destination do not perform the protection; instead, an intermediate device, such as a router, firewall, or VPN concentrator, performs the protection function, as in the top connection shown in Figure 19-1 (between the two routers). Actually, the devices on the two internal networks are completely unaware of the fact that the two perimeter routers are protecting their traffic through IPSec. IP packets between the two networks are encapsulated in a packet by the perimeter routers. The new packet header includes the IP addresses of the two perimeter routers, and the original, encapsulated IP packet maintains its packet-header information (actually, the entire original packet is protected).
Tunnel mode provides these advantages:
It centralizes the configuration of IPSec policies.
It provides scalability because you can choose from a wide variety of IPSec platforms to build the L2L tunnels.
Because the original IP packet is encapsulated, you can transport private IP addressing across a public network. In addition, your internal addressing scheme is hidden from prying eyes in the public network, assuming that one of your transforms is ESP encryption.
When you execute the crypto ipsec transform-set command, you are taken into a subconfiguration mode for your transform set. The mode command specifies the mode of the connection. If you do not configure the connection mode, it defaults to tunnel. Transport mode is used on routers on which a point-to-point connection is needed, such as from your router to a syslog or TFTP server, or for a GRE tunnel; however, in most cases, you will be using tunnel mode.
After you have configured your transform set or sets, you can view them with the show crypto ipsec transform-set command, as displayed in Example 19-10.
Router# show crypto ipsec transform-set
Transform set ESP-ONLY: { esp-3des esp-sha-hmac }
will negotiate = { Tunnel, },
Transform set AH-AND-ESP: { ah-sha-hmac }
will negotiate = { Tunnel, },
{ esp-3des esp-md5-hmac }
will negotiate = { Tunnel, },
In Example 19-10, there are two transform sets: One is called ESP-ONLY, and the other is AH-AND-ESP. The transform set ESP-ONLY uses 3DES for encryption and SHA for packet authentication with ESP. The transform set AH-AND-ESP uses SHA for AH packet authentication, MD5 for ESP packet authentication, and 3DES for ESP encryption. Both transforms are using tunnel mode.
A crypto map ties together all of the IKE Phase 2 components to build protected data connections to remote peers. A crypto map contains the following information:
The name or address of the remote IPSec peer.
The local address that the router should use when sending traffic to the remote IPSec peer. By default, this is the interface that traffic exits to reach the remote peer. However, if your router has two physical interfaces by which the remote peer can reach you, you might want to set up a loopback interface and specify the address on this interface for use with IPSec source and termination points.
Which data traffic should be protected to the remote IPSec peer, specified in a crypto ACL.
The transform set to use to protect the data traffic.
The lifetime of the data connections.
Crypto maps cannot be created haphazardly: You must follow rules when building a crypto map. For example, a crypto map must contain the following information for an L2L connection:
It must contain the IP address of the remote peer.
It must contain the method of negotiation: manual or dynamic ISAKMP/IKE (this book covers only the dynamic method).
It must contain the traffic that should be protected (this crypto ACL needs to be mirrored on the remote peer).
Crypto ACLs should not overlap between different entries of a crypto map (this is a common problem I have seen in troubleshooting IPSec connections to multiple peers).
At least one matching transform set must exist on the remote peer.
If you do not have this information for an L2L connection, the appropriate SAs are not built. SAs that are built are assigned an index number, called a Security Parameter Index (SPI) value. This number uniquely identifies the connection between the peers, and this value is placed in the AH and ESP headers of the IPSec packets. When SAs are built between the two peers (one bidirectional management SA for IKE Phase 1, and two unidirectional data SAs for IKE Phase 2), the components of the IKE Phase 1 policies and the crypto map define what is to be protected and how it is protected. The router uses the SPI values to determine what information in these components to use for the protection or verification of a connection.
Basically two types of crypto maps exist:
Static map? This type of map is used for L2L connections when you know the connection information for the remote peer and when your router will be initiating the connection to the remote peer.
Dynamic map? This type of map is used for remote-access connections and L2L connections when the remote peer is establishing the connection to you and you do not know, up front, what information the peer will be using to protect the connection. A good example of this is a remote peer that acquires its address from its ISP through Dynamic Host Configuration Protocol (DHCP) or PPPoE. In this example, you do not know the peer's IP address until it connects to the ISP and then connects to you. In this situation, you cannot use a static map because a static map requires you to know, up front, the IP address of the peer.
This chapter focuses only on static crypto maps; the next chapter, "IPSec Remote-Access Connections," discusses dynamic crypto maps.
A crypto map can have one or more entries in it. You need more than one entry in your crypto map if the any of the following is true:
You need connections to multiple peers (sites).
You want different types of protection to the same or different peers.
You are using manual ISAKMP. With manual ISAKMP, the crypto ACL where you specify protected traffic can have only the permit statement in it. If you need multiple permit statements, you need a separate crypto map entry for each permit statement.
Now take a look at creating static crypto map entries in your crypto map. To create a static crypto map entry, use the following command:
Router(config)# crypto map name_of_crypto_map sequence_# {ipsec-isakmp | ipsec-manual | cisco} Router(config-crypto-map)#
A crypto map is like an ACL, in that a crypto map can have multiple entries in it. And like a named ACL, the crypto map must be given a name to bind these entries to the crypto map. This name must be unique among all names of crypto maps on your router. Typically, you have to create only one crypto map, but it might have several entries in it.
Following the name of the crypto map, you give it a sequence number. This identifies the specific entry for the crypto map. The router uses these sequence numbers to determine what parameters to use for protection for a particular peer. The sequence numbers are important because the router processes them from lowest to highest numbered. Therefore, the most secure entry should have the lowest sequence number, and the least secure entry should have the highest sequence number. When a remote peer makes a connection to your router, your router processes these in order until it finds a match for the peer. If no match is found, no IPSec connections are built between the two peers.
After you have entered a sequence number, you must specify the method of negotiation. You have three options:
ipsec-isakmp? This method uses ISAKMP/IKE to negotiate the security parameters, including keying information.
ipsec-manual? This method requires you manually to configure the ISAKMP/IKE parameters, including the packet authentication and encryption keys to use. (This method should be used only if the remote side does not support ISAKMP/IKE; this book does not cover this option.)
cisco? This method uses the old Cisco VPN technology called Cisco Encryption Technology (CET). Cisco has replaced CET with IPSec.
Upon entering the negotiation method, press the Enter key to move into a subconfiguration mode where you can enter the information to protect the data SA.
For static crypto map entries that use ISAKMP/IKE, here is the basic configuration to use for a specific entry:
Router(config)# crypto map name_of_crypto_map seq_# ipsec-isakmp Router(config-crypto-map)# match address ACL_#_or_name Router(config-crypto-map)# set peer hostname_or_IP_address Router(config-crypto-map)# set transform-set name_of_transform_set1 [name_of_transform_set2...set6] Router(config-crypto-map)# set pfs [group1 | group2 | group5] Router(config-crypto-map)# set security-association lifetime seconds #_of_seconds Router(config-crypto-map)# set security-association lifetime kilobytes #_of_kilobytes
For a static crypto map entry, three commands are required: match address, set peer, and set transform-set. The match address command specifies the traffic to be protected. With this command, you reference your crypto ACL.
The set peer command specifies either the IP address or the name of the remote peer to which the router will be making IPSec connections. You can list more than one of these commands for multiple peers. However, this is only for redundancy; the router uses the peer in the first set peer command that you configure and uses other peers only if the first peer is not reachable. If you want to set up more than one connection to a peer, you need to create multiple crypto map entries.
NOTE
I recommend not using the name option for a peer unless you statically configure name resolution with the ip host command. Remember that DNS can be easily hijacked.
The set transform set command specifies the transform set to use to protect the IKE Phase 2 data connection to this peer. You can list up to six transform sets. The order in which you list them is important: The remote peer looks for a matching transform set based on the order in which you entered the transforms. Therefore, make sure that you configure the most secure transform first and the least secure last. Typically, with L2L connections, you control the protection used on the routers at both ends. In this case, you need to configure only one transform and specify it here.
The set pfs command is optional. PFS stands for Perfect Forward Secrecy. When you enable this option, you are specifying that DH should be used to exchange the keying information instead of the existing IPSec connection. DH's advantages are that if the old connection was compromised, keying information will not be sent across it, and that DH is more secure than the connection-encryption algorithms because of the key size used. However, the downside of using PFS is that it adds delay because the DH connection must be built. Only three DH groups are supported: groups 1, 2, and 5. If you omit the group designation, it defaults to group1, which is the least secure (group 5 is the most secure).
You can associate two lifetime values with your IKE Phase 2 data connections. You can configure these on a peer-by-peer basis or globally. Configuring these timeout values in a crypto map entry overrides the global values. The two lifetimes are based on time, in seconds, and in kilobytes transferred. The default lifetime in seconds is 3600 (1 hour), which you can override with the set security-association lifetime seconds crypto map command. The default lifetime for amount of data transferred is 4,608,000 KB; you can override this with the set security-association lifetime kilobytes command. When either of these lifetimes is almost reached, the router begins building new data connections to replace the ones that are just about to expire.
If you want to set these lifetimes globally instead of tuning them for each IPSec connection, use the following two global configuration mode commands:
Router(config)# crypto ipsec security-association lifetime seconds #_of_seconds Router(config)# crypto ipsec security-association lifetime kilobytes #_of_kilobytes
Any timeout specified in a crypto map entry overrides the globally defined values.
After you have created a crypto map, you need to activate it. Activation is accomplished just like activating an ACL: You activate it on an interface. With crypto maps, only one crypto map can be activated on a router's interface. However, you can have the same or different crypto maps activated on different router interfaces. Normally, you need to create only a single crypto map and activate this on your router's public, or external, interface. However, if your perimeter router has two public interfaces, you can activate the same crypto map on multiple interfaces.
To activate your crypto map on an interface, use the following command:
Router(config)# interface type [slot_#/]port_# Router(config-if)# crypto map name_of_the_crypto_map
By default, when you have activated a crypto map on your router's interface, the router uses the IP address on this interface as the source IP address in its IPSec packets. If your router has two public interfaces, for example, and you want your router to use the same IP address for both interfaces (perhaps a loopback interface), use the following command:
Router(config)# crypto map name_of_the_crypto_map local-address name_of_interface
For example, if you have a loopback0 interface and want the router to use this as the source (and termination point) of its IPSec transmissions, you would configure the following:
Router(config)# crypto map MYMAP local-address loopback0
Note that you still would apply the crypto map to the physical interfaces connected to the public network.
To verify your crypto map configuration, use the following command:
Router# show crypto map [{interface interface_name] | tag crypto_map_name}]
This command displays your crypto map configuration. Optionally, the interface parameter lists only the crypto map activated on the specified interface. The tag parameter displays only the specified crypto map name. Example 19-11 shows an example of the use of the show crypto map command.
Router# show crypto map
Crypto Map: "MYMAP" idb: Ethernet1 local address: 192.1.1.1
Crypto Map "MYMAP" 10 ipsec-isakmp
Peer = 200.1.1.1
Extended IP access list 100
access-list 100 permit ip
source: addr = 192.168.1.0/255.255.255.0
dest: addr = 192.168.2.0/255.255.255.0
Current peer: 200.1.1.1
Security-association lifetime:
4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ RemotePeerTransform, }
In this example, the crypto map is applied to interface ethernet1, and the local IP address used for IPSec communications is 192.1.1.1. There is only one entry in this crypto map, called MYMAP, with a sequence number of 10. The peer specified is 200.1.1.1, and the crypto ACL is 100, which protects traffic between the local network (192.168.1.0/24) and the remote network (192.168.2.0/24). Below this are the lifetime values for this peer, whether or not PFS is used, and the list of transform sets used. In this example, only one transform set is used: RemotePeerTransform.