Feedback
|
Table Of Contents
Configuring Internet Key Exchange Version 2 (IKEv2)
Prerequisites for Configuring Internet Key Exchange Version 2
Restrictions for Configuring Internet Key Exchange Version 2
Information About Internet Key Exchange Version 2
Cisco IOS Suite-B Support for IKEv2 Proposal
Peer Authentication Using Extensible Authentication Protocol (EAP)
IKEv2 RA Server Support for IPv4 Configuration Attributes
IKEv2 User And Group Authorization
How to Configure Internet Key Exchange Version 2
Configuring Global IKEv2 Options
Configuring the IKEv2 Proposal
Configuring the IKEv2 Name Mangler
Configuring IKEv2 Authorization Policy
Configuring IKEv2 Fragmentation
Configuration Examples for Internet Key Exchange Version 2
Example: Configuring the Proposal
Example: IKEv2 Proposal with One Transform for Each Transform Type
Example: IKEv2 Proposal with Multiple Transforms for Each Transform Type
Example: IKEv2 Proposals on the Initiator and Responder
Example: Configuring the Policy
Example: IKEv2 Policy Matched on a VRF and Local Address
Example: IKEv2 Policy with Multiple Proposals That Match All Peers in a Global VRF
Example: IKEv2 Policy That Matches All Peers in Any VRF
Example: How a Policy Is Matched
Example: Configuring the IKEv2 Keyring
Example: IKEv2 Keyring with Multiple Peer Subblocks
Example: IKEv2 Keyring with Symmetric Preshared Keys Based on an IP Address
Example: IKEv2 Keyring with Asymmetric Preshared Keys Based on an IP Address
Example: IKEv2 Keyring with Asymmetric Preshared Keys Based on a Hostname
Example: IKEv2 Keyring with Symmetric Preshared Keys Based on an Identity
Example: IKEv2 Keyring with a Wildcard Key
Example: How a Keyring is Matched
Example: Configuring the Profile
Example: IKEv2 Profile Matched on Remote Identity
Example: IKEv2 Profile Catering to Two Peers
Example: Configuring the IKEv2 Remote Access Server
Example: Configuring the IKEv2 RA Server to Authenticate Peers Using EAP
Example: Configuring IKEv2 RA Server for Group Authorization (External AAA)
Example: Configuring IKEv2 RA Server for Group Authorization (Local AAA)
Example: Configuring IKEv2 RA Server for User Authorization
Example: Configuring Crypto Map-Based IKEv2 Peers Using Certification Authentication Method
Example: Configuring Crypto-Map-Based IKEv2 Peers Using Preshared Key Authentication Method
Example: Configuring IPsec Using sVTI-Based IKEv2 Peers
Example: Configuring Crypto Map- and dVTI-Based IKEv2 Peers
Example: Configuring IKEv2 on DMVPN Networks
Feature Information for Internet Key Exchange Version 2
Configuring Internet Key Exchange Version 2 (IKEv2)
First Published: March 26, 2010Last Updated: March 25, 2011This module describes the Internet Key Exchange Version 2 (IKEv2) protocol. IKEv2 is the supporting protocol for IP Security Protocol (IPsec) and is used for performing mutual authentication and establishing and maintaining security associations (SAs).
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see 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 for Internet Key Exchange Version 2" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Configuring Internet Key Exchange Version 2
•
Restrictions for Configuring Internet Key Exchange Version 2
•
Information About Internet Key Exchange Version 2
•
How to Configure Internet Key Exchange Version 2
•
Configuration Examples for Internet Key Exchange Version 2
•
Feature Information for Internet Key Exchange Version 2
Prerequisites for Configuring Internet Key Exchange Version 2
You should be familiar with the concepts and tasks explained in the module Configuring Security for VPNs with IPsec.
Restrictions for Configuring Internet Key Exchange Version 2
•
You cannot configure an option that is not supported on a specific platform. For example, in a security protocol, the capability of the hardware-crypto engine is important, and you cannot specify the Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) types of encryption transform in a nonexportable image, or specify an encryption algorithm that a crypto engine does not support.
Information About Internet Key Exchange Version 2
IKEv2, a next-generation key management protocol based on RFC 4306, is an enhancement of the IKE protocol.
IKEv2 supports crypto map-and tunnel protection-based crypto interfaces. The crypto map-based applications include static and dynamic crypto maps, and the tunnel protection-based applications pertain to IPsec static VTI (sVTI), dynamic VTI (dVTI), point-point, and multipoint generic routing encapsulation (mGRE) tunnel interfaces. The VPN solutions include site-to-site VPN, DMVPN, and remote access VPN headend.
The following sections describe the constructs of the IKEv2 protocol in Cisco IOS software:
IKEv2 Proposal
An IKEv2 proposal is a collection of transforms used in the negotiation of IKE SAs as part of the IKE_SA_INIT exchange. The transform types used in the negotiation are as follows:
•
Encryption algorithm
•
Integrity algorithm
•
Pseudo-Random Function (PRF) algorithm
•
Diffie-Hellman (DH) group
You must configure at least one encryption algorithm, one integrity algorithm, and one DH group for the proposal to be considered incomplete. The PRF algorithm is the same as the integrity algorithm, and hence, it is not configured separately. Multiple transforms can be configured and proposed by the initiator for encryption, integrity, and group, of which one transform is selected by the responder. When multiple transforms are configured for a transform type, the order of priority is from left to right.
Note
Unlike IKEv1, the authentication method and SA lifetime are not negotiable in IKEv2, and they cannot be configured in the IKEv2 proposal. Though the crypto ikev2 proposal command looks similar to the IKEv1 crypto isakmp policy command, the IKEv2 proposal configuration supports specifying multiple options for each transform type.
IKEv2 proposals are named and not numbered during the configuration. Manually configured IKEv2 proposals must be linked with an IKEv2 policy; otherwise, the proposals are not used in the negotiation.
Cisco IOS Suite-B Support for IKEv2 Proposal
Suite-B adds support for the SHA-2 family (HMAC variant) hash algorithm used to authenticate packet data and verify the integrity verification mechanisms for the IKEv2 proposal configuration. HMAC is a variant that provides an additional level of hashing.
Suite-B also allows the Elliptic Curve Digital Signature Algorithm (ECDSA) signature (ECDSA-sig), as defined in RFC 4754, to be the authentication method for IKEv2, which is configured in the IKEv2 profile. See "Configuring the IKEv2 Profile" section for more information.
Suite-B requirements comprise 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. See the Configuring Security for VPNs with IPsec feature module for more detailed information about Cisco IOS Suite-B support.
IKEv2 Policy
An IKEv2 policy contains proposals that are used to negotiate the encryption, integrity, PRF algorithms, and DH group in SA_INIT exchange. It can have match statements which are used as selection criteria to select a policy during negotiation.
IKEv2 Profile
An IKEv2 profile is a repository of the nonnegotiable parameters of the IKE SA, such as local or remote identities and authentication methods and the services that are available to the authenticated peers that match the profile.An IKEv2 profile must be attached to either crypto map or IPSec profile on both IKEv2 initiator and responder.
IKEv2 Keyring
An IKEv2 keyring is a repository of symmetric and asymmetric preshared keys and is independent of the IKEv1 keyring. The IKEv2 keyring is associated with an IKEv2 profile and hence, caters to a set of peers that match the IKEv2 profile. The IKEv2 keyring gets its VRF context from the associated IKEv2 profile.
IKEv2 Remote Access Server
The IKEv2 Remote Access (RA) server feature implements the IKEv2 RFC compliant remote access server and adds support for the following:
•
Peer Authentication Using Extensible Authentication Protocol (EAP)
•
IKEv2 RA Server Support for IPv4 Configuration Attributes
•
IKEv2 User And Group Authorization
The IKEv2 remote access server interoperates with the Microsoft Windows7 IKEv2 client.
Note
•
Microsoft Windows 7 IKEv2 client sends IP address as IKE identity that prevents Cisco IOS IKEv2 RA server from segregating remote users based on IKE identity. To allow the Windows 7 IKEv2 client to send email address (user@domain) as IKE identity, apply the hotfix documented in KB675488 http://support.microsoft.com/kb/975488 on Microsoft Windows 7 and specify the email address string in either the user name field when prompted or the CommonName field in the certificate depending on the authentication method.
•
Use the Microsoft Certificate Server to obtain certificates for the Cisco IOS IKEv2 RA server and the Microsoft Windows 7 client for certificate-based authentication, because the Windows 7 client requires an Extended Key Usage field in the certificate that is not supported by the Cisco IOS Certificate Server.
•
For EAP authentication, Microsoft Windows 7 IKEv2 client expects an EAP identity request before any other EAP requests. Please configure the query-identity argument in IKEv2 profile on IKEv2 RA server to send an EAP identity request to the client.
Peer Authentication Using Extensible Authentication Protocol (EAP)
The IKEv2 RA server supports peer authentication using EAP and acts as a pass-through authenticator relaying EAP messages between the RA client and the backend EAP server. The backend EAP server is typically a RADIUS server that supports EAP authentication.
Note
When an RA client authenticates using EAP, the RA server must authenticate using certificates.
The RA server is configured to authenticate RA clients using EAP by configuring the authentication remote eap command in IKEv2 profile configuration mode. The RA clients indicate the intent to authenticate using EAP by skipping AUTH payload in the IKE_AUTH request.
If the query-identity argument is configured, the RA server queries the EAP identity from the RA client; otherwise, the RA client's IKEv2 identity is used as the EAP identity. However, if the query-identity argument is not configured and the RA client's IKEv2 identity is an IPv4 or IPv6 address, the session is terminated because IP addresses cannot be used as the EAP identity.
The RA server starts the EAP authentication by passing the RA client's EAP identity to the EAP server and relays EAP messages between the RA client and the EAP server until the authentication is complete. If the authentication succeeds, the EAP server is expected to return the authenticated EAP identity to the RA server in the EAP success message.
After EAP authentication, the EAP identity, which is used for the configured user or group authorizations, is obtained from the following sources in the given order:
•
The EAP identity provided by the EAP server with the EAP success message.
•
The EAP identity queried from the client when the query-identity argument is configured.
•
The RA client IKEv2 identity used as the EAP identity.
The authorization data received from the EAP server along with the EAP success message is considered as the user authorization data. User authorization if configured is performed only if the EAP server does not provide authorization data along with the EAP success message or provides an invalid framed-ip-address per-user attribute. Attributes received from the EAP server are overridden and merged with the user authorization data.
Figure 1 shows IKEv2 exchange for EAP authentication without the query-identity argument.
Figure 1 IKEv2 Exchange Without Specifying query-identity Argument
Figure 2 shows IKEv2 exchange for EAP authentication with the query-identity argument.
Figure 2 IKEv2 Exchange With the query-identity Argument
IKEv2 RA Server Support for IPv4 Configuration Attributes
The IKEv2 RA server supports the following IKEv2 configuration attributes:
•
INTERNAL_IP4_ADDRESS
•
INTERNAL_IP4_NETMASK
•
INTERNAL_IP4_DNS
•
INTERNAL_IP4_NBNS
•
INTERNAL_IP4_SUBNET
The IKEv2 RA server fetches the attribute values from AAA through user and group authorizations. The INTERNAL_IP4_ADDRESS attribute value is derived from the following sources in the given order:
•
The framed-ip-address attribute received in AAA user authorization.
•
The Local IP address pool.
•
The DHCP server.
A lower priority address sources is used for address allocation only if the higher priority address source is not configured. However, if address allocation from the higher priority address source results in an error, the next source is not tried and the session is terminated.
The value for INTERNAL_IP4_NETMASK attribute is derived as follows:
•
If the IP address is obtained from the DHCP server, the netmask is also obtained from the DHCP server.
•
If the IP address is obtained from framed-ip-address attribute in AAA user authorization or the local IP address pool, the netmask is derived from the IPv4-netmask attribute received in the user or group authorization. If the netmask is not available, the INTERNAL_IP4_NETMASK attribute is not included in the configuration reply. If available, the INTERNAL_IP4_NETMASK attribute is included only if the INTERNAL_IP4_ADDRESS attribute is included in the configuration reply.
If the client requests multiple IPv4 addresses, only one IPv4 address is sent in the reply. An IPv4 address is allocated and included in the reply only if the client requests an address. If available, the remaining attributes are included in the reply even though the client does not request it. If the client requests an IPv4 address and the RA server is unable to assign an address, an INTERNAL_ADDRESS_FAILURE message is returned to the client.
IKEv2 User And Group Authorization
The IKEv2 RA server supports user and group authorizations. You can configure user authorizations, group authorizations, both, or none. The username for the user and group authorizations can be directly specified or derived from the peer IKEv2 identity using a name mangler. Group authorization can be local and external-AAA based, while user authorization can only be external-AAA based. The IKEv2 authorization policy serves as a container of IKEv2 local AAA group authorization parameters.
If AAA user and group authorizations are not configured, it is not considered an error. However, after configuring the user and group authorization, an error encountered during AAA authorization is treated as an error and the connection is terminated. User authorization attributes take a higher priority in constructing a reply when group and user authorization are configured. The framed-ip per-user attribute is always fetched from the user authorization data and ignored if received in the group authorization data. Other attributes are derived from both user and group authorization data with user authorization data taking the higher priority.
IKEv2 Name Mangler
The IKEv2 name mangler derives the username for group and user authorizations from specific portions of the peer IKEv2 identity.
IKEv2 Supported Standards
Cisco implements the IP Security Protocol (IPsec) standard for use in IKEv2.
The component technologies implemented in IKEv2 are as follows:
•
AES-CBC—Advanced Encryption Standard-Cipher Block Chaining
•
DES—Data Encryption Standard
•
Diffie-Hellman—A public-key cryptography protocol
•
MD5 (HMAC variant)—Message digest algorithm 5
•
SHA (HMAC variant)—Secure Hash Algorithm
For more information on the supported standards and component technologies, see Supported Standards for Use with IKE.
Benefits of IKEv2
The benefits of IKEv2 are described in the following sections:
EAP Support
IKEv2 allows the use of Extensible Authentication Protocol (EAP) for authentication.
Reliability and State Management (Windowing)
IKEv2 uses sequence numbers and acknowledgments to provide reliability, and mandates some error-processing logistics and shared state management.
Denial of Service (DoS) Attack Resilience
IKEv2 does not process a request until it determines the requester. This addresses to some extent the DoS problems in IKEv1, which can be tricked to perform much cryptographic (expensive) processing from false locations (spoofing).
Additional Benefits
IKEv2 provides built-in support for Dead Peer Detection (DPD) and Network Address Translation-Traversal (NAT-T). You can reference the certificates through a URL and hash to avoid fragmentation.
How to Configure Internet Key Exchange Version 2
To enable IKEv2 on a crypto interface, attach an IKEv2 profile to the crypto map or IPsec profile applied to the interface.
Note
You need not enable IKEv1 on individual interfaces because IKEv1 is enabled globally on all interfaces in the router.
Perform the following tasks to manually configure IKEv2:
•
Configuring Global IKEv2 Options (optional)
•
Configuring the IKEv2 Proposal (required)
•
Configuring the IKEv2 Policy (required)
•
Configuring the IKEv2 Keyring (required)
•
Configuring the IKEv2 Profile (required)
•
Configuring the IKEv2 Name Mangler (optional)
•
Configuring IKEv2 Authorization Policy (optional)
•
Configuring IKEv2 Fragmentation (optional)
Configuring Global IKEv2 Options
Note
The profile-specific configuration specified in the "Configuring the IKEv2 Profile" section takes precedence over the global IKEv2 options.
Perform this task to configure global IKEv2 options that are independent of peers.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 certificate-cache number-of-certificates
4.
crypto ikev2 cookie-challenge number
5.
crypto ikev2 diagnose error number
6.
crypto ikev2 dpd interval retry-interval {on-demand | periodic}
7.
crypto ikev2 http-url cert
8.
crypto ikev2 limit {max-in-negotation-sa limit | max-sa limit}
9.
crypto ikev2 nat keepalive interval
10.
crypto ikev2 window size
11.
crypto logging ikev2
12.
end
DETAILED STEPS
Configuring the IKEv2 Proposal
Note
The default IKEv2 proposal is used in the default IKEv2 policy.
Perform this task to configure the proposals manually if you do not want to use the default proposal. The default IKEv2 proposal requires no configuration and is a collection of commonly used transforms types, which are as follows:
encryption aes-cbc-128 3desintegrity sha md5group 5 2The transform types shown below translate to the transform combinations in the following order of priority:
aes-cbc-128, sha, 5aes-cbc-128, sha, 2aes-cbc-128, md5, 5aes-cbc-128, md5, 23des, sha, 53des, sha, 23des, md5, 53des, md5, 2SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 proposal name
4.
encryption {3des} {aes-cbc-128} {aes-cbc-192} {aes-cbc-256}
5.
integrity {sha1} {sha256} {sha384} {sha512} {md5}
6.
group {1} {2} {5} {14} {15} {16} {19} {20} {24}
7.
end
8.
show crypto ikev2 proposal [name | default]
DETAILED STEPS
What to Do Next
After you create the IKEv2 proposal, the proposal must be attached to a policy to pick the proposal for negotiation. For information on completing this task, see the "Configuring the IKEv2 Policy" section.
Configuring the IKEv2 Policy
Note
Use the show crypto ikev2 policy command to display the IKEv2 default policy.
Perform this task to manually create an IKEv2 policy; otherwise, the default proposal associated with the default policy is used for negotiation. An IKEv2 policy with no proposal is considered incomplete. During the initial exchange, the local address (IPv4 or IPv6) and the FVRF of the negotiating SA is matched with the policy and the proposal is selected.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 policy name
4.
proposal name
5.
match fvrf {fvrf-name | any}
6.
match address local {ipv4-address | ipv6-address}
7.
end
8.
show crypto ikev2 policy [policy-name]
DETAILED STEPS
Troubleshooting Tips
•
Clear (and reinitialize) IPsec SAs by using the clear crypto sa EXEC command.
•
Using the clear crypto sa command without parameters will clear out the full SA database, which will clear out active security sessions. For more information, see the clear crypto sa command in the Cisco IOS Security Command Reference.
•
Use the debug crypto ikev2 command to enable debug messages.
•
To see the default policy and any default values within configured policies, use the show crypto ikev2 policy default and show crypto ikev2 proposal default commands.
What to Do Next
Depending on the match parameters specified in your IKE policies, you must perform certain additional configuration tasks before IKE and IPsec can successfully use the IKE policies. For information on completing these additional tasks, see the "Configuring the IKEv2 Keyring" section.
Configuring the IKEv2 Keyring
Perform this task to configure the IKEv2 keyring if the local or remote authentication method is a preshared key.
IKEv2 keyring keys must be configured in the peer configuration submode that defines a peer subblock. An IKEv2 keyring can have multiple peer subblocks. A peer subblock contains a single symmetric or asymmetric key pair for a peer or peer group identified by any combination of hostname, identity, and IP address.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 keyring keyring-name
4.
peer name
5.
description line-of-description
6.
hostname name
7.
address {ipv4-address [mask] | ipv6-address prefix}
8.
identity {address {ipv4-address | ipv6-address} | fqdn name | email email-id | key-id key-id}
9.
pre-shared-key {local | remote} {0 | 6 | line}
10.
end
DETAILED STEPS
What to Do Next
After configuring the IKEv2 keyring, configure the IKEv2 profile. For more information, see the "Configuring the IKEv2 Profile" section.
Configuring the IKEv2 Profile
An IKEv2 profile is a repository of nonnegotiable parameters of the IKE SA (such as local/remote identities and authentication methods) and the services available to the authenticated peers that match the profile. An IKEv2 profile must be configured and must be attached to either a crypto map or an IPSec profile on both the IKEv2 initiator and responder. Use the command set ikev2-profile profile-name to attach the profile.
Perform this task to configure an IKEv2 profile and to implement the IKEv2 remote access server.
Note
Similar, to IKEv1, NAT-T is auto detected. To disable NAT-T encapsulation, use the no crypto ipsec nat-transparency udp-encapsulation command.
Use the show crypto ikev2 profile tag command to display the IKEv2 profile.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 profile profile-name
4.
description line-of-description
5.
aaa accounting [psk | cert | eap] list-name
6.
aaa authentication eap list-name
7.
authentication {local {rsa-sig | pre-share | ecdsa-sig} | remote {eap [query-identity]| rsa-sig | pre-share | ecdsa-sig}
8.
aaa authorization {group | user} [cert | eap | psk] aaa-listname {aaa-username | name-mangler mangler-name}
9.
dpd interval retry-interval {on-demand | periodic}
10.
identity local {address {ipv4-address | ipv6-address}| dn | email email-string | fqdn fqdn-string | key-id opaque-string}
11.
ivrf name
12.
keyring [aaa] name
13.
lifetime seconds
14.
match {address local {ipv4-address | ipv6-address} | interface name} | certificate certificate-map | fvrf {fvrf-name | any} | identity remote {address {ipv4-address [mask] | ipv6-address prefix} | email [domain] string | fqdn [domain] string | key-id opaque-string}
15.
nat keepalive seconds
16.
pki trustpoint trustpoint-label [sign | verify]
17.
virtual-template number
18.
end
DETAILED STEPS
Configuring the IKEv2 Name Mangler
Perform this task to specify the IKEv2 name mangler, which is used to derive a name for the authorization requests. The name is derived from specified portions of different forms of remote IKE identities or the EAP identity. The name mangler specified here is referred to in the IKEv2 profile.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 name-mangler mangler-name
4.
dn {common-name | country | domain | locality | organization | organization-unit | state}
5.
eap {all | dn {common-name | country | domain | locality | organization | organization-unit | state} | {prefix | suffix {delimiter {. | @ | \}}}
6.
email {all | domain | username}
7.
fqdn {all | domain | hostname}
8.
end
DETAILED STEPS
Configuring IKEv2 Authorization Policy
The IKEv2 authorization policy serves as a container of IKEv2 local AAA group authorization parameters. The IKEv2 authorization policy is referred from IKEv2 profile via the aaa authorization group command. Perform this task to configure the IKEv2 authorization policy.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 authorization policy policy-name
4.
dhcp {giaddr ip-address | server {ip-address | hostname} | timeout seconds}
5.
dns primary-server [secondary-server]
6.
netmask mask
7.
pool name
8.
subnet-acl {acl-number | acl-name}
9.
wins primary-server [secondary-server]
10.
end
DETAILED STEPS
Configuring IKEv2 Fragmentation
Perform this task to fragment the IKEv2 packets at IKEv2 layer and to avoid fragmentation after encryption. IKEv2 peers negotiate the support for fragmentation and the MTU in the IKE_INIT exchange. Fragmentation of packets exceeding the negotiated MTU starts with IKE_AUTH exchange.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
crypto ikev2 fragmentation [mtu mtu-size]
4.
end
DETAILED STEPS
Configuration Examples for Internet Key Exchange Version 2
This section contains the following configuration examples:
•
Example: Configuring the Proposal
•
Example: Configuring the Policy
•
Example: Configuring the IKEv2 Keyring
•
Example: Configuring the Profile
•
Example: Configuring the IKEv2 Remote Access Server
•
Example: Configuring Crypto Map-Based IKEv2 Peers Using Certification Authentication Method
•
Example: Configuring Crypto-Map-Based IKEv2 Peers Using Preshared Key Authentication Method
•
Example: Configuring IPsec Using sVTI-Based IKEv2 Peers
•
Example: Configuring Crypto Map- and dVTI-Based IKEv2 Peers
•
Example: Configuring IKEv2 on DMVPN Networks
Example: Configuring the Proposal
This section contains the following examples:
•
Example: IKEv2 Proposal with One Transform for Each Transform Type
•
Example: IKEv2 Proposal with Multiple Transforms for Each Transform Type
•
Example: IKEv2 Proposals on the Initiator and Responder
Example: IKEv2 Proposal with One Transform for Each Transform Type
This example shows how to configure an IKEv2 proposal with one transform for each transform type:
crypto ikev2 proposal proposal-1encryption 3desintegrity shagroup 2Example: IKEv2 Proposal with Multiple Transforms for Each Transform Type
This example shows how to configure an IKEv2 proposal with multiple transforms for each transform type:
crypto ikev2 proposal proposal-2encryption 3des aes-cbc-128integrity sha md5group 2 5The IKEv2 proposal proposal-2 shown translates to the following prioritized list of transform combinations:
•
3des, sha, 2
•
3des, sha, 5
•
3des, md5, 2
•
3des, md5, 5
•
aes-cbc-128, sha, 2
•
aes-cbc-128, sha, 5
•
aes-cbc-128, md5, 2
•
aes-cbc-128, md5, 5
Example: IKEv2 Proposals on the Initiator and Responder
The following example shows how to configure IKEv2 proposals on the initiator and the responder. The proposal on the initiator is as follows:
crypto ikev2 proposal proposal-1encryption 3des aes-cbc-128integrity sha md5group 2 5The proposal on the responder is as follows:
crypto ikev2 proposal proposal-2encryption aes-cbc-128 3despeerintegrity md5 shagroup 5 2The selected proposal will be as follows:
encryption 3desintegrity shagroup 2In the proposal shown above, the initiator and responder have conflicting preferences. In this case, the initiator is preferred over the responder.
Example: Configuring the Policy
This section contains the following examples:
•
Example: IKEv2 Policy Matched on a VRF and Local Address
•
Example: IKEv2 Policy with Multiple Proposals That Match All Peers in a Global VRF
•
Example: IKEv2 Policy That Matches All Peers in Any VRF
•
Example: How a Policy Is Matched
Example: IKEv2 Policy Matched on a VRF and Local Address
This example shows how an IKEv2 policy is matched based on a VRF and local address:
crypto ikev2 policy policy2match vrf vrf1match local address 10.0.0.1proposal proposal-1Example: IKEv2 Policy with Multiple Proposals That Match All Peers in a Global VRF
This example shows how an IKEv2 policy with multiple proposals matches the peers in a global VRF:
crypto ikev2 policy policy2proposal proposal-Aproposal proposal-Bproposal proposal-BExample: IKEv2 Policy That Matches All Peers in Any VRF
This example shows how an IKEv2 policy matches the peers in any VRF:
crypto ikev2 policy policy2match vrf anyproposal proposal-1Example: How a Policy Is Matched
Do not configure overlapping policies. If there are multiple possible policy matches, the best match is used, as shown in the following example:
crypto ikev2 policy policy1match fvrf fvrf1crypto ikev2 policy policy2match fvrf fvff1match local address 10.0.0.1The proposal with FVRF as fvrf1 and the local-peer as 10.0.0.1 matches policy1 and policy2, but policy2 is selected because it is the best match.
Example: Configuring the IKEv2 Keyring
This section contains the following examples:
•
Example: IKEv2 Keyring with Multiple Peer Subblocks
•
Example: IKEv2 Keyring with Symmetric Preshared Keys Based on an IP Address
•
Example: IKEv2 Keyring with Asymmetric Preshared Keys Based on an IP Address
•
Example: IKEv2 Keyring with Asymmetric Preshared Keys Based on a Hostname
•
Example: IKEv2 Keyring with Symmetric Preshared Keys Based on an Identity
•
Example: IKEv2 Keyring with a Wildcard Key
•
Example: How a Keyring is Matched
Example: IKEv2 Keyring with Multiple Peer Subblocks
The following example shows how to configure an IKEv2 keyring with multiple peer subblocks:
crypto ikev2 keyring keyring-1peer peer1description peer1address 209.165.200.225 255.255.255.224pre-shared-key key-1peer peer2description peer2hostname peer1.example.compre-shared-key key-2peer peer3description peer3hostname peer3.example.comidentity key-id abcaddress 209.165.200.228 255.255.255.224pre-shared-key key-3Example: IKEv2 Keyring with Symmetric Preshared Keys Based on an IP Address
The following example shows how to configure an IKEv2 keyring with symmetric preshared keys based on an IP address. The following is the initiator's keyring:
crypto ikev2 keyring keyring-1peer peer1description peer1address 209.165.200.225 255.255.255.224pre-shared-key key1The following is the responder's keyring:
crypto ikev2 keyring keyring-1peer peer2description peer2address 209.165.200.228 255.255.255.224pre-shared-key key1Example: IKEv2 Keyring with Asymmetric Preshared Keys Based on an IP Address
The following example shows how to configure an IKEv2 keyring with asymmetric preshared keys based on an IP address. The following is the initiator's keyring:
crypto ikev2 keyring keyring-1peer peer1description peer1 with asymmetric keysaddress 209.165.200.225 255.255.255.224pre-shared-key local key1pre-shared-key remote key2The following is the responder's keyring:
crypto ikev2 keyring keyring-1peer peer2description peer2 with asymmetric keysaddress 209.165.200.228 255.255.255.224pre-shared-key local key2pre-shared-key remote key1Example: IKEv2 Keyring with Asymmetric Preshared Keys Based on a Hostname
The following example shows how to configure an IKEv2 keyring with asymmetric preshared keys based on the hostname. The following is the initiator's keyring:
crypto ikev2 keyring keyring-1peer host1description host1 in example domainhost host1.example.compre-shared-key local key1pre-shared-key remote key2The following is the responder's keyring:
crypto ikev2 keyring keyring-1peer host2description host2 in abc domainhost host2.example.compre-shared-key local key2pre-shared-key remote key1Example: IKEv2 Keyring with Symmetric Preshared Keys Based on an Identity
The following example shows how to configure an IKEv2 keyring with symmetric preshared keys based on an identity:
crypto ikev2 keyring keyring-4peer abcdescription example domainidentity fqdn example.compre-shared-key abc-key-1peer user1description user1 in example domainidentity email user1@example.compre-shared-key abc-key-2peer user1-remotedescription user1 example remote usersidentity key-id examplepre-shared-key example-key-3Example: IKEv2 Keyring with a Wildcard Key
The following example shows how to configure an IKEv2 keyring with a wildcard key:
crypto ikev2 keyring keyring-1peer ciscodescription example domainaddress 0.0.0.0 0.0.0.0pre-shared-key example-keyExample: How a Keyring is Matched
The following example shows how a keyring is matched:
crypto ikev2 keyring keyring-1peer ciscodescription example.comaddress 0.0.0.0 0.0.0.0pre-shared-key xyz-keypeer peer1description abc.example.comaddress 10.0.0.0 255.255.0.0pre-shared-key abc-keypeer host1description host1@abc.example.comaddress 10.0.0.1pre-shared-key host1-example-keyIn the example shown, the key lookup for peer 10.0.0.1 first matches the wildcard key example-key, then the prefix key example-key and finally the host key host1-example-key. The best match host1-example-key is used.
crypto ikev2 keyring keyring-2peer host1description host1 in abc.example.com sub-domainaddress 10.0.0.1pre-shared-key host1-example-keypeer host2description example domainaddress 0.0.0.0 0.0.0.0pre-shared-key example-keyIn the example shown, the key lookup for peer 10.0.0.1 would first match the host key host1-abc-key. Because this is a specific match, no further lookup is performed.
Example: Configuring the Profile
This section contains the following:
•
Example: IKEv2 Profile Matched on Remote Identity
•
Example: IKEv2 Profile Catering to Two Peers
Example: IKEv2 Profile Matched on Remote Identity
The following profile caters to peers that identify themselves using fqdn example.com and authenticate with the RSA-signature using trustpoint-remote. The local node authenticates itself with a preshared key using keyring-1.
crypto ikev2 profile profile2match identity remote fqdn example.comidentity local email router2@example.comauthentication local pre-shareauthentication remote rsa-sigkeyring keyring-1pki trustpoint trustpoint-remote verifylifetime 300dpd 5 10 on-demandvirtual-template 1Example: IKEv2 Profile Catering to Two Peers
The following example shows how to configure an IKEv2 profile catering to two peers that use different authentication methods:
crypto ikev2 profile profile2match identity remote email user1@example.commatch identity remote email user2@example.comidentity local email router2@cisco.comauthentication local rsa-sigauthentication remote pre-shareauthentication remote rsa-sigkeyring keyring-1pki trustpoint trustpoint-local signpki trustpoint trustpoint-remote verifylifetime 300dpd 5 10 on-demandvirtual-template 1Example: Configuring the IKEv2 Remote Access Server
This section provides the following configuration examples:
•
Example: Configuring the IKEv2 RA Server to Authenticate Peers Using EAP
•
Example: Configuring IKEv2 RA Server for Group Authorization (External AAA)
•
Example: Configuring IKEv2 RA Server for Group Authorization (Local AAA)
•
Example: Configuring IKEv2 RA Server for User Authorization
Example: Configuring the IKEv2 RA Server to Authenticate Peers Using EAP
This example shows how to configure the server to authenticate peers using EAP.
aaa new-model!aaa group server radius eap-serverserver 192.168.2.1!aaa authentication login eap-list group eap-server!crypto pki trustpoint trustpoint1enrollment url http://192.168.3.1:80revocation-check crl!crypto ikev2 profile ikev2-profile1match identity remote address 0.0.0.0authentication local rsa-sigauthentication remote eap query-identitypki trustpoint trustpoint1aaa authentication eap eap-listvirtual-template 1!crypto ipsec transform-set transform1 esp-3des esp-sha-hmac!crypto ipsec profile ipsec-profile1set transform-set trans transform1set ikev2-profile ikev2-profile1!interface Ethernet0/0ip address 192.168.1.1 255.255.255.0!interface Virtual-Template1 type tunnelip unnumbered Ethernet0/0tunnel mode ipsec ipv4tunnel protection ipsec profile ipsec-profile1!radius-server host 192.168.2.1 key key1!Example: Configuring IKEv2 RA Server for Group Authorization (External AAA)
The following example shows how to configure the RA server for group authentication through an external AAA, which would be the RADIUS or TACACS server.
aaa new-model!aaa group server radius cisco-acsserver 192.168.2.2!aaa authorization network group-author-list group cisco-acs!crypto pki trustpoint trustpoint1enrollment url http://192.168.3.1:80revocation-check crl!crypto pki certificate map certmap1 1subject-name co cisco!crypto ikev2 name-mangler group-author-manglerdn domain!crypto ikev2 profile ikev2-profile1match certificate certmap1authentication local rsa-sigauthentication remote rsa-sigpki trustpoint trustpoint1aaa authorization group group-author-list name-mangler group-author-manglervirtual-template 1!crypto ipsec transform-set transform1 esp-3des esp-sha-hmac!crypto ipsec profile ipsec-profile1set transform-set trans transform1set ikev2-profile ikev2-profile1!interface Ethernet0/0ip address 192.168.1.1 255.255.255.0!interface Virtual-Template1 type tunnelip unnumbered Ethernet0/0tunnel mode ipsec ipv4tunnel protection ipsec profile ipsec-profile1!radius-server host 192.168.2.2 key key2!Example: Configuring IKEv2 RA Server for Group Authorization (Local AAA)
The following example shows how to configure the RA server for group authentication through local AAA using the AAA authorization policy.
aaa new-model!aaa authorization network local-group-author-list local!crypto pki trustpoint trustpoint1enrollment url http://192.168.3.1:80revocation-check crl!crypto pki certificate map certmap1 1subject-name co cisco!crypto ikev2 authorization policy author-policy1pool pool1dhcp server 192.168.4.1dhcp timeout 10dhcp giaddr 192.168.1.1dns 10.1.1.1 10.1.1.2subnet-acl acl1wins 11.1.1.1 11.1.1.2netmask 255.0.0.0!crypto ikev2 profile ikev2-profile1match certificate certmap1authentication local rsa-sigauthentication remote rsa-sigpki trustpoint trustpoint1aaa authorization group local-group-author-list author-policy1virtual-template 1!crypto ipsec transform-set transform1 esp-3des esp-sha-hmac!crypto ipsec profile ipsec-profile1set transform-set trans transform1set ikev2-profile ikev2-profile1!interface Ethernet0/0ip address 192.168.1.1 255.255.255.0!interface Virtual-Template1 type tunnelip unnumbered Ethernet0/0tunnel mode ipsec ipv4tunnel protection ipsec profile ipsec-profile1!ip local pool pool11 12.1.1.1 12.1.1.100!ip access-list extended acl-1permit ip 11.12.13.0 0.0.0.255 anypermit ip 15.0.0.0 0.255.255.255 any!Example: Configuring IKEv2 RA Server for User Authorization
The following example shows how to configure the RA server for user authentication.
aaa new-model!aaa group server radius cisco-acsserver 192.168.2.2!aaa authorization network user-author-list group cisco-acs!crypto pki trustpoint trustpoint1enrollment url http:// 192.168.3.1:80revocation-check crl!crypto pki certificate map certmap1 1subject-name co cisco!crypto ikev2 name-mangler user-author-manglerdn common-name!crypto ikev2 profile ikev2-profile1match certificate certmap1authentication local rsa-sigauthentication remote rsa-sigpki trustpoint trustpoint1aaa authorization user user-author-list name-mangler user-author-manglervirtual-template 1!crypto ipsec transform-set transform1 esp-3des esp-sha-hmac!crypto ipsec profile ipsec-profile1set transform-set trans transform1set ikev2-profile ikev2-profile1!interface Ethernet0/0ip address 192.168.1.1 255.255.255.0!interface Virtual-Template1 type tunnelip unnumbered Ethernet0/0tunnel mode ipsec ipv4tunnel protection ipsec profile ipsec-profile1!radius-server host 192.168.2.2 key key2!Example: Configuring Crypto Map-Based IKEv2 Peers Using Certification Authentication Method
The following example shows how to configure crypto-map-based IKEv2 peers using the certificate authentication method between a static crypto-map IKEv2 initiator, a dynamic crypto-map IKEv2 responder, and a CA server. The initiator configuration is as follows:
crypto pki trustpoint ca-serverenrollment url http://10.1.1.3:80revocation-check none!crypto pki certificate map cmap-1 1subject-name eq hostname = responder!!crypto pki certificate chain ca-servercertificate 02308201AF 30820118 A0030201 02020102 300D0609 2A864886 F70D0101 0405003014311230 10060355 04031309 63612D73 65727665 72301E17 0D313030 3331303132353132 355A170D 31313033 31303132 35313235 5A301A31 18301606 092A864886F70D01 09021609 494E4954 4941544F 52305C30 0D06092A 864886F7 0D0101010500034B 00304802 4100A47E 8C58BA89 8CCDC5A4 5A63BD29 C331A2A5 393F46166B43FD2E 5ED4C81A 913E3B13 33A9B2DC CFC30391 24BB0DC8 B28FD6F1 C008D10134C10062 30F88CF7 9D630203 010001A3 4F304D30 0B060355 1D0F0404 030205A0301F0603 551D2304 18301680 144871D9 002C66DF D85FACB8 45D1D25F EA35745591301D06 03551D0E 04160414 E77C74E7 183AB530 83DC531B 1DE3DA1D 914A925D300D0609 2A864886 F70D0101 04050003 81810042 21934B77 7E485E6F EE717D756407B361 45190CEF E1A29CF2 6FA29E9A 5ECC1CEE B273533D 1453F6CE 1FDDA7477E701B4B 2A2AE53F D67C2345 952325BA 30950435 0706C5EE A7A8B414 CFEEB7A29CD46F8F 3F663268 A20C4CCF E75D61EF 03FBA85D EDD6B26E 63653F09 F97DAFA66C76E44E C9CA3FDC 6CD85D30 169A1D9E 4E870Bquitcertificate ca 0130820201 3082016A A0030201 02020101 300D0609 2A864886 F70D0101 0405003014311230 10060355 04031309 63612D73 65727665 72301E17 0D313030 3331303132343933 385A170D 31333033 30393132 34393338 5A301431 12301006 0355040313096361 2D736572 76657230 819F300D 06092A86 4886F70D 01010105 0003818D00308189 02818100 DA4ECE09 B998F670 598F32C1 7E9FA920 1D217AC4 293B842E7563CE11 B2F0F822 23077930 636C8293 00F6CFDD F6C9B0F5 8348BE58 6478F6317D44152F 494AEBCC A507FA6B 408D6BBB FAAB0A7A 2E7546A8 CA70F9A6 0F7F6824554BD833 060D657D ABDF406C 69EEF449 7A4F9AFE 6F0852E7 05DEDAC1 D433191E712868C2 A94E642B 02030100 01A36330 61300F06 03551D13 0101FF04 0530030101FF300E 0603551D 0F0101FF 04040302 0186301F 0603551D 23041830 1680144871D9002C 66DFD85F ACB845D1 D25FEA35 74559130 1D060355 1D0E0416 04144871D9002C66 DFD85FAC B845D1D2 5FEA3574 5591300D 06092A86 4886F70D 0101040500038181 00AFC36B 8A917284 06BD51CB 83BDC4E8 9457A361 6CAAF416 3BBEF69104215AC5 EDBC5730 C071C2FB 8A6C90CF D6AB39C2 3BC2147F D35553D9 028B2155802E50DB 48CDE067 B3857447 89A1C733 D81EFEF7 1115480F 70ED2F22 F27E35A1F3BB597C 7C8F717B FAAD79D3 0F469702 DE9190E4 B1B0808E 46A118EB 887CEAEBDFE2900E D2quitcrypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!crypto ikev2 profile profmatch fvrf anymatch certificate cmap-1identity local dnauthentication local rsa-sigauthentication remote pre-shareauthentication remote rsa-sigpki trustpoint ca-server!!crypto ipsec transform-set trans esp-3des esp-sha-hmac!crypto map cmap 1 ipsec-isakmpset peer 209.165.200.225set transform-set transset ikev2-profile profmatch address ikev2list!interface Loopback0ip address 209.165.200.226 255.255.255.224!interface Ethernet0/0ip address 209.165.200.227 255.255.255.224crypto map cmap!interface Ethernet1/0ip address 209.165.200.228 255.255.255.224!ip route 209.165.200.229 255.255.255.224 209.265.200.231!ip access-list extended ikev2listpermit ip any any!The responder configuration is as follows:
crypto pki trustpoint ca-serverenrollment url http://10.1.1.3:80revocation-check none!!!crypto pki certificate map cmap-2 1subject-name eq hostname = initiator!crypto pki certificate chain ca-servercertificate 03308201AF 30820118 A0030201 02020103 300D0609 2A864886 F70D0101 0405003014311230 10060355 04031309 63612D73 65727665 72301E17 0D313030 3331303132353231 325A170D 31313033 31303132 35323132 5A301A31 18301606 092A864886F70D01 09021609 52455350 4F4E4445 52305C30 0D06092A 864886F7 0D0101010500034B 00304802 4100B517 EB8E64E1 B58CB014 07B3A6AF E6B69577 874863679471B1DA BC66B847 DFA5073A 82121332 E787EA2D 3C433514 39033074 4095E7C767A387A1 EBD24692 A76F0203 010001A3 4F304D30 0B060355 1D0F0404 030205A0301F0603 551D2304 18301680 144871D9 002C66DF D85FACB8 45D1D25F EA35745591301D06 03551D0E 04160414 DFF2401C 53276D96 89DE8C0A 786CCA71 C9EA792B300D0609 2A864886 F70D0101 04050003 8181002C 6E334273 CB832A95 3DDC6293669E416C A134D543 20952BC3 14A5C0B0 03AE011C 963AF523 C7C5C935 4FE9B2A5F24B3161 4D0D723A FA428BD1 85ADF172 B4007067 43C27D8A 1F74ED3D DEBE9F731F515355 E77E766C AEACC303 39457991 29AB090C 99E21B5B 60DCB2C8 780B44793EB3D46B B66C8C26 15311A7A B7A4ED97 32727Cquitcertificate ca 0130820201 3082016A A0030201 02020101 300D0609 2A864886 F70D0101 0405003014311230 10060355 04031309 63612D73 65727665 72301E17 0D313030 3331303132343933 385A170D 31333033 30393132 34393338 5A301431 12301006 0355040313096361 2D736572 76657230 819F300D 06092A86 4886F70D 01010105 0003818D00308189 02818100 DA4ECE09 B998F670 598F32C1 7E9FA920 1D217AC4 293B842E7563CE11 B2F0F822 23077930 636C8293 00F6CFDD F6C9B0F5 8348BE58 6478F6317D44152F 494AEBCC A507FA6B 408D6BBB FAAB0A7A 2E7546A8 CA70F9A6 0F7F6824554BD833 060D657D ABDF406C 69EEF449 7A4F9AFE 6F0852E7 05DEDAC1 D433191E712868C2 A94E642B 02030100 01A36330 61300F06 03551D13 0101FF04 0530030101FF300E 0603551D 0F0101FF 04040302 0186301F 0603551D 23041830 1680144871D9002C 66DFD85F ACB845D1 D25FEA35 74559130 1D060355 1D0E0416 04144871D9002C66 DFD85FAC B845D1D2 5FEA3574 5591300D 06092A86 4886F70D 0101040500038181 00AFC36B 8A917284 06BD51CB 83BDC4E8 9457A361 6CAAF416 3BBEF69104215AC5 EDBC5730 C071C2FB 8A6C90CF D6AB39C2 3BC2147F D35553D9 028B2155802E50DB 48CDE067 B3857447 89A1C733 D81EFEF7 1115480F 70ED2F22 F27E35A1F3BB597C 7C8F717B FAAD79D3 0F469702 DE9190E4 B1B0808E 46A118EB 887CEAEBDFE2900E D2quitcrypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!!crypto ikev2 profile profmatch fvrf anymatch certificate cmap-2identity local dnauthentication local rsa-sigauthentication remote pre-shareauthentication remote rsa-sigpki trustpoint ca-server!!crypto ipsec transform-set trans esp-3des esp-sha-hmac!crypto dynamic-map dmap 1set transform-set transset ikev2-profile prof!!crypto map cmap 1 ipsec-isakmp dynamic dmapinterface Loopback0ip address 209.165.200.230 255.255.255.224!interface Ethernet0/0ip address 209.165.200.231 255.255.255.224crypto map cmap!interface Ethernet1/0ip address 209.165.200.232 255.255.255.224!ip route 209.165.200.233 255.255.255.224 209.165.200.228!ip access-list extended ikev2listpermit ip host 209.165.200.231 host 209.165.200.228The CA server configuration is as follows:
crypto pki server ca-servergrant auto!crypto pki trustpoint ca-serverrevocation-check crlrsakeypair ca-server!!crypto pki certificate chain ca-servercertificate ca 0130820201 3082016A A0030201 02020101 300D0609 2A864886 F70D0101 0405003014311230 10060355 04031309 63612D73 65727665 72301E17 0D303930 3330383136333335 395A170D 31323033 30373136 33333539 5A301431 12301006 0355040313096361 2D736572 76657230 819F300D 06092A86 4886F70D 01010105 0003818D00308189 02818100 99750598 EF4AF8B4 823DEF66 2F3BBA31 81C2DC5F D9B4040B99FB6020 22243CD6 B9F24C84 A543D7DB DD0B3018 2E36208C D0FD4015 EAF0DA69C1B0302B 87CEC34B 8646593F 0185AF02 0B86A3F3 5E5C3880 A992CD4A 79F13403411CC61F 07CEB4D9 0E967CB2 FAE0A899 5A3B6C87 73111F06 128465DA A45291F8F828C5DC 657487E7 02030100 01A36330 61300F06 03551D13 0101FF04 0530030101FF300E 0603551D 0F0101FF 04040302 0186301F 0603551D 23041830 1680147BD032BFB7 B3F70F1A 597B7C1E 1B42E472 5CCD6030 1D060355 1D0E0416 04147BD032BFB7B3 F70F1A59 7B7C1E1B 42E4725C CD60300D 06092A86 4886F70D 0101040500038181 003838FA 628804EF E9FF69D9 3D5E299C 29074B2C AE33A563 8AF7597678FB68D4 5EF1E27B 04936FDF 78A09432 5348849D F79E17F5 70B233C9 2C1535D0506F0C35 99335012 84BBA3DC 050FD3C9 6E7B1D63 41ACC2B5 2B02432D BA2CC2CFE379DEA0 A9C208AC 0BEBB2D8 E6488815 EB12F1E0 19072D55 D5D11A49 739144D8271A842E EDquit!interface Ethernet1/0ip address 209.165.200.232 255.255.255.224!ip http serverTo obtain the CA and device certificates, enter the crypto pki authenticate ca-server and crypto pki enroll ca-server commands. To initiate a connection between the initiator and the responder, enter the following command at the initiator's CLI:
ping 209.165.200.230 source 209.165.200.226The output of the command is as follows:
Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 209.165.200.230, timeout is 2 seconds:Packet sent with a source address of 209.165.200.226%IKEV2-5-OSAL_INITIATE_TUNNEL: Received request to establish an IPsec tunnel; local traffic selector = Address Range: 209.165.200.226-209.165.200.226 Protocol: 1 Port Range: 0-65535; remote traffic selector = Address Range: 209.165.200.230-209.165.200.230 Protocol: 1 Port Range: 0-65535%IKEV2-5-SA_UP: SA UP.!!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 8/11/12 msEnter the following show commands in the responder's CLI to display the session details:
show crypto sessionCrypto session current statusInterface: Ethernet0/0Session status: UP-ACTIVEPeer: 1.1.1.1 port 500IKEv2 SA: local 209.165.200.231/500 remote 209.165.200.227/500 ActiveIPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 209.165.200.226Active SAs: 2, origin: dynamic crypto mapshow crypto ikev2 sa detailedTunnel-id Local Remote fvrf/ivrf Status1 209.165.200.231/500 209.165.200.227/500 (none)/(none) READYEncr: 3DES, Hash: MD596, DH Grp:2, Auth sign: RSA, Auth verify: RSALife/Active Time: 86400/846 secCE id: 1001, Session-id: 1Status Description: Negotiation doneLocal spi: F79756E978ED41C7 Remote spi: 188FB9A119516D34Local id: hostname=RESPONDERRemote id: hostname=INITIATORLocal req msg id: 0 Remote req msg id: 2Local next msg id: 0 Remote next msg id: 2Local req queued: 0 Remote req queued: 2Local window: 5 Remote window: 5DPD configured for 0 seconds, retry 0NAT-T is not detectedExample: Configuring Crypto-Map-Based IKEv2 Peers Using Preshared Key Authentication Method
The following example shows how to configure crypto-map-based IKEv2 peers using the preshared key authentication method between a static crypto-map IKEv2 initiator and a dynamic crypto-map IKEv2 responder. The initiator configuration is as follows:
crypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!crypto ikev2 keyring v2-kr1peer abcaddress 209.165.200.231 255.255.255.224pre-shared-key abc!!!crypto ikev2 profile profmatch fvrf anymatch identity remote fqdn dmap-responderidentity local fqdn smap-initiatorauthentication local pre-shareauthentication remote pre-sharekeyring v2-kr1!!crypto ipsec transform-set trans esp-3des esp-sha-hmac!crypto map cmap 1 ipsec-isakmpset peer 209.165.200.225set transform-set transset ikev2-profile profmatch address ikev2list!interface Loopback0ip address 209.165.200.226 255.255.255.224!interface Ethernet0/0ip address 209.165.200.227 255.255.255.224crypto map cmap!ip route 209.165.200.229 255.255.255.224 209.165.200.225!ip access-list extended ikev2listpermit ip any any!The responder configuration is as follows:
crypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!crypto ikev2 keyring v2-kr1peer abcaddress 209.165.200.228pre-shared-key abc!!!crypto ikev2 profile profmatch fvrf anymatch identity remote fqdn smap-initiatoridentity local fqdn dmap-responderauthentication local pre-shareauthentication remote pre-sharekeyring v2-kr1ivrf global!!crypto ipsec transform-set trans esp-3des esp-sha-hmac!crypto dynamic-map dmap 1set transform-set transset reverse-route tag 222set ikev2-profile profmatch address ikev2list!crypto map cmap 1 ipsec-isakmp dynamic dmap!interface Loopback0ip address 209.165.200.230 255.255.255.224!interface Ethernet0/0ip address 209.165.200.231 255.255.255.224crypto map cmap!ip route 209.165.200.233 255.255.255.224 209.165.200.228!ip access-list extended ikev2listpermit ip any any!To initiate the connection between the initiator and the responder, enter the following command at the initiator's CLI:
ping 209.165.200.230 source 209.165.200.226Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 209.165.200.230, timeout is 2 seconds:Packet sent with a source address of 209.165.200.226%IKEV2-5-OSAL_INITIATE_TUNNEL: Received request to establish an IPsec tunnel; local traffic selector = Address Range: 209.165.200.226-209.165.200.226 Protocol: 1 Port Range: 0-65535; remote traffic selector = Address Range: 209.165.200.230-209.165.200.230 Protocol: 1 Port Range: 0-65535%IKEV2-5-SA_UP: SA UP.!!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 8/11/12 msTo display the session details, enter the following show commands:
show crypto sessionCrypto session current statusInterface: Ethernet0/0Session status: UP-ACTIVEPeer: 209.165.200.225 port 500IKEv2 SA: local 209.165.200.228/500 remote 209.165.200.231/500 ActiveIPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0Active SAs: 2, origin: crypto mapshow crypto ikev2 sa detailTunnel-id Local Remote fvrf/ivrf Status1 209.165.200.228/500 209.165.200.231/500 (none)/(none) READYEncr: 3DES, Hash: MD596, DH Grp:2, Auth sign: PSK, Auth verify: PSKLife/Active Time: 86400/21 secCE id: 1002, Session-id: 2Status Description: Negotiation doneLocal spi: 687752902752A6FD Remote spi: C9DCCFC65493D14FLocal id: smap-initiatorRemote id: dmap-responderLocal req msg id: 2 Remote req msg id: 0Local next msg id: 2 Remote next msg id: 0Local req queued: 2 Remote req queued: 0Local window: 5 Remote window: 5DPD configured for 0 seconds, retry 0NAT-T is not detectedExample: Configuring IPsec Using sVTI-Based IKEv2 Peers
The following example shows how to configure IPsec using the preshared key authentication method between an sVTI IKEv2 initiator and an sVTI IKEv2 responder. The initiator configuration is as follows:
crypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!crypto ikev2 keyring v2-kr1peer abcaddress 209.165.200.225pre-shared-key abc!!!crypto ikev2 profile profmatch fvrf anymatch identity remote address 209.165.200.231 255.255.255.224authentication local pre-shareauthentication remote pre-sharekeyring v2-kr1!!crypto ipsec transform-set trans esp-3des esp-sha-hmac!crypto ipsec profile ipsecprofset transform-set transset ikev2-profile prof!interface Loopback0ip address 209.165.200.226 255.255.255.224!interface Tunnel0ip address 10.0.0.1 255.255.255.0tunnel source 209.165.200.231tunnel mode ipsec ipv4tunnel destination 209.165.200.225tunnel protection ipsec profile ipsecprof!interface Ethernet0/0ip address 209.165.200.231 255.255.255.224!ip route 209.165.200.229 255.255.255.224 Tunnel0!The responder configuration is as follows:
crypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!crypto ikev2 keyring v2-kr1peer abcaddress 209.165.200.231pre-shared-key abc!!!crypto ikev2 profile profmatch fvrf anymatch identity remote address 209.165.200.231 255.255.255.224authentication local pre-shareauthentication remote pre-sharekeyring v2-kr1!!crypto ipsec transform-set trans esp-3des esp-sha-hmac!crypto ipsec profile ipsecprofset transform-set transset ikev2-profile prof!crypto map cmap 1 ipsec-isakmp dynamic dmap!interface Loopback0ip address 209.165.200.230 255.255.255.224!interface Tunnel0ip address 10.0.0.2 255.255.255.0tunnel source 209.165.200.225tunnel mode ipsec ipv4tunnel destination 209.165.200.231tunnel protection ipsec profile ipsecprof!interface Ethernet0/0ip address 209.165.200.231 255.255.255.224!ip route 209.165.200.233 255.255.255.224 Tunnel0With sVTI on IKEv2 peers, the session is initiated only when the sVTI interfaces are enabled. In other words, network traffic is not required to initiate the session. To verify the traffic between the initiator and the responder, enter the following command at the initiator's CLI:
ping 209.165.200.230 source 209.165.200.226Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 209.165.200.230, timeout is 2 seconds:Packet sent with a source address of 209.165.200.226%IKEV2-5-OSAL_INITIATE_TUNNEL: Received request to establish an IPsec tunnel; local traffic selector = Address Range: 209.165.200.226-209.165.200.226 Protocol: 1 Port Range: 0-65535; remote traffic selector = Address Range: 209.165.200.230-209.165.200.23 Protocol: 1 Port Range: 0-65535%IKEV2-5-SA_UP: SA UP.!!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 8/11/12 msEnter the following show command in the initiator's CLI to display the session details:
show crypto sessionCrypto session current statusInterface: Ethernet0/0Session status: UP-ACTIVEPeer: 209.165.200.225 port 500IKEv2 SA: local 209.165.200.231/500 remote 209.165.200.225/500 ActiveIPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0Active SAs: 2, origin: crypto mapshow crypto ikev2 sa detailedTunnel-id Local Remote fvrf/ivrf Status1 209.165.200.231/500 209.165.200.225/500 (none)/(none) READYEncr: 3DES, Hash: MD596, DH Grp:2, Auth sign: PSK, Auth verify: PSKLife/Active Time: 86400/21 secCE id: 1002, Session-id: 2Status Description: Negotiation doneLocal spi: 687752902752A6FD Remote spi: C9DCCFC65493D14FLocal id: smap-initiatorRemote id: dmap-responderLocal req msg id: 2 Remote req msg id: 0Local next msg id: 2 Remote next msg id: 0Local req queued: 2 Remote req queued: 0Local window: 5 Remote window: 5DPD configured for 0 seconds, retry 0NAT-T is not detectedExample: Configuring Crypto Map- and dVTI-Based IKEv2 Peers
The following example shows how to configure crypto map-and dVTI-based IKEv2 peers using the preshared key authentication method between a static crypto map IKEv2 initiator and a dVTI-based IKEv2 responder. The initiator configuration is as follows:
crypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!crypto ikev2 keyring v2-kr1peer abcaddress 0.0.0.0 0.0.0.0pre-shared-key abc!!!crypto ikev2 profile profmatch fvrf anymatch identity remote address 0.0.0.0authentication local pre-shareauthentication remote pre-sharekeyring v2-kr1!crypto ipsec transform-set trans esp-3des esp-sha-hmac!crypto map cmap 1 ipsec-isakmpset peer 206.165.200.235set transform-set transset ikev2-profile profmatch address ikev2list!interface Loopback0ip address 206.165.200.226 255.255.255.224!interface Ethernet0/0ip address 206.165.200.227 255.255.255.224crypto map cmap!ip route 206.165.200.229 255.255.255.224 206.165.200.235!ip access-list extended ikev2listpermit ip host 206.165.200.227 host 206.165.200.235permit ip 206.165.200.233 255.255.255.224 206.165.200.229 255.255.255.224The responder configuration is as follows:
crypto ikev2 proposal prop-1encryption 3desintegrity md5group 2!crypto ikev2 policy pol-1match fvrf anyproposal prop-1!crypto ikev2 keyring v2-kr1peer ciscoaddress 0.0.0.0 0.0.0.0pre-shared-key cisco!!!crypto ikev2 profile profmatch fvrf anymatch identity remote address 0.0.0.0authentication local pre-shareauthentication remote pre-sharekeyring v2-kr1virtual-template 1!crypto ipsec transform-set set esp-3des esp-sha-hmac!crypto ipsec profile viset transform-set setset ikev2-profile prof!interface Loopback0ip address 206.165.200.230 255.255.255.224!interface Ethernet0/0ip address 206.165.200.235 255.255.255.224!interface Virtual-Template1 type tunnelip unnumbered Ethernet0/0ip mtu 1000tunnel source Ethernet0/0tunnel mode ipsec ipv4tunnel protection ipsec profile vi!To initiate a connection between the initiator and the responder, enter the following command at the initiator's CLI:
ping 206.165.200.230 source 206.165.200.226Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 206.165.200.230, timeout is 2 seconds:Packet sent with a source address of 206.165.200.226%IKEV2-5-OSAL_INITIATE_TUNNEL: Received request to establish an IPsec tunnel; local traffic selector = Address Range: 206.165.200.226-206.165.200.226 Protocol: 1 Port Range: 0-65535; remote traffic selector = Address Range: 206.165.200.230-206.165.200.230 Protocol: 1 Port Range: 0-65535%IKEV2-5-SA_UP: SA UP.!!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 8/11/12 msEnter the following show command in an Easy VPN server to display the session details:
show crypto sessionCrypto session current statusInterface: Virtual-Access2Session status: UP-ACTIVEPeer: 206.165.200.227 port 500IKEv2 SA: local 206.165.200.235/500 remote 206.165.200.227/500 ActiveIPSEC FLOW: permit ip 206.165.200.229/255.255.255.224 206.165.200.233/255.255.255.224Active SAs: 2, origin: crypto mapshow crypto ikev2 sa detailTunnel-id Local Remote fvrf/ivrf Status1 206.165.200.235/500 206.165.200.227/500 (none)/(none) READYEncr: 3DES, Hash: MD596, DH Grp:2, Auth sign: PSK, Auth verify: PSKLife/Active Time: 86400/8 secCE id: 1001, Session-id: 1Status Description: Negotiation doneLocal spi: 305F610F57428834 Remote spi: D9D183B5689AEDCDLocal id: 206.165.200.235Remote id: 206.165.200.227Local req msg id: 0 Remote req msg id: 2Local next msg id: 0 Remote next msg id: 2Local req queued: 0 Remote req queued: 2Local window: 5 Remote window: 5DPD configured for 0 seconds, retry 0NAT-T is not detectedshow crypto routeVPN Routing Table: Shows RRI and VTI created routesCodes: RRI - Reverse-Route, VTI- Virtual Tunnel InterfaceS - Static Map ACLsRoutes created in table GLOBAL DEFAULT206.165.200.233/255.255.255.224 [1/0] via 206.165.200.227 tag 0on Virtual-Access2 RRIExample: Configuring IKEv2 on DMVPN Networks
DMVPN uses a tunnel protection CLI that is identical between IKEv1 and IKEv2. The IPsec profile applied on a DMVPN tunnel only refers to an IKEv2 profile. The DMVPN Hub configuration is as follows:
crypto ikev2 keyring cisco-ikev2-keyringpeer dmvpn-nodedescription symmetric pre-shared key for the hub/spokeaddress 0.0.0.0 0.0.0.0pre-shared-key cisco123crypto ikev2 profile cisco-ikev2-profilekeyring cisco-ikev2-keyringauthentication pre-sharedmatch local address 0.0.0.0crypto ipsec profile cisco-ipsec-ikev2set transform-set cisco-tsset ikev2-profile cisco-ikev2-profile! interface Tunnel 0description This is the Legacy IKEv1 facing tunnel on the hubip address 1.1.1.99 255.255.255.0no ip redirectsip nhrp map multicast dynamicip nhrp network-id 99ip nhrp redirectno ip split-horizon eigrp 1tunnel source Ethernet0/0tunnel mode gre multipointtunnel protection ipsec profile cisco-ipsec!interface Tunnel1description This would be the new IKEv2 facing tunnel on the hubip address 2.2.2.99 255.255.255.0no ip redirectsip nhrp map multicast dynamicip nhrp network-id 100no ip split-horizon eigrp 1tunnel source Ethernet0/1tunnel mode gre multipointtunnel protection ipsec profile cisco-ipsec-ikev2The IKEv2 configuration is as follows:
crypto ikev2 profile cisco-ikev2-profilekeyring cisco-ikev2-keyringauthentication pre-sharedmatch local address 0.0.0.0crypto ipsec profile cisco-ipsec-ikev2set transform-set cisco-tsset ikev2-profile cisco-ikev2-profileinterface Tunnel1ip address 2.2.2.11 255.255.255.0no ip redirectsip nhrp map 2.2.2.99 22.22.22.99ip nhrp map multicast 22.22.22.99ip nhrp network-id 100 ? Keep this same for all IKEv2 spokes for clarityip nhrp nhs 2.2.2.99 ? This points to the hub's IKEv2 facing interfacetunnel source Ethernet0/1tunnel mode gre multipointtunnel protection ipsec profile cisco-ipsec-ikev2Where to Go Next
After configuring IKEv2, proceed to configure IPsec VPNs. For more information, see the "Configuring Security for VPNs With IPsec" section.
Additional References
Related Documents
Standards
MIBs
MIB MIBs LinkNone
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
RFC TitleRFC 4306
Internet Key Exchange (IKEv2) Protocol
RFC 5685
Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
Technical Assistance
Feature Information for Internet Key Exchange Version 2
Table 1 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 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.
Table 1 Feature Information for Internet Key Exchange Version 2
Feature Name Releases Feature InformationIKEv2 Site to Site
15.1(1)T
IKEv2 is a component of IP Security (IPsec) and is used for performing mutual authentication and establishing and maintaining security associations (SAs).
In Cisco IOS Release 15.1(1)T, this feature was introduced on the Cisco 7200 series routers.
The following sections provide information about this feature:
•
Information About Internet Key Exchange Version 2
•
How to Configure Internet Key Exchange Version 2
The following commands were introduced or modified: aaa accounting (IKEv2 profile), address (IKEv2 keyring), authentication (IKEv2 profile), crypto ikev limit, crypto ikev2 certificate-cache, crypto ikev2 cookie-challenge, crypto ikev2 diagnose, crypto ikev2 dpd, crypto ikev2 http-url, crypto ikev2 keyring, crypto ikev2 nat, crypto ikev2 policy, crypto ikev2 profile, crypto ikev2 proposal, crypto ikev2 window, crypto logging ikev2, description (IKEv2 keyring), dpd, encryption (IKEv2 proposal), group (IKEv2 proposal), hostname (IKEv2 keyring), identity (IKEv2 keyring), identity local, integrity, ivrf, keyring, lifetime (IKEv2 profile), match (IKEv2 policy), match (IKEv2 profile), nat, peer, pki trustpoint, pre-shared-key (IKEv2 keyring), proposal, virtual-template (IKEv2 profile), clear crypto ikev2 sa, clear crypto ikev2 stat, clear crypto session, clear crypto ikev2 sa, debug crypto ikev2, show crypto ikev2 diagnose error, show crypto ikev2 policy, show crypto ikev2 profile, show crypto ikev2 proposal, show crypto ikev2 sa, show crypto ikev2 session, show crypto ikev2 stats, show crypto session, show crypto socket.
Suite-B support in IOS SW crypto
15.1(2)T
Suite-B adds support for the SHA-2 family (HMAC variant) hash algorithm used to authenticate packet data and verify the integrity verification mechanisms for the IKEv2 proposal configuration. HMAC is a variant that provides an additional level of hashing.
Suite-B also allows the Elliptic Curve Digital Signature Algorithm (ECDSA) signature (ECDSA-sig), as defined in RFC 4754, to be the authentication method for IKEv2.
Suite-B requirements comprise of four user interface suites of cryptographic algorithms for use with IKE and IPSec that are described in RFC 4869. Each suite is consists of an encryption algorithm, a digital signature algorithm, a key agreement algorithm, and a hash or message digest algorithm. See the Configuring Security for VPNs with IPsec feature module for more detailed information about Cisco IOS Suite-B support.
The following sections provide information about this feature:
•
Cisco IOS Suite-B Support for IKEv2 Proposal
•
Configuring the IKEv2 Proposal
•
Configuring the IKEv2 Profile
The following commands were introduced or modified: authentication, group, identity (IKEv2 profile), integrity, match (IKEv2 profile).
IKEv2 Remote Access Headend
15.1(3)T
IKEv2 remote access headend feature implements RFC 5685 in IKEv2.
In Cisco IOS Release 15.1(3)T, this feature was introduced.
The following sections provide information about this feature:
•
Configuring the IKEv2 Profile
•
Configuring the IKEv2 Name Mangler
•
Configuring IKEv2 Authorization Policy
•
Configuring IKEv2 Fragmentation
The following commands were introduced or modified: aaa accounting (IKEv2 profile), aaa authentication (IKEv2 profile), aaa authorization (IKEv2 profile), authentication (IKEv2 profile), crypto ikev2 client configuration group, crypto ikev2 fragmentation, crypto ikev2 name mangler, dhcp, dn, dns, eap, email, fqdn, keyring, netmask, pool, show crypto ikev2 profile, show crypto ikev2 sa, subnet-acl, wins.
IPv6 support for IPSec and IKEv2
15.1(4)M
This feature allows IPv6 addresses to be added to IPSec and IKEv2 protocols.
In Cisco IOS Release 15.1(4)M, this feature was introduced.
The following sections provide information about this feature:
•
Configuring the IKEv2 Keyring
•
Configuring the IKEv2 Profile
The following commands were introduced or modified: address (IKEv2 keyring), identity (IKEv2 keyring), identity local, match (IKEv2 policy), and match (IKEv2 profile), show crypto ikev2 session, show crypto ikev2 sa, show crypto ikev2 profile, show crypto ikev2 policy, debug crypto condition, clear crypto ikev2 sa.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at 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. (1005R)
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.
© 2010-2011 Cisco Systems, Inc. All rights reserved.
Feedback

