Configuring Security for VPNs with IPsec
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Contents
Configuring Security for VPNs with IPsecLast Updated: June 4, 2012
This module describes how to configure basic IPsec VPNs. IPsec is a framework of open standards developed by the IETF. It provides security for the transmission of sensitive information over unprotected networks such as the Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec devices ("peers"), such as Cisco routers.
Finding Feature InformationYour software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Toolkit and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Prerequisites for Configuring Security for VPNs with IPsecIKE ConfigurationYou must configure Internet Key Exchange (IKE) as described in the module Configuring Internet Key Exchange for IPsec VPNs.
Ensure Access Lists Are Compatible with IPsecIKE uses UDP port 500. The IPsec encapsulating security payload (ESP) and authentication header (AH) protocols use protocol numbers 50 and 51, respectively. Ensure that your access lists are configured so that traffic from protocol 50, 51, and UDP port 500 are not blocked at interfaces used by IPsec. In some cases, you might need to add a statement to your access lists to explicitly permit this traffic. Restrictions for Configuring Security for VPNs with IPsecNAT ConfigurationIf you use Network Address Translation (NAT), you should configure static NAT so that IPsec works properly. In general, NAT should occur before the router performs IPsec encapsulation; in other words, IPsec should work with global addresses. Nested IPsec TunnelsIPsec supports nested tunnels that terminate on the same router. Double encryption of locally generated IKE packets and IPsec packets is supported only when a static virtual tunnel interface (sVTI) is configured. Double encryption is supported on releases up to and including Cisco IOS Release 12.4(15)T, but not on later releases. With CSCts46591, the following nested IPsec tunnels are supported: Information About Configuring Security for VPNs with IPsec
Supported StandardsCisco implements the following standards with this feature:
The component technologies implemented for IPsec include:
Cisco IOS also implements Triple DES (168-bit) encryption, depending on the software versions available for a specific platform. Triple DES (3DES) is a strong form of encryption that allows sensitive information to be transmitted over untrusted networks. It enables customers to utilize network layer encryption.
IPsec as implemented in Cisco software supports the following additional standards:
Supported Hardware Switching Paths and EncapsulationSupported HardwareVPN Accelerator Module SupportThe VPN Accelerator Module (VAM) is a single-width acceleration module. It provides high-performance, hardware-assisted tunneling and encryption services suitable for VPN remote access, site-to-site intranet, and extranet applications. It also provides platform scalability and security while working with all services necessary for successful VPN deployments--security, quality of service (QoS), firewall and intrusion detection, service-level validation, and management. The VAM off-loads IPsec processing from the main processor, thus freeing resources on the processor engines for other tasks. The VAM provides hardware-accelerated support for the following multiple encryption functions:
For more information on VAMs, see the document VPN Acceleration Module (VAM). AIMs and NM SupportThe data encryption Advanced Integration Module (AIM) and Network Module (NM) provide hardware-based encryption. The data encryption AIMs and NM are hardware Layer 3 (IPsec) encryption modules and provide DES and Triple DES IPsec encryption for multiple T1s or E1s of bandwidth. These products also have hardware support for Diffie-Hellman, RSA, and DSA key generation. Before using either module, note that RSA manual keying is not supported. See the table below to determine which VPN encryption module to use. IPPCP Software for Use with AIMs and NMs in Cisco 2600 and Cisco 3600 Series RoutersThe software Internet Protocol Payload Compression Protocol (IPPCP) with AIMs and NMs allows customers to use Lempel-Ziv-Stac (LZS) software compression with IPsec when a VPN module is in Cisco 2600 and Cisco 3600 series routers, allowing users to effectively increase the bandwidth on their interfaces. Without IPPCP software, compression is not supported with the VPN encryption hardware AIM and NM; that is, a user has to remove the VPN module from the router and run the software encryption with software compression. IPPCP enables all VPN modules to support LZS compression in the software when the VPN module is in the router, thereby allowing users to configure data compression and increase their bandwidth, which is useful for a low data link. Without IPPCP, compression occurs at Layer 2, and encryption occurs at Layer 3. After a data stream is encrypted, it is passed on for compression services. When the compression engine receives the encrypted data streams, the data expands and does not compress. This feature enables both compression and encryption of the data to occur at Layer 3 by selecting LZS with the IPsec transform set; that is, LZS compression occurs before encryption, and with better compression ratio.
For more information on AIMs and NM, see the Installing Advanced Integration Modules in Cisco 2600 Series, Cisco 3600 Series, and Cisco 3700 Series Routers document. Supported Switching PathsThe table below lists the supported switching paths that work with IPsec.
Supported EncapsulationIPsec 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, Layer 2 Forwarding (L2F), Layer 2 Tunneling Protocol (L2TP), 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. Because the IPsec Working Group has not yet addressed the issue of group key distribution, IPsec currently cannot be used to protect group traffic (such as broadcast or multicast traffic). IPsec Functionality OverviewIPsec provides the following network security services. (In general, the local security policy dictates the use of one or more of these services.)
IPsec provides secure tunnels between two peers, such as two routers. You define which packets are considered sensitive and should be sent through these secure tunnels, and you define the parameters that should be used to protect these sensitive packets by specifying the characteristics of these tunnels. When the IPsec peer recognizes a sensitive packet, the peer sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer. (The use of the term tunnel in this chapter does not refer to using IPsec in tunnel mode.) More accurately, these tunnels are sets of security associations (SAs) that are established between two IPsec peers. The SAs define the protocols and algorithms to be applied to sensitive packets and specify the keying material to be used by the two peers. SAs are unidirectional and are established per security protocol (AH or ESP). With IPsec, you can define the traffic that needs to be protected between two IPsec peers by configuring access lists and applying these access lists to interfaces using crypto map sets. Therefore, traffic may be selected on the basis of the source and destination address, and optionally the Layer 4 protocol and port. (The access lists used for IPsec are only used to determine the traffic that needs to be protected by IPsec, not the traffic that should be blocked or permitted through the interface. Separate access lists define blocking and permitting at the interface.) A crypto map set can contain multiple entries, each with a different access list. The crypto map entries are searched in a sequence--the router attempts to match the packet to the access list specified in that entry. When a packet matches a permit entry in a particular access list, and the corresponding crypto map entry is tagged as cisco, connections are established, if necessary. If the crypto map entry is tagged as ipsec-isakmp, IPsec is triggered. If there is no SA that the IPsec can use to protect this traffic to the peer, IPsec uses IKE to negotiate with the remote peer to set up the necessary IPsec SAs on behalf of the data flow. The negotiation uses information specified in the crypto map entry as well as the data flow information from the specific access list entry. (The behavior is different for dynamic crypto map entries. See the Creating Dynamic Crypto Maps section later in this module.) If the crypto map entry is tagged as ipsec-manual, IPsec is triggered. If there is no SA that IPsec can use to protect this traffic to the peer, the traffic is dropped. In this case, the SAs are installed via the configuration, without the intervention of IKE. If SAs do not exist, IPsec does not have all the necessary pieces configured. Once established, the set of SAs (outbound to the peer) is then applied to the triggering packet and to subsequent applicable packets as those packets exit the router. "Applicable" packets are packets that match the same access list criteria that the original packet matched. For example, all applicable packets could be encrypted before being forwarded to the remote peer. The corresponding inbound SAs are used when processing the incoming traffic from that peer. Multiple IPsec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of SAs. For example, some data streams only need to be authenticated, while other data streams must both be encrypted and authenticated. Access lists associated with IPsec crypto map entries also represent the traffic that the router needs protected by IPsec. Inbound traffic is processed against crypto map entries--if an unprotected packet matches a permit entry in a particular access list associated with an IPsec crypto map entry, that packet is dropped because it was not sent as an IPsec-protected packet. Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms, and other settings that can be applied to IPsec-protected traffic. During the IPsec SA negotiation, the peers agree to use a particular transform set when protecting a particular data flow. IKEv1 Transform SetsAn 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. You can specify multiple transform sets and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry is used in the IPsec SA negotiation to protect the data flows specified by that crypto map entry's access list. During IPsec security association negotiations with IKE, peers search for a transform set that is the same at 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.) If you change a transform set definition, the change is applied only to crypto map entries that reference the transform set. The change is not applied to existing security associations, but is used in subsequent negotiations to establish new SAs. If you want the new settings to take effect sooner, you can clear all or part of the SA database by using the clear crypto sa command. IKEv2 Transform SetsAn Internet Key Exchange version 2 (IKEv2) proposal is a set of transforms used in the negotiation of IKEv2 SA as part of the IKE_SA_INIT exchange. An IKEv2 proposal is regarded as complete only when it has at least an encryption algorithm, an integrity algorithm, and a Diffie-Hellman (DH) group configured. If no proposal is configured and attached to an IKEv2 policy, then the default proposal is used in the negotiation. The default proposal is a collection of commonly used algorithms which are as follows: encryption aes-cbc-128 3des integrity sha md5 group 5 2 The transforms shown above translate to the following combinations in the following order of priority: aes-cbc-128, sha, 5 aes-cbc-128, sha, 2 aes-cbc-128, md5, 5 aes-cbc-128, md5, 2 3des, sha, 5 3des, sha, 2 3des, md5, 5 3des, md5, 2 Although the crypto ikev2 proposal command is similar to the crypto isakmp policy priority command, the IKEv2 proposal differs as follows:
When multiple transforms are configured for a transform type, the order of priority is from left to right. A proposal with multiple transforms for each transform type translates to all possible combinations of transforms. If only a subset of these combinations is required, then they must be configured as individual proposals. Device(config)# crypto ikev2 proposal proposal-1 Device(config-ikev2-proposal)# encryption 3des, aes-cbc-128 Device(config-ikev2-proposal)# integrity sha, md5 Device(config-ikev2-proposal)# group 2 For example, the commands shown above translate to the following transform combinations: 3des, sha, 2 aes-cbc-128, sha, 2 3des, md5, 2 aes-cbc-128, md5, 2 To configure the first and last transform combinations, use the following commands: Device(config)# crypto ikev2 proposal proposal-1 Device(config-ikev2-proposal)# encryption 3des Device(config-ikev2-proposal)# integrity sha Device(config-ikev2-proposal)# group 2 Device(config-ikev2-proposal)# exit Device(config)# crypto ikev2 proposal proposal-2 Device(config-ikev2-proposal)# encryption aes-cbc-128 Device(config-ikev2-proposal)# integrity md5 Device(config-ikev2-proposal)# group 2 IPsec Traffic Nested to Multiple PeersYou can nest IPsec traffic to a series of IPsec peers. For example, for traffic to traverse multiple firewalls (these firewalls have a policy of not letting through traffic that they have not authenticated), the router must establish IPsec tunnels with each firewall in turn. The "nearer" firewall becomes the "outer" IPsec peer. In the example shown in the figure below, Router A encapsulates the traffic destined for Router C in IPsec (Router C is the inner IPsec peer). However, before Router A can send this traffic, it must first reencapsulate this traffic in IPsec to send it to Router B (Router B is the "outer" IPsec peer). It is possible for the traffic between the "outer" peers to have one kind of protection (such as data authentication) and for traffic between the "inner" peers to have a different protection (such as both data authentication and encryption). Crypto Access Lists
Crypto Access List OverviewCrypto 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:
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. When to Use the permit and deny Keywords in Crypto Access ListsCrypto protection can be permitted or denied for certain IP traffic in a crypto access list as follows:
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 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. 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.2 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.2 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 Mirror Image Crypto Access Lists at Each IPsec PeerCisco 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. 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 to Use the any Keyword in Crypto Access ListsWhen 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.") Transform Sets: A Combination of Security Protocols and AlgorithmsAbout Transform SetsA 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. You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry is used in the IPsec SA negotiation to protect the data flows specified by that crypto map entry's access list. 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.) If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. The change is not applied to existing security associations, but is used in subsequent negotiations to establish new SAs. If you want the new settings to take effect sooner, you can clear all or part of the SA database by using the clear crypto sa command. The table below shows allowed transform combinations.
Cisco IOS Suite-B Support for IKE and IPsec Cryptographic AlgorithmsSuite-B adds support for four user interface suites of cryptographic algorithms for use with IKE and IPSec that are described in RFC 4869. Each suite consists of an encryption algorithm, a digital signature algorithm, a key agreement algorithm, and a hash or message digest algorithm. Suite-B has the following cryptographic algorithms:
IPSec encryption algorithms use AES-GCM when encryption is required and AES-GMAC for message integrity without encryption. IKE negotiation uses AES Cipher Block Chaining (CBC) mode to provide encryption and Secure Hash Algorithm (SHA)-2 family containing the SHA-256 and SHA-384 hash algorithms, as defined in RFC 4634, to provide the hash functionality. Diffie-Hellman using Elliptic Curves (ECP), as defined in RFC 4753, is used for key exchange and the Elliptic Curve Digital Signature Algorithm (ECDSA), as defined in RFC 4754, to provide authentication. Suite-B RequirementsSuite-B imposes the following software crypto engine requirements for IKE and IPsec:
Where to Find Suite-B Configuration InformationSuite-B configuration support is described in the following documents:
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 SetsBefore you create crypto map entries, you should determine the type of crypto map--static, dynamic, or manual--best addresses the needs of your network.
About Crypto MapsCrypto map entries created for IPsec pull together the various parts used to set up IPsec SAs, including:
How Crypto Maps WorkCrypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set. Later, you apply these crypto map sets to interfaces; all IP traffic passing through the interface is evaluated against the applied crypto map set. If a crypto map entry sees outbound IP traffic that should be protected and the crypto map specifies the use of IKE, an SA is negotiated with the remote peer according to the parameters included in the crypto map entry; otherwise, if the crypto map entry specifies the use of manual SAs, an SA should have already been established via configuration. (If a dynamic crypto map entry sees outbound traffic that should be protected and no security association exists, the packet is dropped.) The policy described in the crypto map entries is used during the negotiation of SAs. If the local router initiates the negotiation, it uses the policy specified in the static crypto map entries to create the offer to be sent to the specified IPsec peer. If the IPsec peer initiates the negotiation, the local router checks the policy from the static crypto map entries, as well as any referenced dynamic crypto map entries, to decide whether to accept or reject the peer's request (offer). For IPsec to succeed between two IPsec peers, both peers' crypto map entries must contain compatible configuration statements. Compatible Crypto Maps: Establishing an SAWhen two peers try to establish an SA, they must each have at least one crypto map entry that is compatible with one of the other peer's crypto map entries. For two crypto map entries to be compatible, they must meet the following criteria:
Load Sharing Among Crypto MapsYou 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. Crypto Map GuidelinesYou 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:
Static Crypto MapsWhen 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. Dynamic Crypto MapsDynamic 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: Dynamic Crypto Maps OverviewDynamic crypto maps are only available for use by IKE. A dynamic crypto map entry is essentially a static crypto map entry without all the parameters configured. It acts as a policy template where the missing parameters are later dynamically configured (as the result of an IPsec negotiation) to match a remote peer's requirements. This allows remote peers to exchange IPsec traffic with the router even if the router does not have a crypto map entry specifically configured to meet all of the remote peer's requirements. Dynamic crypto maps are not used by the router to initiate new IPsec security associations with remote peers. Dynamic crypto maps are used when a remote peer tries to initiate an IPsec security association with the router. Dynamic crypto maps are also used in evaluating traffic. A dynamic crypto map set is included by reference as part of a crypto map set. Any crypto map entries that reference dynamic crypto map sets should be the lowest priority crypto map entries in the crypto map set (that is, have the highest sequence numbers) so that the other crypto map entries are evaluated first; that way, the dynamic crypto map set is examined only when the other (static) map entries are not successfully matched. If the router accepts the peer's request, it installs the new IPsec security associations, it also installs a temporary crypto map entry. This entry contains the results of the negotiation. At this point, the router performs normal processing using this temporary crypto map entry as a normal entry, even requesting new security associations if the current ones are expiring (based upon the policy specified in the temporary crypto map entry). Once the flow expires (that is, all corresponding security associations expire), the temporary crypto map entry is removed. For both static and dynamic crypto maps, if unprotected inbound traffic matches a permit statement in an access list, and the corresponding crypto map entry is tagged as "IPsec," the traffic is dropped because it is not IPsec-protected. (This is because the security policy as specified by the crypto map entry states that this traffic must be IPsec-protected.) For static crypto map entries, if outbound traffic matches a permit statement in an access list and the corresponding SA is not yet established, the router initiates new SAs with the remote peer. In the case of dynamic crypto map entries, if no SA exists, the traffic would simply be dropped (because dynamic crypto maps are not used for initiating new SAs). Tunnel Endpoint DiscoveryDefining a dynamic crypto map allows only the receiving router to dynamically determine an IPsec peer. Tunnel Endpoint Discovery (TED) allows the initiating router to dynamically determine an IPsec peer for secure IPsec communications. Dynamic TED helps to simplify the IPsec configuration on individual routers within a large network. Each node has a simple configuration that defines the local network that the router is protecting and the required IPsec transforms. To have a large, fully-meshed network without TED, each peer needs to have static crypto maps to every other peer in the network. For example, if there are 100 peers in a large, fully-meshed network, each router needs 99 static crypto maps for each of its peers. With TED, only a single dynamic TED-enabled crypto map is needed because the peer is discovered dynamically. Thus, static crypto maps do not need to be configured for each peer. The figure below and the corresponding steps explain a sample TED network topology. DETAILED STEPS What to Do Next
TED Versions The following table lists the available TED versions:
TED Restrictions TED has the following restrictions:
Redundant Interfaces Sharing the Same Crypto MapFor redundancy, you could apply the same crypto map set to more than one interface. The default behavior is as follows:
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:
Establish Manual SAsThe 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).
How to Configure IPsec VPNs
Creating Crypto Access ListsSUMMARY STEPS
DETAILED STEPS
What to Do NextAfter 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). Configuring Transform Sets for IKEv1 and IKEv2 ProposalsPerform this task to define a transform set that is to be used by the IPsec peers during IPsec security association negotiations with IKEv1 and IKEv2 proposals. RestrictionsIf you are specifying SEAL encryption, note the following restrictions:
Configuring Transform Sets for IKEv1SUMMARY STEPS
DETAILED STEPS
What to Do NextAfter you have defined a transform set, you should create a crypto map as specified in the "Creating Crypto Map Sets" section. Configuring Transform Sets for IKEv2SUMMARY STEPS
DETAILED STEPS
Transform Sets for IKEv2 ExamplesIKEv2 Proposal with One Transform for Each Transform TypeDevice(config)# crypto ikev2 proposal proposal-1 Device(config-ikev2-proposal)# encryption 3des Device(config-ikev2-proposal)# integrity sha Device(config-ikev2-proposal)# group 2 IKEv2 Proposal with Multiple Transforms for Each Transform TypeDevice(config)# crypto ikev2 proposal proposal-2 Device(config-ikev2-proposal)# encryption 3des aes-cbc-128 Device(config-ikev2-proposal)# integrity sha md5 Device(config-ikev2-proposal)# group 2 5 The IKEv2 proposal proposal-2 translates to the following prioritized list of transform combinations: IKEv2 Proposals on the Initiator and ResponderThe proposal of the initiator is as follows: Device(config)# crypto ikev2 proposal proposal-1 Device(config-ikev2-proposal)# encryption 3des aes-cbc-128 Device(config-ikev2-proposal)# integrity sha md5 Device(config-ikev2-proposal)# group 2 5 The proposal of the responder is as follows: Device(config)# crypto ikev2 proposal proposal-2 Device(config-ikev2-proposal)# encryption aes-cbc-128 3des Device(config-ikev2-proposal)# integrity md5 sha Device(config-ikev2-proposal)# group 5 2 In the scenario, the initiator's choice of algorithms is preferred and the selected algorithms are as follows: encryption 3des integrity sha group 2 What to Do NextAfter you have defined a transform set, you should create a crypto map as specified in the "Creating Crypto Map Sets" section. Creating Crypto Map Sets
Creating Static Crypto MapsWhen IKE is used to establish SAs, the 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 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. DETAILED STEPS
Troubleshooting TipsCertain configuration changes take effect only when negotiating subsequent SAs. If you want the new settings to take immediate effect, you must clear the existing SAs so that they are reestablished with the changed configuration. If the router is actively processing IPsec traffic, clear only the portion of the SA database that would be affected by the configuration changes (that is, clear only the SAs established by a given crypto map set). Clearing the full SA database should be reserved for large-scale changes, or when the router is processing very little other IPsec traffic. To clear IPsec SAs, use the clear crypto sa command with appropriate parameters. (Omitting all parameters clears out the full SA database, which clears active security sessions.) What to Do NextAfter you have successfully created a static crypto map, you must apply the crypto map set to each interface through which IPsec traffic flows. To complete this task, see the "Applying Crypto Map Sets to Interfaces" section. Creating Dynamic Crypto MapsDynamic crypto map entries specify crypto access lists that limit traffic for which IPsec SAs can be established. A dynamic crypto map entry that does not specify an access list is ignored during traffic filtering. A dynamic crypto map entry with an empty access list causes traffic to be dropped. If there is only one dynamic crypto map entry in the crypto map set, it must specify the acceptable transform sets. Perform this task to create dynamic crypto map entries that use IKE to establish the SAs.
DETAILED STEPS
Troubleshooting TipsCertain configuration changes take effect only when negotiating subsequent SAs. If you want the new settings to take immediate effect, you must clear the existing SAs so that they are reestablished with the changed configuration. If the router is actively processing IPsec traffic, clear only the portion of the SA database that would be affected by the configuration changes (that is, clear only the SAs established by a given crypto map set). Clearing the entire SA database must be reserved for large-scale changes, or when the router is processing minimal IPsec traffic. To clear IPsec SAs, use the clear crypto sa command with appropriate parameters. (Omitting all parameters clears the full SA database, which clears active security sessions.) What to Do NextAfter you have successfully created a crypto map set, you must apply the crypto map set to each interface through which IPsec traffic flows. To complete this task, see the "Applying Crypto Map Sets to Interfaces" section. Creating Crypto Map Entries to Establish Manual SAsPerform this task to create crypto map entries to establish manual SAs (that is, when IKE is not used to establish the SAs). To create IPv6 crypto maps 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. DETAILED STEPS
Troubleshooting TipsFor manually established SAs, you must clear and reinitialize the SAs for the changes to take effect. To clear IPsec SAs, use the clear crypto sa command with appropriate parameters. (Omitting all parameters clears the entire SA database, which clears active security sessions.) What to Do NextAfter you have successfully created a crypto map set, you must apply the crypto map set to each interface through which IPsec traffic flows. To complete this task, see the "Applying Crypto Map Sets to Interfaces" section. Applying Crypto Map Sets to InterfacesYou must apply a crypto map set to each interface through which IPsec traffic flows. Applying the crypto map set to an interface instructs the device to evaluate the interface's traffic against the crypto map set and to use the specified policy during connection or security association negotiation on behalf of traffic to be protected by the crypto map. Perform this task to apply a crypto map to an interface. DETAILED STEPS
Configuration Examples for IPsec VPNExample: Configuring AES-Based Static Crypto MapThis example shows how a static crypto map is configured and how an AES is defined as the encryption method: crypto isakmp policy 10 encryption aes 256 authentication pre-share lifetime 180 crypto isakmp key cisco123 address 10.0.110.1 ! ! crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac mode transport ! crypto map aesmap 10 ipsec-isakmp set peer 10.0.110.1 set transform-set aesset match address 120 ! ! ! voice call carrier capacity active ! ! mta receive maximum-recipients 0 ! ! interface FastEthernet0/0 ip address 10.0.110.2 255.255.255.0 ip nat outside no ip route-cache no ip mroute-cache duplex auto speed auto crypto map aesmap ! interface Serial0/0 no ip address shutdown ! interface FastEthernet0/1 ip address 10.0.110.1 255.255.255.0 ip nat inside no ip route-cache no ip mroute-cache duplex auto speed auto ! ip nat inside source list 110 interface FastEthernet0/0 overload ip classless ip route 0.0.0.0 0.0.0.0 10.5.1.1 ip route 10.0.110.0 255.255.255.0 FastEthernet0/0 ip route 172.18.124.0 255.255.255.0 10.5.1.1 ip route 172.18.125.3 255.255.255.255 10.5.1.1 ip http server ! ! access-list 110 deny ip 10.0.110.0 0.0.0.255 10.0.110.0 0.0.0.255 access-list 110 permit ip 10.0.110.0 0.0.0.255 any access-list 120 permit ip 10.0.110.0 0.0.0.255 10.0.110.0 0.0.0.255 ! Additional ReferencesRelated Documents
RFCs
Technical Assistance
Feature Information for Security for VPNs with IPsecThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2012 Cisco Systems, Inc. All rights reserved.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||