The table below lists the supported switching paths that work with IPsec.

ip cef
interface ethernet0/0
 ip route-cache
! Ensure that you will not hit flow switching.
 no ip route-cache flow

! Enable global CEF.
ip cef
interface ethernet0/0
 ip route-cache
 ip route-cache flow
! Enable CEF for the interface 
 ip route-cache cef

interface ethernet0/0
 ip route-cache
! Ensure that you will not hit flow switching.
 no ip route-cache flow
! Disable CEF for the interface, which supersedes global CEF.
 no ip route-cache cef

interface ethernet0/0
 ip route-cache
! Enable flow switching
p route-cache flow
! Disable CEF for the interface.
  no ip route-cache cef

interface ethernet0/0
 no ip route-cache

IPsec works with the following serial encapsulations: Frame Relay, High-Level Data-Links Control (HDLC), and PPP.

IPsec also works with Generic Routing Encapsulation (GRE) and IPinIP Layer 3, Data Link Switching+ (DLSw+), and Source Route Bridging (SRB) tunneling protocols; however, multipoint tunnels are not supported. Other Layer 3 tunneling protocols may not be supported for use with IPsec.

An Internet Key Exchange version 1 (IKEv1) transform set represents a certain combination of security protocols and algorithms. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

encryption aes-cbc-128 3des
integrity sha1 md5
group 5 2

Although the crypto ikev2 proposal command is similar to the crypto isakmp policy priority command, the IKEv2 proposal differs as follows:

• An IKEv2 proposal allows configuration of one or more transforms for each transform type.

• An IKEv2 proposal does not have any associated priority.

Note	To use IKEv2 proposals in negotiation, they must be attached to IKEv2 policies. If a proposal is not configured, then the default IKEv2 proposal is used with the default IKEv2 policy.

Crypto access lists are used to define which IP traffic is protected by crypto and which traffic is not protected by crypto. (These access lists are not the same as regular access lists, which determine what traffic to forward or block at an interface.) For example, access lists can be created to protect all IP traffic between Subnet A and Subnet Y or Telnet traffic between Host A and Host B.

The access lists themselves are not specific to IPsec. It is the crypto map entry referencing the specific access list that defines whether IPsec processing is applied to the traffic matching a permit in the access list.

Crypto access lists associated with IPsec crypto map entries have four primary functions:

• Select outbound traffic to be protected by IPsec (permit = protect).

• Indicate the data flow to be protected by the new SAs (specified by a single permit entry) when initiating negotiations for IPsec security associations.

• Process inbound traffic to filter out and discard traffic that should have been protected by IPsec.

• Determine whether or not to accept requests for IPsec security associations on behalf of the requested data flows when processing IKE negotiation from the IPsec peer.

• Perform negotiation only for ipsec-isakmp crypto map entries.

If you want certain traffic to receive one combination of IPsec protection (for example, authentication only) and other traffic to receive a different combination of IPsec protection (for example, both authentication and encryption), you need to create two different crypto access lists to define the two different types of traffic. These different access lists are then used in different crypto map entries, which specify different IPsec policies.

Note	The IPsec traffic cannot be sent when the crypto map access list is modified under a crypto map. The IPsec traffic can be forwarded again after the tunnels are re-keyed. Use the clear crypto session command to continue IPsec traffic forwarding.

Crypto protection can be permitted or denied for certain IP traffic in a crypto access list as follows:

• To protect IP traffic that matches the specified policy conditions in its corresponding crypto map entry, use the permit keyword in an access list.

• To refuse protection for IP traffic that matches the specified policy conditions in its corresponding crypto map entry, use the deny keyword in an access list.

Note	IP traffic is not protected by crypto if it is refused protection in all of the crypto map entries for an interface.

After the corresponding crypto map entry is defined and the crypto map set is applied to the interface, the defined crypto access list is applied to the interface. Different access lists must be used in different entries of the same crypto map set. However, both inbound and outbound traffic is evaluated against the same “outbound” IPsec access list. Therefore, the access list criteria is applied in the forward direction to traffic exiting your router and in the reverse direction to traffic entering your router.

In the figure below, IPsec protection is applied to traffic between Host 10.0.0.1 and Host 192.168.0.2 as the data exits Router A’s S0 interface en route to Host 192.168.0.2. For traffic from Host 10.0.0.1 to Host 192.168.0.2, the access list entry on Router A is evaluated as follows:

source = host 10.0.0.1
dest = host 192.168.0.2

For traffic from Host 192.168.0.2 to Host 10.0.0.1, the access list entry on Router A is evaluated as follows:

source = host 192.168.0.2
dest = host 10.0.0.1

Figure 2. How Crypto Access Lists Are Applied for Processing IPsec

If you configure multiple statements for a given crypto access list that is used for IPsec, in general the first permit statement that is matched is the statement used to determine the scope of the IPsec SA. That is, the IPsec SA is set up to protect traffic that meets the criteria of the matched statement only. Later, if traffic matches a different permit statement of the crypto access list, a new, separate IPsec SA is negotiated to protect traffic matching the newly matched access list statement.

Any unprotected inbound traffic that matches a permit entry in the crypto access list for a crypto map entry flagged as IPsec is dropped because this traffic was expected to be protected by IPsec.

Note

If you view your router’s access lists by using a command such as show ip access-lists, all extended IP access lists are shown in the command output. This display output includes extended IP access lists that are used for traffic filtering purposes and those that are used for crypto. The show command output does not differentiate between the different uses of the extended access lists.

The following example shows that if overlapping networks are used, then the most specific networks are defined in crypto sequence numbers before less specific networks are defined. In this example, the more specific network is covered by the crypto map sequence number 10, followed by the less specific network in the crypto map, which is sequence number 20.

crypto map mymap 10 ipsec-isakmp 
 set peer 192.168.1.1
 set transform-set test 
 match address 101
crypto map mymap 20 ipsec-isakmp 
 set peer 192.168.1.1
 set transform-set test 
 match address 102
access-list 101 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list 102 permit ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255

The following example shows how having a deny keyword in one crypto map sequence number and having a permit keyword for the same subnet and IP range in another crypto map sequence number are not supported.

crypto map mymap 10 ipsec-isakmp 
 set peer 192.168.1.1
 set transform-set test 
 match address 101
crypto map mymap 20 ipsec-isakmp 
 set peer 192.168.1.1
 set transform-set test 
 match address 102
access-list 101 deny   ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list 101 permit ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
access-list 102 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255

Cisco recommends that for every crypto access list specified for a static crypto map entry that you define at the local peer, you define a “mirror image” crypto access list at the remote peer. This ensures that traffic that has IPsec protection applied locally can be processed correctly at the remote peer. (The crypto map entries themselves must also support common transforms and must refer to the other system as a peer.)

The figure below shows some sample scenarios of mirror image and nonmirror image access lists.

Figure 3. Mirror Image vs. Nonmirror Image Crypto Access Lists (for IPsec)

As the above figure indicates, IPsec SAs can be established as expected whenever the two peers’ crypto access lists are mirror images of each other. However, an IPsec SA can be established only some of the time when access lists are not mirror images of each other. This can happen in the case where an entry in one peer’s access list is a subset of an entry in the other peer’s access list, such as shown in Cases 3 and 4 in the above figure. IPsec SA establishment is critical to IPsec—without SAs, IPsec does not work, thus causing packets matching the crypto access list criteria to be silently dropped instead of being forwarded with IPsec.

In the figure above, an SA cannot be established in Case 4. This is because SAs are always requested according to the crypto access lists at the initiating packet’s end. In Case 4, Router N requests that all traffic between Subnet X and Subnet Y be protected, but this is a superset of the specific flows permitted by the crypto access list at Router M, so the request is not permitted. Case 3 works because Router M’s request is a subset of the specific flows permitted by the crypto access list at Router N.

Because of the complexities introduced when crypto access lists are not configured as mirror images at peer IPsec devices, Cisco strongly encourages you to use mirror image crypto access lists.

When you create crypto access lists, using the any keyword could cause problems. Cisco discourages the use of the any keyword to specify the source or destination addresses. By default, VTI solutions use the any keyword as a proxy identity. Use of VTI is encouraged when proxy identities of any are required.

The any keyword in a permit statement is not recommended when you have multicast traffic flowing through the IPsec interface; the any keyword can cause multicast traffic to fail.

The permit any any statement is strongly discouraged because this causes all outbound traffic to be protected (and all protected traffic is sent to the peer specified in the corresponding crypto map entry) and requires protection for all inbound traffic. Then, all inbound packets that lack IPsec protection are silently dropped, including packets for routing protocols, the Network Time Protocol (NTP), echo, echo response, and so on.

You need to be sure that you define which packets to protect. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.

The use of the any keyword in access control lists (ACLs) with reverse route injection (RRI) is not supported. (For more information on RRI, see the section “Creating Crypto Map Sets.”)

Note	Cisco no longer recommends using ah-md5-hmac, esp-md5-hmac, esp-des or esp-3des. Instead, you should use ah-sha-hmac, esp-sha-hmac or esp-aes. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

A transform set represents a certain combination of security protocols and algorithms. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

During IPsec security association negotiations with IKE, peers search for an identical transform set for both peers. When such a transform set is found, it is selected and applied to the protected traffic as part of both peers’ IPsec SAs. (With manually established SAs, there is no negotiation with the peer, so both sides must specify the same transform set.)

The table below shows allowed transform combinations.

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

Suite-B imposes the following software crypto engine requirements for IKE and IPsec:

• HMAC-SHA256 and HMAC-SHA384 are used as pseudorandom functions; the integrity check within the IKE protocol is used. Optionally, HMAC-SHA512 can be used.

• Elliptic curve groups 19 (256-bit ECP curve) and 20 (384-bit ECP curve) are used as the Diffie-Hellman group in IKE. Optionally, group 21 (521-bit ECP curve) can be used.

• The Elliptic Curve Digital Signature Algorithm (ECDSA) algorithm (256-bit and 384-bit curves) is used for the signature operation within X.509 certificates.

• GCM (16 byte ICV) and GMAC is used for ESP (128-bit and 256-bit keys). Optionally, 192-bit keys can be used.

• Public Key Infrastructure (PKI) support for validation of X.509 certificates using ECDSA signatures must be used.

• PKI support for generating certificate requests using ECDSA signatures and for importing the issued certificates into IOS must be used.

• IKEV2 support for allowing the ECDSA signature (ECDSA-sig) as authentication method must be used.

Suite-B configuration support is described in the following documents:

• For more information on the esp-gcm and esp-gmac transforms, see the “Configuring Transform Sets for IKEv1” section.

• For more information on SHA-2 family (HMAC variant) and Elliptic Curve (EC) key pair configuration, see the Configuring Internet Key Exchange for IPsec VPNs feature module.

• For more information on configuring a transform for an integrity algorithm type, see the “Configuring the IKEv2 Proposal” section in the Configuring Internet Key Exchange Version 2 (IKEv2) and FlexVPN Site-to-Site feature module.

• For more information on configuring the ECDSA-sig to be the authentication method for IKEv2, see the “Configuring IKEv2 Profile (Basic)” section in the Configuring Internet Key Exchange Version 2 (IKEv2) and FlexVPN Site-to-Site feature module.

• For more information on configuring elliptic curve Diffie-Hellman (ECDH) support for IPsec SA negotiation, see the Configuring Internet Key Exchange for IPsec VPNs and Configuring Internet Key Exchange Version 2 and FlexVPN feature modules.

For more information on the Suite-B support for certificate enrollment for a PKI, see the Configuring Certificate Enrollment for a PKI feature module.

Crypto map entries created for IPsec pull together the various parts used to set up IPsec SAs, including:

• Which traffic should be protected by IPsec (per a crypto access list)

• The granularity of the flow to be protected by a set of SAs

• Where IPsec-protected traffic should be sent (who the remote IPsec peer is)

• The local address to be used for the IPsec traffic (See the “Applying Crypto Map Sets to Interfaces” section for more details)

• What IPsec SA should be applied to this traffic (selecting from a list of one or more transform sets)

• Whether SAs are manually established or are established via IKE

• Other parameters that might be necessary to define an IPsec SA

You can define multiple remote peers using crypto maps to allow load sharing. Load sharing is useful because if one peer fails, there is still a protected path. The peer to which packets are actually sent is determined by the last peer that the router heard from (that is, received either traffic or a negotiation request) for a given data flow. If the attempt fails with the first peer, IKE tries the next peer on the crypto map list.

If you are not sure how to configure each crypto map parameter to guarantee compatibility with other peers, you might consider configuring dynamic crypto maps as described in the section “Creating Dynamic Crypto Maps”. Dynamic crypto maps are useful when the establishment of the IPsec tunnels is initiated by the remote peer (such as in the case of an IPsec router fronting a server). They are not useful if the establishment of the IPsec tunnels is locally initiated because the dynamic crypto maps are policy templates, not complete statements of policy.

You can apply only one crypto map set to a single interface. The crypto map set can include a combination of IPsec/IKE and IPsec/manual entries. Multiple interfaces can share the same crypto map set if you want to apply the same policy to multiple interfaces.

If you create more than one crypto map entry for a given interface, use the seq-num argument of each map entry to rank the map entries; the lower the seq-num argument the higher the priority. At the interface that has the crypto map set, traffic is first evaluated against the higher priority map entries.

You must create multiple crypto map entries for a given interface if any of the following conditions exist:

• If different data flows are to be handled by separate IPsec peers.

• If you want to apply different IPsec security to different types of traffic (for the same or separate IPsec peers); for example, if you want traffic between one set of subnets to be authenticated, and traffic between another set of subnets to be both authenticated and encrypted. In such cases, the different types of traffic should be defined in two separate access lists, and you must create a separate crypto map entry for each crypto access list.

• If you are not using IKE to establish a particular set of security associations, and you want to specify multiple access list entries, you must create separate access lists (one per permit entry) and specify a separate crypto map entry for each access list.

When IKE is used to establish SAs, IPsec peers can negotiate the settings they use for the new security associations. This means that you can specify lists (such as lists of acceptable transforms) within the crypto map entry.

Perform this task to create crypto map entries that use IKE to establish the SAs. To create IPv6 crypto map entries, you must use the ipv6 keyword with the crypto map command. For IPv4 crypto maps, use the crypto map command without the ipv6 keyword.

Note	Static IPv6 crypto maps with IKE is not supported.

Dynamic crypto maps can simplify IPsec configuration and are recommended for use with networks where the peers are not always predetermined. To create dynamic crypto maps, you should understand the following concepts:

For redundancy, you could apply the same crypto map set to more than one interface. The default behavior is as follows:

• Each interface has its own piece of the security association database.

• The IP address of the local interface is used as the local address for IPsec traffic originating from or destined to that interface.

If you apply the same crypto map set to multiple interfaces for redundancy purposes, you must specify an identifying interface. One suggestion is to use a loopback interface as the identifying interface. This has the following effects:

• The per-interface portion of the IPsec security association database is established one time and shared for traffic through all the interfaces that share the same crypto map.

• The IP address of the identifying interface is used as the local address for IPsec traffic originating from or destined to those interfaces sharing the same crypto map set.

The use of manual security associations is a result of a prior arrangement between the users of the local router and the IPsec peer. The two parties may begin with manual SAs and then move to using SAs established via IKE, or the remote party’s system may not support IKE. If IKE is not used for establishing SAs, there is no negotiation of SAs, so the configuration information in both systems must be the same in order for traffic to be processed successfully by IPsec.

The local router can simultaneously support manual and IKE-established SAs, even within a single crypto map set.

There is very little reason to disable IKE on the local router (unless the router only supports manual SAs, which is unlikely).

Note

Access lists for crypto map entries tagged as ipsec-manual are restricted to a single permit entry and subsequent entries are ignored. In other words, the SAs established by that particular crypto map entry are only for a single data flow. To support multiple manually established SAs for different kinds of traffic, define multiple crypto access lists, and apply each one to a separate ipsec-manual crypto map entry. Each access list should include one permit statement defining what traffic to protect.

After at least one crypto access list is created, a transform set needs to be defined as described in the “Configuring Transform Sets for IKEv1 and IKEv2 Proposals” section.

Next the crypto access lists need to be associated to particular interfaces when you configure and apply crypto map sets to the interfaces. (Follow the instructions in the “Creating Crypto Map Sets” and “Applying Crypto Map Sets to Interfaces” sections).

If you are specifying SEAL encryption, note the following restrictions:

• Your router and the other peer must not have a hardware IPsec encryption.

• Your router and the other peer must support IPsec.

• Your router and the other peer must support the k9 subsystem.

• SEAL encryption is available only on Cisco equipment. Therefore, interoperability is not possible.

• Unlike IKEv1, the authentication method and SA lifetime are not negotiable in IKEv2, and because of this, these parameters cannot be configured under the IKEv2 proposal.