Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide
Configuring IKE Features Using the IPSec VPN SPA
Downloads: This chapterpdf (PDF - 452.0KB) The complete bookPDF (PDF - 13.22MB) | Feedback

Table of Contents

Configuring IKE Features Using the

Overview of IKE

Differences Between IKEv1 and IKEv2

Benefits of IKEv2

IKEv2 Supported Standards

IKEv2 CLI Constructs

IKEv2 Proposal

IKEv2 Policy

IKEv2 Profile

IKEv2 Key Ring

IKEv2 Smart Defaults

Information About IKEv2 Exchanges

Configuring Basic IKEv2 CLI Constructs

Restrictions for Configuring IKEv2

Configuring IKEv2 Key Rings

Configuration Example for Keyring

Configuring an IKEv2 Profile (Basic)

Sample Configuration: IKEv2 Profile

Verification of IKEv2 Profile Configuration

Information About IKEv2 Proposal

Configuring an IKEv2 Proposal

Configuration Example: IKEv2 Proposal

Verification of IKEv2 Proposal Configuration

Information About IKEv2 Policies

Configuring IKEv2 Policies

Sample Configuration for IKEv2 Policy

Verification of IKEv2 Policy Configuration

Verification of IKEv2 SA Configuration

Verification of IKEv2 Session Configuration

Verification of IKEv2 SA Statistics

Configuring Advanced Encryption Standard in an IKE Policy Map

Verifying the AES IKE Policy

Configuring ISAKMP Keyrings

ISAKMP Keyrings Configuration Guidelines and Restrictions

Limiting an ISAKMP Profile to a Local Termination Address or Interface

Limiting a Keyring to a Local Termination Address or Interface

Configuring Certificate to ISAKMP Profile Mapping

Certificate to ISAKMP Profile Mapping Configuration Guidelines and Restrictions

Mapping the Certificate to the ISAKMP Profile

Verifying the Certificate to ISAKMP Profile Mapping Configuration

Assigning the Group Name to the Peer

Verifying the Group Name to Peer Assignation Configuration

Configuring an Encrypted Preshared Key

Encrypted Preshared Key Configuration Guidelines and Restrictions

Configuring an Encrypted Preshared Key

Verifying the Encrypted Preshared Key Configuration

Configuring Call Admission Control for IKE

Configuring the IKE Security Association Limit

Configuring a System Resource Limit

Clearing Call Admission Statistics

Verifying the Call Admission Control for IKE Configuration

Configuring Dead Peer Detection

DPD Configuration Guidelines and Restrictions

Configuring a Dead Peer Detection Message

Verifying the DPD Configuration

Understanding IPSec NAT Transparency

IPSec NAT Transparency Configuration Guidelines and Restrictions

Configuring NAT Transparency

Disabling NAT Transparency

Configuring NAT Keepalives

Verifying the NAT Configuration

Configuration Examples

Advanced Encryption Standard Configuration Example

ISAKMP Keyrings Configuration Examples

ISAKMP Profile Bound to a Local Interface Configuration Example

ISAKMP Keyring Bound to a Local Interface Configuration Example

ISAKMP Keyring Bound to a Local IP Address Configuration Example

Certificate to ISAKMP Profile Mapping Configuration Examples

Certificates Mapped to the ISAKMP Profile on the Basis of Arbitrary Fields Configuration Example

Group Name Assigned to a Peer Associated with an ISAKMP Profile Configuration Example

Encrypted Preshared Key Configuration Example

Call Admission Control for IKE Configuration Examples

IKE Security Association Limit Configuration Example

System Resource Limit Configuration Example

Dead Peer Detection Configuration Examples

On-Demand DPD Configuration Example

Periodic DPD Configuration Example

ISAKMP NAT Keepalive Configuration Example

Configuring IKE Features Using the IPSec VPN SPA

This chapter provides information about configuring Internet Key Exchange (IKE) related features using the IPSec VPN SPA on the Cisco 7600 series router. It includes the following sections:


Note For detailed information on Internet Key Exchange (IKE), refer to the following Cisco IOS documentation:

Cisco IOS Security Configuration Guide
, Release 12.2, at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/fsecur_c.html

Cisco IOS Security Command Reference, Release 12.2, at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/fsecur_r.html


For information about managing your system images and configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide and Cisco IOS Configuration Fundamentals Command Reference publications.

For more information about the commands used in this chapter, refer to the Cisco IOS Software Releases 15.0SR Command References and to the Cisco IOS Software Releases 12.2SX Command References . Also refer to the related Cisco IOS Release 12.2 software command reference and master index publications. For more information, see the “$paratext>” section.


Tip To ensure a successful configuration of your VPN using the IPSec VPN SPA, read all of the configuration summaries and guidelines before you perform any configuration tasks.


Overview of IKE

Internet Key Exchange (IKE) is a key management protocol standard that is used in conjunction with the IPSec standard. IPSec can be configured without IKE, but IKE enhances IPSec by providing additional features, flexibility, and ease of configuration for the IPSec standard.


Note For more detailed information on IKE, refer to the Cisco IOS Security Configuration Guide.


IKE automatically negotiates IPSec security associations (SAs) and enables IPSec secure communications without costly manual preconfiguration. Specifically, IKE provides the following benefits:

  • Eliminates the need to manually specify all the IPSec security parameters in the crypto maps at both peers.

Note Beginning in Cisco IOS Release 12.2SRA, manual keying is no longer supported.


  • Allows you to specify a lifetime for the IPSec security association (SA).
  • Allows encryption keys to change during IPSec sessions.
  • Allows IPSec to provide anti-replay services.
  • Permits certification authority (CA) support for a manageable, scalable IPSec implementation.
  • Allows dynamic authentication of peers.

Because IKE negotiations must be protected, each IKE negotiation begins by agreement of both peers on a common (shared) IKE policy. This policy states which security parameters will be used to protect subsequent IKE negotiations and mandates how the peers are authenticated. You must create an IKE policy at each peer participating in the IKE negotiation.

If you do not configure any IKE policies, your router will use the default policy, which is always set to the lowest priority and contains the default value of each parameter.

After the two peers agree upon a policy, the security parameters of the policy are identified by an SA established at each peer, and these SAs apply to all subsequent IKE traffic during the negotiation.

You can configure multiple, prioritized policies on each peer, each with a different combination of parameter values. However, at least one of these policies must contain exactly the same encryption, hash, authentication, and Diffie-Hellman parameter values as one of the policies on the remote peer. For each policy that you create, you assign a unique priority (1 through 10,000, with 1 being the highest priority).

Differences Between IKEv1 and IKEv2

IKE is available in two versions, IKEv1 and IKEv2. The complexity of IKEv1 made its widespread implementation difficult. IKEv2 had improved upon IKEv1 in the number of exchange messages and the renewed choices of the encryption and authentification algorithms. IKEv1 had many RFCs, IKE (RFC2409), ISAKMP (RFC2408), DOI (RFC2407), and others. IKEv2 has fewer and more consolidated RFCs.

IKEv2 has fewer phases and fewer number of messages to be exchanged during the phases, thus making it more flexible and simpler than IKEv1.

IKEv2 offers enhanced security by means of mechanisms that reduce the possibility of DoS type of attacks. To discourage DoS attacks, the responder may ask the initiator for a cookie as assurance that the connection is normal.

The restructuring of the interrelationship of attributes, transforms, and proposals in IKEv1 to a hierarchy ensures better understanding of the version. Greater flexibility in IKEv2 ensures that the communicating parties can choose SA lifetimes that are independent of each other.

Benefits of IKEv2

IKEv2 provides the following benefits:

  • Provides built-in support for dead peer detection (DPD) and network address translation-traversal (NAT-T).
  • To avoid fragmentation, certificates can be referenced through a URL and hash, instead of being sent within IKEv2 packets.
  • Allows the use of Extensible Authentication Protocol (EAP) for authentication.
  • Provides multiple crypto engines. If your network has both IPv4 and IPv6 traffic, and you have multiple crypto engines, choose one of the following configuration options:

One engine handles IPv4 traffic and the other engine handles IPv6 traffic.

One engine handles both IPv4 and IPv6 traffic.

  • IKEv2 uses sequence numbers and acknowledgments to provide reliability, and mandates some error processing logistics, and shared-state management.

IKEv2 Supported Standards

Cisco implements the IP Security (IPsec) Protocol for use in IKEv2.

The component technologies implemented in IKEv2 are as follows:

  • AES-CBC—Advanced Encryption Standard-Cipher Block Chaining
  • SHA (HMAC variant)—Secure Hash Algorithm
  • DH—A public-key cryptography protocol
  • DES—Data Encryption Standard
  • MD5 (HMAC [Hash-based Message Authentication Code] variant)—Message digest algorithm 5

Note Cisco no longer recommends using DES or MD5 (including the HMAC variant); instead, use AES and SHA-256. For more information about the latest Cisco cryptographic recommendations, see “Next Generation Encryption” available at: http://csio.cisco.com/blog/2011/10/14/next-generation-encryption/


For more information about supported standards and component technologies, see the “Supported Standards for Use with IKE” section in the “Configuring Internet Key Exchange for IPsec VPNs” of Internet Key Exchange for IPsec VPNs Configuration Guide at: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ikevpn/configuration/15-s/sec-ike-for-ipsec-vpns-15-s-book.pdf .

IKEv2 CLI Constructs

The IKEv2 CLI constructs include IKEv2 proposals, policies, profiles, and key rings.

IKEv2 Proposal

An Internet Key Exchange Version 2 (IKEv2) proposal is a collection of transforms used in the negotiation of Internet Key Exchange (IKE) security associations (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
  • DH group

IKEv2 Policy

An IKEv2 policy contains proposals that are used to negotiate the encryption, integrity, PRF algorithms, and DH group in the IKE_SA_INIT exchange. It can have match statements that are used as selection criteria to select a policy during negotiation.

For information about the default IKEv2 policy, see IKEv2 Smart Defaults.

IKEv2 Profile

An IKEv2 profile is a repository of nonnegotiable parameters of IKE SA, such as local or remote identities, and authentication methods and services that are available to authenticated peers that match the profile. An IKEv2 profile must be attached to either a crypto map or an IPSec profile on the initiator. An IKEv2 profile is not mandatory on the responder.

IKEv2 Key Ring

An IKEv2 key ring is a repository of symmetric and asymmetric preshared keys and is independent of the IKEv1 key ring. The IKEv2 key ring is associated with an IKEv2 profile, and hence supports a set of peers that match the IKEv2 profile.

IKEv2 Smart Defaults

The IKEv2 Smart Defaults feature minimizes the FlexVPN configuration by covering most of the use cases. IKEv2 smart defaults can be customized for specific use cases, although customization is not recommended.

The following rules apply to the IKEv2 Smart Defaults feature:

  • A default configuration is displayed in the corresponding show command with default as a keyword and with no argument. For example, the show crypto ikev2 proposal default command displays the default IKEv2 proposal and the show crypto ikev2 proposal command displays the default IKEv2 proposal, along with user-configured proposals, if any.
  • The default configuration is displayed in the show running-config all command; it is not displayed in the show running-config command.
  • You can modify the default configuration, which is displayed in the show running-config all command.
  • A default configuration can be disabled using the no form of the corresponding command, for example, no crypto ikev2 proposal default . A disabled default configuration is not used in negotiation, but the configuration is displayed in the show running-config command. A disabled default configuration loses user modification, if any, and restores the system-configured values.
  • A default configuration can be reenabled using the default form of the corresponding command, for example, default crypto ikev2 proposal .
  • The default mode for the default transform set is transport; the default mode for all other transform sets is tunnel.

Note We recommend you do not use MD5 (including the HMAC variant) and DH groups 1, 2 and 5; use SHA-256 and DH Groups 14 or higher instead. For more information about the latest Cisco cryptographic recommendations, see “Next Generation Encryption” available at: http://csio.cisco.com/blog/2011/10/14/next-generation-encryption/


The following table lists the commands that are enabled with the IKEv2 Smart Defaults feature, along with the default values.

Table 28-1 IKEv2 Command Defaults

Command Name
Default Values

crypto ikev2 authorization policy

Device# show crypto ikev2 authorization policy default

IKEv2 Authorization policy: default

route set interface

route accept any tag: 1 distance: 2

crypto ikev2 proposal

Device# show crypto ikev2 proposal default

IKEv2 proposal: default

Encryption: AES-CBC-256 AES-CBC-192 AESCBC-

128

Integrity: SHA512 SHA384 SHA256 SHA96 MD596

PRF: SHA512 SHA384 SHA256 SHA1 MD5

DH Group: DH_GROUP_1536_MODP/Group 5

DH_GROUP_1024_MODP/Group 2.

crypto ikev2 policy

Device# show crypto ikev2 policy default

IKEv2 policy: default

Match fvrf: any

Match address local: any

Proposal: default

crypto ipsec profile

Device# show crypto ipsec profile default

IPSEC profile default

Security association lifetime: 4608000

kilobytes/3600 seconds

Responder-Only (Y/N): N

PFS (Y/N): N

Transform sets={

default: { esp-aes esp-sha-hmac },

crypto ipsec transform-set

Device# show crypto ipsec transform-set

default

Transform set default: { esp-aes esp-shahmac}

will negotiate = { Tunnel, },


Note Before you use the default IPsec profile, explicitly specify the crypto ipsec profile command on a tunnel interface using the tunnel protection ipsec profile default command.


Information About IKEv2 Exchanges

IKE communications consist of pairs of messages, a request, and a response each, called exchanges. The first exchange of messages, the IKE_SA_INIT and IKE_AUTH exchanges establish an IKE SA. The initial exchanges normally consist of four messages. Subsequent IKE exchanges are called the CREATE_CHILD_SA or INFORMATIONAL exchanges. It is imperative that all IKE_SA_INIT exchanges be completed before any other exchange type, after which all IKE_AUTH exchanges must be completed. Thereafter, any number of CREATE_CHILD_SA and INFORMATIONAL exchanges occur in no preordained order.

An IKE message flow always consists of a request followed by a response. The requester ensures reliability. If the response is not received within a timeout interval, the requester either retransmits the request, or abandons the connection.

IKE_SA_INIT exchanges negotiate IKE SA security parameters, exchange DH keys and nonces. They are not crypto protected.

IKE_AUTH exchanges are crypto protected. They exchange identities, and prove knowledge of the secrets related to those identities. They also establish the IKE and the first, and usually the only, AH and, or or ESP CHILD-SA.

Informational exchanges happen only after the initial exchanges. They are status and control messages that are crypto protected. They delete SAs, report error conditions, check SA liveliness, and perform other SA housekeeping functions.

Configuring Basic IKEv2 CLI Constructs

To enable IKEv2 on a crypto interface, attach an IKEv2 profile to the crypto map or IPsec profile applied to the interface.


Note This step is optional on the IKEv2 responder.


Restrictions for Configuring IKEv2

  • 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 the AES type of encryption transform in a nonexportable image, or specify an encryption algorithm that a crypto engine does not support.

Note The difference between IKEv1 and IKEv2 is that you need not enable IKEv1 on individual interfaces because IKEv1 is enabled globally on all the interfaces on a device.


  • When IPsec SA is created by IKEv2, idle timeout does not work for IKEv2 IPsec SA.

To manually configure basic IKEv2 constructs, perform the following tasks:

Configuring IKEv2 Key Rings

Perform this task to configure the IKEv2 key ring if the local or remote authentication method is a preshared key.

IKEv2 key rings must be configured in the peer configuration submode that defines a peer subblock.

An IKEv2 key ring 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 the hostname, identity, and IP address.

IKEv2 key rings are independent of IKEv1 key rings. The key differences are as follows:

  • IKEv2 key rings support symmetric and asymmetric preshared keys.
  • IKEv2 key rings do not support Rivest, Shamir, and Adleman (RSA) public keys.
  • IKEv2 key rings are specified in the IKEv2 profile and are not looked up, unlike IKEv1, where keys are looked up on receipt of MM1 to negotiate the preshared key authentication method. The authentication method is not negotiated in IKEv2.
  • IKEv2 key rings are not associated with VPN routing and forwarding (VRF) during configuration. The VRF of an IKEv2 key ring is the VRF of the IKEv2 profile that refers to the key ring.
  • A single key ring can be specified in an IKEv2 profile, unlike an IKEv1 profile, which can specify multiple key rings.
  • A single key ring can be specified in more than one IKEv2 profile, if the same keys are shared across peers matching different profiles.
  • An IKEv2 key ring is structured as one or more peer sub-blocks.

On an IKEv2 initiator, the key lookup for the IKEv2 key ring is performed using the hostname of the peer or the address, in that order. On an IKEv2 responder, the key lookup is performed using the IKEv2 identity of the peer or the address, in that order.


Note You cannot configure the same identity in more than one peer.


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 }

9. pre-shared-key { local | remote } [ 0 | 6 ] line hex hexadecimal-string

10. end

Detailed Steps

Step
Command or Action
Purpose

Step 1

enable
Example:
Router#enable

Enables the privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal
Example:
Router#configure terminal

Enters the global configuration mode.

Step 3

crypto ikev2 keyring keyring-name
Example:
Router(config)#crypto ikev2 keyring keyring-1

Defines an IKEv2 key ring and enters the IKEv2 key ring configuration mode.

Step 4

peer name
Example:
Router(config-ikev2-keyring)#peer cisco

Defines the peer or peer group and enters IKEv2 key ring peer configuration mode.

Step 5

description line-of-description
Example:
Router(config-ikev2-keyring-peer)# description cisco with assymmetric keys

(Optional) Describes the peer or peer group.

Step 6

hostname name
Example:
Router(config-ikev2-keyring-peer)# hostname host1

Specifies the peer using a hostname.

Step 7

address { ipv4-address [mask] | i pv6-address prefix }
Example:
Router(config-ikev2-keyring-peer)# address 10.0.0.1 255.255.255.0

Specifies an IPv4 or IPv6 address or range for the peer.

Note This IP address is the IKE endpoint address.

Step 8

identity { address { ipv4-address | ipv6-address }
 
Example:
Router(config-ikev2-keyring-peer)# identity address 10.0.0.5

Identifies the IKEv2 peer through the IPv4 or IPv6 address.

Note The identity is available for key lookup on the IKEv2 responder only.

Step 9

pre-shared-key { local | remote } { 0 | 6 | line | hex }
Example:
Router(config-ikev2-keyring-peer)#pre-shared-key local key 1

Specifies the preshared key of the peer.

Step 10

end
Example:
Router(config-ikev2-keyring-peer)# end

Exits the IKEv2 key ring peer configuration mode.

Configuration Example for Keyring

Router#enable
Router#conf t
Router(config)#crypto ikev2 keyring keyring-1
Router(config-ikev2-keyring)#peer company
Router(config-ikev2-keyring-peer)#description first keyring
Router(config-ikev2-keyring-peer)#hostname host-1
Router(config-ikev2-keyring-peer)#address 10.0.0.1
% Address/Mask 10.0.0.1/255.255.255.255 is configured in peer 'cisco'
Router(config-ikev2-keyring-peer)#identity address 10.0.0.5
Router(config-ikev2-keyring-peer)#pre-shared key local 5
Router(config-ikev2-keyring-peer)#end

Configuring an IKEv2 Profile (Basic)

An IKEv2 profile is a repository of nonnegotiable parameters of the IKE SA such as:

  • Local or remote identities
  • Authentication methods
  • Services available to authenticated peers that match the profile

An IKEv2 profile must be configured and associated with either a crypto map or an IPsec profile on the IKEv2 initiator. Use the set ikev2-profile profile-name command to associate a profile with a crypto map or an IPsec profile. To disassociate the profile, use the no form of the command.

The following rules apply to match statements:

  • An IKEv2 profile must contain a match identity or a match certificate statement; otherwise, the profile is considered incomplete and is not used. An IKEv2 profile can have more than one match identity or match certificate statements.
  • An IKEv2 profile must have a single-match Front Door VPN routing and forwarding (FVRF) statement.
  • When a profile is selected, multiple match statements of the same type are logically used with the operator OR, and multiple match statements of different types are logically used with the AND operator.
  • The match identity and match certificate statements are considered to be the same type of statements and are used with the OR operator.
  • The configuration of overlapping profiles is considered a misconfiguration. In the case of multiple profile matches, no profile is selected.

SUMMARY STEPS

1. enable

2. configure terminal

3. crypto ikev2 profile profile-name

4. description line-of-description

5. aaa { accounting | authentication | authorization list-name }

6. authentication { local { rsa-sig | pre-share | ecdsa-sig | eap } | remote { eap [ query-identity | timeout seconds ] | rsa-sig | pre-share | ecdsa-sig }}

7. dpd interval retry-interval { on-demand | periodic }

8. identity local { address { ipv4-address | ipv6-address } | dn | email email-string | fqdn fqdn-string | keyid opaque-string }

9. initial-contact [ force ]

10. ivrf name

11. keyring { local keyring-name | aaa list-name name - mangler mangler-name }

12. lifetime seconds

13. 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 | fqdn } [ domain ] string | key-id opaque-string }}

14. nat keepalive seconds

15. pki trustpoint trustpoint-label [ sign | verify ]

16. redirect gateway auth

17. end

Detailed Steps

Command or Action
Purpose

Step 1

enable

Example:
Router#enable

Enables the privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:
Router#configure terminal

Enters the global configuration mode.

Step 3

crypto ikev2 profile profile-name

Example:
Router(config)#crypto ikev2 profile profile-1

Defines an IKEv2 profile and enters IKEv2 profile configuration mode.

Step 4

description line-of-description

Example:
Router(config-ikev2-profile)# description This is an IKEv2 profile

(Optional) Describes the profile.

Step 5

aaa { accounting | authentication | authorization list-name }

Example:
Router(config-ikev2-profile)# aaa authentication eap list-1

(Optional) Enables authentication, authorization, and accounting (AAA) method lists for IPsec sessions.

keyword is not specified, the AAA method list is used irrespective of the peer authentication method.

Step 6

authentication { local { rsa-sig | pre-share | ecdsa-sig | eap } | remote { eap [ query-identity | timeout seconds ] | rsa-sig | pre-shar e | ecdsa-sig }}

Example:
Router(config-ikev2-profile)# authentication remote pre-share

Specifies the local or remote authentication method.

Note You can specify only one local authentication method, but multiple remote authentication methods.

Step 7

dpd interval retry-interval { on-demand | periodic }

Example:
Router(config-ikev2-profile)#dpd 20 5 on-demand

(Optional) Configures dead peer detection (DPD) globally for peers matching the profile.

Note DPD is disabled by default.

Step 8

identity local { address { ipv4-address | ipv6-address } | dn | email email-string | fqdn fqdn-string | key-id opaque-string }

Example:
Router(config-ikev2-profile)# identity local email xyz@example.com

(Optional) Specifies the local IKEv2 identity type.

Note If the local authentication method is a preshared key, the default local identity is the IP address. If the local authentication method is an RSA signature, the default local identity is a Distinguished Name.

Step 9

initial-contact [ force ]

Example:
Router(config-ikev2-profile)#initial-contact force

Enforces initial contact processing if the initial contact notification is not received in the IKE_AUTH exchange.

Step 10

ivrf name

Example:
Router(config-ikev2-profile)#ivrf vrf1

(Optional) Specifies a user-defined VPN routing and forwarding (VRF) or global VRF if the IKEv2 profile is attached to a crypto map.

If the IKEv2 profile is used for tunnel protection, the Inside VRF (IVRF) for the tunnel interface should be configured on the tunnel interface.

Note IVRF specifies the VRF for cleartext packets. The default value for IVRF is FVRF.

Step 11

keyring { local keyring-name | aaa list-name }

Example:
Router(config-ikev2-profile)#keyring local keyring-1

Specifies the local or AAA-based key ring that must be used with the local and remote preshared key authentication method.

Note You can specify only one key ring. Local AAA is not supported for AAA-based preshared keys.

Step 12

lifetime seconds

Example:
Router(config-ikev2-profile)#lifetime 300

Specifies the lifetime, in seconds, for the IKEv2 SA.

Step 13

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 | fqdn } [ domain ] string | key-id opaque-string }}

Example:
Router(config-ikev2-profile)#match address 10.10.10.10

Uses match statements to select an IKEv2 profile for a peer.

Step 14

nat keepalive seconds

Example:
Router(config-ikev2-profile)#nat keepalive 300

(Optional) Enables NAT keepalive and specifies the duration in seconds.

Note NAT is disabled by default.

Step 15

pki trustpoint trustpoint-label [ sign | verify ]

Example:
Router(config-ikev2-profile)# pki trustpoint cisco sign

Specifies Public Key Infrastructure (PKI) trustpoints for use with the RSA signature authentication method.

keyword is not specified, the trustpoint is used for signing and verification.

Note In contrast to IKEv1, a trustpoint must be configured in an IKEv2 profile for certificate-based authentication to succeed. There is no fallback for globally configured trustpoints if this command is not present in the configuration. The trustpoint configuration applies to the IKEv2 initiator and responder.

Step 16

redirect gateway auth

Example:
Router(config-ikev2-profile)# redirect gateway auth

Enables the redirect mechanism on the gateway after SA authentication.

Note The redirect mechanism is specific to the IKEv2 profiles.

Step 17

end

Example:
Router(config-ikev2-profile)#end

Exits the IKEv2 profile configuration mode and returns to the privileged EXEC mode.

Sample Configuration: IKEv2 Profile

Router#enable
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#crypto ikev2 profile profile-1
Router(config-ikev2-profile)#description This is an ikev2 profile.
Router(config-ikev2-profile)#aaa authentication eap list-1
Router(config-ikev2-profile)#authentication remote pre-share
Router(config-ikev2-profile)#dpd 20 5 on-demand
Router(config-ikev2-profile)#identity local email xyz@example.com
Router(config-ikev2-profile)#initial-contact force
Router(config-ikev2-profile)#ivrf global
Router(config-ikev2-profile)#keyring local keyring-1
% Profile already contains this keyring
Router(config-ikev2-profile)#lifetime 200
Router(config-ikev2-profile)#match address 10.10.10.10
Router(config-ikev2-profile)#nat keepalive 100
Router(config-ikev2-profile)#redirect gateway auth
! (IKEv2 Cluster load-balancer is not enabled)
Router(config-ikev2-profile)#end

Verification of IKEv2 Profile Configuration

Use the show crypto ikev2 profile command to verify the configuration of an IKEv2 profile.

Router#show crypto ikev2 profile profile-1
 
IKEv2 profile: profile-1
Ref Count: 1
Description: This is an ikev2 profile.
Match criteria:
Fvrf: global
Local address/interface: none
Identities:
address 0.0.0.0
Certificate maps: none
Local identity: email xyz@example.com
Remote identity: none
Local authentication method: pre-share
Remote authentication method(s): pre-share
EAP options: none
Keyring: keyring-1
Trustpoint(s): none
Lifetime: 200 seconds
DPD: interval 20, retry-interval 5, on-demand
NAT-keepalive: 100 seconds
Ivrf: global
Virtual-template: none
AAA EAP authentication mlist: list-1

Information About IKEv2 Proposal

An 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 DH group configured. If no proposal is configured and attached to an IKEv2 policy, the default proposal in the default IKEv2 policy is used in negotiation.


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


Although the IKEv2 proposal works like the crypto isakmp policy command, the IKEv2 proposal is different in the following respects:

  • An IKEv2 proposal allows the configuration of one or more transforms
  • An IKEv2 proposal does not have any associated priority.

Configuring an IKEv2 Proposal

Perform this task to override the default IKEv2 proposal, or to manually configure the proposal, if you do not want to use the default proposal.

For information on the default IKEv2 proposal, see “IKEv2 Proposal” section.

SUMMARY STEPS

1. enable

2. configure terminal

3. crypto ikev2 proposal name

4. encryption { 3des } { aes-cbc-128 } { aes-cbc-192 } { aes-cbc-256 } { des }

5. integrity { md5 }{ sha1 } { sha256 } { sha384 } { sha512 }

6. group { 1 } { 14 } { 15 }{ 16 }{ 19 } { 2 } { 20 } { 24 } { 5 }

7. end

Detailed Steps

Command or Action
Purpose

Step 1

enable
Example:
Router#enable

Enables the privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal
Example:
Router#conf t

Enters the global configuration mode.

Step 3

crypto ikev2 proposal name
Example:
Router(config)#crypto ikev2 proposal proposal-1

Overrides the default IKEv2 proposal, defines an IKEv2 proposal name, and enters the IKEv2 proposal configuration mode.

Step 4

encryption { 3des } { aes-cbc-128 } { aes-cbc-192} {aes-cbc-256 }
Example:
Router(config-ikev2-proposal)#
encryption aes-cbc-192

Specifies one or more transforms of the encryption type, which are as follows:

  • 3des (No longer recommended)
  • aes-cbc-128
  • aes-cbc-192
  • aes-cbc-256

Step 5

integrity { md5 } { sha1 }{ sha256 } { sha384 }{ sha512 }
Example:
Router(config-ikev2-proposal)#
integrity sha1

Specifies one or more transforms of the integrity algorithm type, which are as follows:

  • The md5 keyword specifies MD5 (HMAC variant) as the hash algorithm. (No longer recommended)
  • The sha1 keyword specifies SHA-1 (HMAC variant) as the hash algorithm.
  • The sha256 keyword specifies SHA-2 family 256-bit (HMAC variant) as the hash algorithm.
  • The sha384 keyword specifies SHA-2 family 384-bit (HMAC variant) as the hash algorithm.
  • The sha512 keyword specifies SHA-2 family 512-bit (HMAC variant) as the hash algorithm.

Step 6

group { 1 } { 14 } { 15 } { 16 } { 19 }{ 2 } { 20 }{ 24 } { 5 }
Example:
Router(config-ikev2-proposal)#group 14

Specifies the DH group identifier.

The default DH group identifiers are group 2 and group 5 in the IKEv2 proposal:

  • 1—768-bit DH. (No longer recommended.)
  • 2—1024-bit DH. (No longer recommended.)
  • 5—1536-bit DH. (No longer recommended.)
  • 14—Specifies the 2048-bit DH group.
  • 15—Specifies the 3072-bit DH group.
  • 16—Specifies the 4096-bit DH group.
  • 19—Specifies the 256-bit elliptic curve DH (ECDH) group.
  • 20—Specifies the 384-bit ECDH group.
  • 24—Specifies the 2048-bit DH group.

The group that is chosen must be strong enough (have enough bits) to protect the IPsec keys during negotiation. A generally accepted guideline recommends the use of a 2048-bit group after 2013 (until 2030). Either group 14 or group 24 can be selected to meet this guideline. Even if a longer-lived security method is needed, the use of elliptic curve cryptography is recommended, but group 15 and group 16 can also be considered.

Step 7

end
Example:
Router(config-ikev2-proposal)#end

Exits the IKEv2 proposal configuration mode and returns to the privileged EXEC mode.


Note After you create the IKEv2 proposal, attach it to a policy so that the proposal is picked for negotiation. For information about completing this task, see the “Configuring IKEv2 Policies” section.


Configuration Example: IKEv2 Proposal

Router#enable
Router#conf t
Router(config)#crypto ikev2 proposal proposal-2
Router(config-ikev2-proposal)#encryption aes-cbc-192
Router(config-ikev2-proposal)#integrity sha1
Router(config-ikev2-proposal)#group 14
Router(config-ikev2-proposal)#end

Verification of IKEv2 Proposal Configuration

Use the show crypto ikev2 proposal [ name | default ] command to verify all the IKEv2 proposals. To verify the default proposal, use the command with the option ‘default’. To verify a user-defined proposal, use the command with the proposal name.

The following examples show sample output for the show crypto ikev2 proposal command:

Default Proposal

IKEv2 proposal: default
Encryption : AES-CBC-256 AES-CBC-192 AES-CBC-128
Integrity : SHA512 SHA384 SHA256 SHA96 MD596
PRF : SHA512 SHA384 SHA256 SHA1 MD5
DH Group : DH_GROUP_1536_MODP/Group 5 DH_GROUP_1024_MODP/Group 2

 

User-defined Proposal

IKEv2 proposal: proposal-2
Encryption : AES-CBC-192
Integrity : SHA96
PRF : SHA1
DH Group : DH_GROUP_2048_MODP/Group 14

Information About IKEv2 Policies

An IKEv2 policy must contain at least one proposal to be considered as complete and can have match statements, which are used as selection criteria to select a policy for negotiation. During the initial exchange, the local address (IPv4 or IPv6) and the Front Door VRF (FVRF) of the negotiating SA are matched with the policy and the proposal is selected.

The following rules apply to the match statements:

  • An IKEv2 policy without any match statements will match all peers in the global FVRF.
  • An IKEv2 policy can have only one match FVRF statement.
  • An IKEv2 policy can have one or more match address local statements.
  • When a policy is selected, multiple match statements of the same type are logically ORed and match statements of different types are logically ANDed.
  • There is no precedence between match statements of different types.
  • Configuration of overlapping policies is considered a misconfiguration. In the case of multiple, possible policy matches, the first policy is selected.

Configuring IKEv2 Policies

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

Detailed Steps

Command or Action
Purpose

Step 1

enable

Example
Router#enable

Enables the privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:
Router#configure terminal

Enters the global configuration mode.

Step 3

crypto ikev2 policy name

Example:
Router(config)#crypto ikev2 policy policy-1

Overrides the default IKEv2 policy, defines an IKEv2 policy name, and enters the IKEv2 policy configuration mode.

Step 4

proposal name

Example:
Router(config-ikev2-policy)#proposal proposal-1

Specifies the proposals that must be used with the policy.

The proposals are prioritized in the order of listing.


Note You must specify at least one proposal. You can specify additional proposals with each proposal in a separate statement.


Step 5

match fvrf { fvrf-name | any }

Example:
Router(config-ikev2-policy)#match fvrf any

(Optional) Matches the policy based on a user-configured FVRF or any FVRF.

The default is global FVRF.


Note The match fvrf any command must be explicitly configured in order to match any VRF. The FVRF specifies the VRF in which the IKEv2 packets are negotiated.


Step 6

match address local { ipv4-address | ipv6-address }

Example:
Router(config-ikev2-policy)#match address local 10.0.0.1

(Optional) Matches the policy based on the local IPv4 or IPv6 address.

The default matches all the addresses in the configured FVRF.

Step 7

end

Example:
Router(config-ikev2-policy)#end

Exits the IKEv2 policy configuration mode and returns to privileged EXEC mode.

Sample Configuration for IKEv2 Policy

Router#enable
Router#configure terminal
Router(config)#crypto ikev2 policy policy-1
Router(config-ikev2-policy)#proposal proposal-1
Router(config-ikev2-policy)#match address local 20.0.0.1
Router(config-ikev2-policy)#match fvrf any
Router(config-ikev2-policy)#end

Verification of IKEv2 Policy Configuration

Use the show crypto ikev2 policy [ policy-name | default ] command to view all configured IKEv2 policies.

Router#show crypto ikev2 policy
IKEv2 policy : default
Match fvrf : any
Match address local : any
Proposal : default
IKEv2 policy : policy-1
Match fvrf : any
Match address local : 10.0.0.1
Match address local : 20.0.0.1
Proposal : proposal-1

Verification of IKEv2 SA Configuration

Use the show crypto ikev2 sa command to verify the IKEv2 SA configuration.

Router#show crypto ikev2 sa fvrf A10150
IPv4 Crypto IKEv2 SA
 
Tunnel-id Local Remote fvrf/ivrf Status
82 171.0.150.1/500 171.0.150.2/500 A10150/A10150 READY
Encr: 3DES, Hash: MD596, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/965 sec
 
IPv6 Crypto IKEv2 SA

Verification of IKEv2 Session Configuration

Use the show crypto ikev2 session command to verify the IKEv2 session configuration.

Router#show crypto ikev2 session
IPv4 Crypto IKEv2 Session
Session-id:14719, Status:UP-ACTIVE, IKE count:1, CHILD count:1
 
Tunnel-id Local Remote fvrf/ivrf Status
82 171.0.150.1/500 171.0.150.2/500 A10150/A10150 READY
Encr: 3DES, Hash: MD596, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/1103 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0xF1306713/0x8B57E80

Verification of IKEv2 SA Statistics

Use the show crypto ikev2 stats command to verify IKEv2 SA statistics.

Router#show crypto ikev2 stats
--------------------------------------------------------------------------------
Crypto IKEv2 SA Statistics
--------------------------------------------------------------------------------
System Resource Limit: 0 Max IKEv2 SAs: 0 Max in nego: 40
Total IKEv2 SA Count: 126 active: 125 negotiating: 1
Incoming IKEv2 Requests: 14543 accepted: 14527 rejected: 16
Outgoing IKEv2 Requests: 2110 accepted: 1929 rejected: 181
Rejected IKEv2 Requests: 197 rsrc low: 0 SA limit: 197
IKEv2 packets dropped at dispatch: 0
Incoming IKEV2 Cookie Challenged Requests: 0
accepted: 0 rejected: 0 rejected no cookie: 0

 

Configuring Advanced Encryption Standard in an IKE Policy Map

The Advanced Encryption Standard (AES) is a privacy transform for IPSec and Internet Key Exchange (IKE) that has been developed to replace Data Encryption Standard (DES). AES is designed to be more secure than DES. AES offers a larger key size, while ensuring that the only known approach to decrypt a message is for an intruder to try every possible key. AES has a variable key length. The algorithm can specify a 128-bit key (the default), a 192-bit key, or a 256-bit key.

To configure the AES encryption algorithm within an IKE policy map, perform this task beginning in global configuration mode:

 

Command
Purpose

Step 1

Router(config)# crypto isakmp policy priority

Defines an ISAKMP policy and enters ISAKMP policy configuration mode.

  • priority —Identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 10000, with 1 being the highest priority and 10000 the lowest.

Step 2

Router(config-isakmp)# encryption { aes | aes 192 | aes 256 }

Specifies the encryption algorithm within an IKE policy.

  • aes —Specifies 128-bit AES as the encryption algorithm.
  • aes 192 —Specifies 192-bit AES as the encryption algorithm.
  • aes 256 —Specifies 256-bit AES as the encryption algorithm.

Step 3

...

Router(config-isakmp)# exit

Specifies any other policy values appropriate to your configuration, and then exits ISAKMP policy configuration mode.

For details on configuring an ISAKMP policy, see the Cisco IOS Security Configuration Guide .

Verifying the AES IKE Policy

To verify the configuration of the AES IKE policy, enter the show crypto isakmp policy command:

Router# show crypto isakmp policy
 
Protection suite of priority 1
encryption algorithm: AES - Advanced Encryption Standard (256 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
lifetime: 3600 seconds, no volume limit
 
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
 

For an AES configuration example, see the “Advanced Encryption Standard Configuration Example” section.

Configuring ISAKMP Keyrings

A crypto keyring is a collection of preshared and RSA public keys. You can configure a keyring and then associate it with the Internet Security Association and Key Management Protocol (ISAKMP) profile. The crypto ISAKMP profile may contain zero, one, or more than one keyring.

The ISAKMP keyrings feature (also known as the SafeNet IPSec VPN Client Support feature) allows you to use the local-address command to limit the scope of an ISAKMP profile or ISAKMP keyring configuration to a local termination address or interface. The benefit of this feature is that different customers can use the same peer identities and ISAKMP keys by using different local termination addresses.

ISAKMP Keyrings Configuration Guidelines and Restrictions

When configuring ISAKMP keyrings, follow these guidelines and restrictions:

  • The local address option works only for the primary address of an interface.
  • If an IP address is provided, the administrator must ensure that the connection of the peer terminates to the address that is provided.
  • If the IP address does not exist on the device, or if the interface does not have an IP address, the ISAKMP profile or ISAKMP keyring will be effectively disabled.

Limiting an ISAKMP Profile to a Local Termination Address or Interface

To configure an ISAKMP profile and limit it to a local termination address or interface, perform this task beginning in global configuration mode:

 

Command
Purpose

Step 1

Router(config)# crypto isakmp profile profile-name

Defines an ISAKMP profile and enters ISAKMP profile configuration mode.

  • profile-name —Name of the ISAKMP profile.

Step 2

Router(conf-isa-profile)# keyring keyring-name

(Optional) Configures a keyring with an ISAKMP profile.

  • keyring-name —Name of the crypto keyring.
Note A keyring is not needed inside an ISAKMP profile for local termination to work. Local termination works even if Rivest, Shamir, and Adelman (RSA) certificates are used.

Step 3

Router(conf-isa-profile)# match identity address address

Matches an identity from a peer in an ISAKMP profile.

  • address —IP address of the remote peer.

Step 4

Router(conf-isa-profile)# local-address { interface-name | ip-address [ vrf-tag ]}

Limits the scope of an ISAKMP profile or an ISAKMP keyring configuration to a local termination address or interface.

  • interface-name —Name of the local interface.
  • ip-address —Local termination address.
  • vrf-tag —(Optional) Scope of the IP address will be limited to the VRF.

Limiting a Keyring to a Local Termination Address or Interface

To configure an ISAKMP keyring and limit its scope to a local termination address or interface, perform this task beginning in global configuration mode:

 

Command
Purpose

Step 1

Router(config)# keyring keyring-name

Defines a crypto keyring to be used during IKE authentication and enters keyring configuration mode.

  • keyring-name —Name of the crypto keyring.

Step 2

Router(conf-keyring)# local-address { interface-name | ip-address [ vrf-tag ]}

Limits the scope of an ISAKMP profile or an ISAKMP keyring configuration to a local termination address or interface.

  • interface-name —Name of the local interface.
  • ip-address —Local termination address.
  • vrf-tag —(Optional) Scope of the IP address will be limited to the VRF.

Step 3

Router(conf-keyring )# pre-shared-key address address

Defines a preshared key to be used for IKE authentication.

  • address —IP address.

For complete configuration information for SafeNet IPSec VPN Client Support, refer to this URL:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_scse.html

For ISAKMP keyrings configuration examples, see the “ISAKMP Keyrings Configuration Examples” section.

Configuring Certificate to ISAKMP Profile Mapping

The Certificate to ISAKMP Profile Mapping feature enables you to assign an Internet Security Association and Key Management Protocol (ISAKMP) profile to a peer on the basis of the contents of arbitrary fields in the certificate. In addition, this feature allows you to assign a group name to those peers that are assigned an ISAKMP profile.


Note Certificate to ISAKMP Profile Mapping is only supported as of Cisco IOS Release 12.2(33)SRA.


Certificate to ISAKMP Profile Mapping Configuration Guidelines and Restrictions

Follow these guidelines and restrictions when configuring Certificate to ISAKMP Profile Mapping:

  • This feature will not be applicable if you use Rivest, Shamir, and Adelman (RSA)- signature or RSA-encryption authentication without certificate exchange. ISAKMP peers must be configured to do RSA-signature or RSA-encryption authentication using certificates.

Mapping the Certificate to the ISAKMP Profile

To map the certificate to the ISAKMP profile, perform the following task beginning in global configuration mode:

Command
Purpose

Step 1

Router(config)# crypto isakmp profile profile-name

Defines an ISAKMP profile and enters ISAKMP profile configuration mode

  • profile-name —Name of the user profile.

Step 2

Router(config-isa-prof)# match certificate certificate-map

Accepts the name of a certificate map.

  • certificate-map —Name of the certificate map.

Verifying the Certificate to ISAKMP Profile Mapping Configuration

To verify that the subject name of the certificate map has been properly configured, enter the show crypto pki certificates and the debug crypto isakmp commands.

The show crypto pki certificates command displays all current IKE security associations (SAs) at a peer. The debug crypto isakmp command displays messages about IKE events.

The following examples show that a certificate has been mapped to an ISAKMP profile. The examples include the configurations for the responder and initiator, the show crypto pki certificates command output verifying that the subject name of the certificate map has been configured, and the debug crypto isakmp command output showing that the certificate has gone through certificate map matching and been matched to the ISAKMP profile.

Responder Configuration

crypto pki certificate map cert_map 10
! The above line is the certificate map definition.
subject-name co ou = green
! The above line shows that the subject name must have "ou = green."
!
crypto isakmp profile certpro
! The above line shows that this is the ISAKMP profile that will match if the certificate
of the peer matches cert_map (shown on third line below).
ca trust-point 2315
ca trust-point LaBcA
match certificate cert_map
 

Initiator Configuration

crypto ca trustpoint LaBcA
enrollment url http://10.76.82.20:80/cgi-bin/openscep
subject-name ou=green,c=IN
! The above line ensures that the subject name "ou = green" is set.
revocation-check none
 

Command Output for show crypto pki certificates for the Initiator

Router# show crypto pki certificates
Certificate
Status: Available
Certificate Serial Number: 21
Certificate Usage: General Purpose
Issuer:
cn=blue-lab CA
o=CISCO
c=IN
Subject:
Name: Router.cisco.com
c=IN
ou=green
! The above line is a double check that "ou = green" has been set as the subject name.
hostname=Router.cisco.com
Validity Date:
start date: 14:34:30 UTC Mar 31 2004
end date: 14:34:30 UTC Apr 1 2009
renew date: 00:00:00 UTC Jan 1 1970
Associated Trustpoints: LaBcA
 

Command Output for debug crypto isakmp for the Responder

Router# debug crypto isakmp
 
*Nov 6 19:31:25.010: ISAKMP:(0): SA request profile is prof2
*Nov 6 19:31:25.010: ISAKMP: Found a peer struct for 14.0.0.2, peer port 500
*Nov 6 19:31:25.010: ISAKMP: Locking peer struct 0x13884FB8, refcount 349 for isakmp_initiator
*Nov 6 19:31:25.010: ISAKMP[I]: sa->swdb: Vlan3
*Nov 6 19:31:25.010: ISAKMP: local port 500, remote port 500
*Nov 6 19:31:25.010: ISAKMP: set new node 0 to QM_IDLE
*Nov 6 19:31:25.010: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 13C041E8
*Nov 6 19:31:25.010: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
*Nov 6 19:31:25.010: ISAKMP:(0):Profile has no keyring, aborting key search
*Nov 6 19:31:25.010: ISAKMP:(0): constructed NAT-T vendor-07 ID
*Nov 6 19:31:25.010: ISAKMP:(0): constructed NAT-T vendor-03 ID
*Nov 6 19:31:25.010: ISAKMP:(0): constructed NAT-T vendor-02 ID
*Nov 6 19:31:25.010: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
*Nov 6 19:31:25.010: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1
 
*Nov 6 19:31:25.010: ISAKMP:(0): beginning Main Mode exchange
*Nov 6 19:31:25.010: ISAKMP:(0): sending packet to 14.0.0.2 my_port 500 peer_port 500 (I) MM_NO_STATE
*Nov 6 19:31:25.018: ISAKMP (0): received packet from 14.0.0.2 dport 500 sport 500 fvrf (N) NEW SA
*Nov 6 19:31:25.018: ISAKMP: Found a peer struct for 14.0.0.2, peer port 500
*Nov 6 19:31:25.018: ISAKMP: Locking peer struct 0x13884FB8, refcount 350 for crypto_isakmp_process_block
*Nov 6 19:31:25.018: ISAKMP[R]: sa->swdb: Vlan2
*Nov 6 19:31:25.018: ISAKMP: local port 500, remote port 500
*Nov 6 19:31:25.018: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 148C68D8
*Nov 6 19:31:25.018: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Nov 6 19:31:25.018: ISAKMP:(0):Old State = IKE_READY New State = IKE_R_MM1
 
*Nov 6 19:31:25.018: ISAKMP:(0): processing SA payload. message ID = 0
*Nov 6 19:31:25.018: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.018: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
*Nov 6 19:31:25.018: ISAKMP (0): vendor ID is NAT-T v7
*Nov 6 19:31:25.018: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.018: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch
*Nov 6 19:31:25.018: ISAKMP:(0): vendor ID is NAT-T v3
*Nov 6 19:31:25.018: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.018: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch
*Nov 6 19:31:25.018: ISAKMP:(0): vendor ID is NAT-T v2
*Nov 6 19:31:25.038: ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy
*Nov 6 19:31:25.038: ISAKMP: encryption 3DES-CBC
*Nov 6 19:31:25.038: ISAKMP: hash MD5
*Nov 6 19:31:25.038: ISAKMP: default group 1
*Nov 6 19:31:25.038: ISAKMP: auth RSA sig
*Nov 6 19:31:25.038: ISAKMP: life type in seconds
*Nov 6 19:31:25.038: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Nov 6 19:31:25.042: ISAKMP:(0):atts are acceptable. Next payload is 3
*Nov 6 19:31:25.042: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.042: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
*Nov 6 19:31:25.042: ISAKMP (0): vendor ID is NAT-T v7
*Nov 6 19:31:25.042: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.042: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch
*Nov 6 19:31:25.042: ISAKMP:(0): vendor ID is NAT-T v3
*Nov 6 19:31:25.042: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.042: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch
*Nov 6 19:31:25.042: ISAKMP:(0): vendor ID is NAT-T v2
*Nov 6 19:31:25.042: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Nov 6 19:31:25.042: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM1
 
*Nov 6 19:31:25.046: ISAKMP:(0): constructed NAT-T vendor-07 ID
*Nov 6 19:31:25.046: ISAKMP:(0): sending packet to 14.0.0.2 my_port 500 peer_port 500 (R) MM_SA_SETUP
*Nov 6 19:31:25.046: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Nov 6 19:31:25.046: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2
 
*Nov 6 19:31:25.046: ISAKMP (0): received packet from 14.0.0.2 dport 500 sport 500 fvrf (I) MM_NO_STATE
*Nov 6 19:31:25.046: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Nov 6 19:31:25.046: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2
 
*Nov 6 19:31:25.046: ISAKMP:(0): processing SA payload. message ID = 0
*Nov 6 19:31:25.046: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.046: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
*Nov 6 19:31:25.046: ISAKMP (0): vendor ID is NAT-T v7
*Nov 6 19:31:25.046: ISAKMP : Looking for xauth in profile prof2
*Nov 6 19:31:25.046: ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy
*Nov 6 19:31:25.046: ISAKMP: encryption 3DES-CBC
*Nov 6 19:31:25.046: ISAKMP: hash MD5
*Nov 6 19:31:25.046: ISAKMP: default group 1
*Nov 6 19:31:25.046: ISAKMP: auth RSA sig
*Nov 6 19:31:25.050: ISAKMP: life type in seconds
*Nov 6 19:31:25.050: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Nov 6 19:31:25.050: ISAKMP:(0):atts are acceptable. Next payload is 0
*Nov 6 19:31:25.050: ISAKMP:(0): processing vendor id payload
*Nov 6 19:31:25.050: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
*Nov 6 19:31:25.050: ISAKMP (0): vendor ID is NAT-T v7
*Nov 6 19:31:25.050: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Nov 6 19:31:25.050: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM2
 
*Nov 6 19:31:25.050: ISAKMP (0): constructing CERT_REQ for issuer cn=mscavpn1,ou=isbu,o=cisco
*Nov 6 19:31:25.054: ISAKMP:(0): sending packet to 14.0.0.2 my_port 500 peer_port 500 (I) MM_SA_SETUP
*Nov 6 19:31:25.054: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Nov 6 19:31:25.054: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM3
 
*Nov 6 19:31:25.058: ISAKMP (0): received packet from 14.0.0.2 dport 500 sport 500 fvrf (R) MM_SA_SETUP
*Nov 6 19:31:25.062: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Nov 6 19:31:25.062: ISAKMP:(0):Old State = IKE_R_MM2 New State = IKE_R_MM3
 
*Nov 6 19:31:25.062: ISAKMP:(0): processing KE payload. message ID = 0
*Nov 6 19:31:25.062: ISAKMP:(0): processing NONCE payload. message ID = 0
*Nov 6 19:31:25.062: ISAKMP:(83727): processing CERT_REQ payload. message ID = 0
*Nov 6 19:31:25.062: ISAKMP:(83727): peer wants a CT_X509_SIGNATURE cert
*Nov 6 19:31:25.066: ISAKMP:(83727): peer want cert issued by cn=mscavpn1,ou=isbu,o=cisco
*Nov 6 19:31:25.066: ISAKMP:(83727): Choosing trustpoint MSCA as issuer
*Nov 6 19:31:25.066: ISAKMP:(83727): processing vendor id payload
*Nov 6 19:31:25.066: ISAKMP:(83727): vendor ID is DPD
*Nov 6 19:31:25.066: ISAKMP:(83727): processing vendor id payload
*Nov 6 19:31:25.066: ISAKMP:(83727): speaking to another IOS box!
*Nov 6 19:31:25.066: ISAKMP:(83727): processing vendor id payload
*Nov 6 19:31:25.066: ISAKMP:(83727): vendor ID seems Unity/DPD but major 230 mismatch
*Nov 6 19:31:25.066: ISAKMP:(83727): vendor ID is XAUTH
*Nov 6 19:31:25.066: ISAKMP (83727): His hash no match - this node outside NAT
*Nov 6 19:31:25.066: ISAKMP (83727): No NAT Found for self or peer
*Nov 6 19:31:25.066: ISAKMP:(83727):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Nov 6 19:31:25.066: ISAKMP:(83727):Old State = IKE_R_MM3 New State = IKE_R_MM3
 
*Nov 6 19:31:25.066: ISAKMP (83727): constructing CERT_REQ for issuer cn=mscavpn1,ou=isbu,o=cisco
*Nov 6 19:31:25.066: ISAKMP:(83727): sending packet to 14.0.0.2 my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Nov 6 19:31:25.070: ISAKMP:(83727):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Nov 6 19:31:25.070: ISAKMP:(83727):Old State = IKE_R_MM3 New State = IKE_R_MM4
 
*Nov 6 19:31:25.070: ISAKMP (0): received packet from 14.0.0.2 dport 500 sport 500 fvrf (I) MM_SA_SETUP
*Nov 6 19:31:25.070: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Nov 6 19:31:25.070: ISAKMP:(0):Old State = IKE_I_MM3 New State = IKE_I_MM4
 
*Nov 6 19:31:25.070: ISAKMP:(0): processing KE payload. message ID = 0
*Nov 6 19:31:25.074: ISAKMP:(0): processing NONCE payload. message ID = 0
*Nov 6 19:31:25.098: ISKAMP: growing send buffer from 1024 to 3072
 
*Nov 6 19:31:25.118: ISAKMP (83727): received packet from 14.0.0.2 dport 500 sport 500 fvrf (R) MM_KEY_EXCH
*Nov 6 19:31:25.122: ISAKMP:(83727):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Nov 6 19:31:25.122: ISAKMP:(83727):Old State = IKE_R_MM4 New State = IKE_R_MM5
 
*Nov 6 19:31:25.122: ISAKMP:(83727): processing ID payload. message ID = 0
*Nov 6 19:31:25.122: ISAKMP (83727): ID payload
next-payload : 6
type : 3
USER FQDN : a@vrf2.com
protocol : 17
port : 500
length : 18
*Nov 6 19:31:25.134: ISAKMP:(83727):: peer matches prof2 profile
*Nov 6 19:31:25.134: ISAKMP:(83727): processing CERT payload. message ID = 0
*Nov 6 19:31:25.134: ISAKMP:(83727): processing a CT_X509_SIGNATURE cert
*Nov 6 19:31:25.142: ISAKMP:(83727): peer's pubkey isn't cached
*Nov 6 19:31:25.158: %CRYPTO-6-IKMP_NO_ID_CERT_USER_FQDN_MATCH: ID of a@vrf2.com (type 3) and certificate user fqdn with empty
*Nov 6 19:31:25.158: ISAKMP (83727): adding peer's pubkey to cache
*Nov 6 19:31:25.158: ISAKMP:(83727): processing SIG payload. message ID = 0
*Nov 6 19:31:25.162: ISAKMP:(83727):SA authentication status:
authenticated
*Nov 6 19:31:25.162: ISAKMP:(83727):SA has been authenticated with 14.0.0.2
*Nov 6 19:31:25.162: ISAKMP:(83727):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Nov 6 19:31:25.162: ISAKMP:(83727):Old State = IKE_R_MM5 New State = IKE_R_MM5
 
*Nov 6 19:31:25.170: ISAKMP:(83727):SA is doing RSA signature authentication using id type ID_USER_FQDN
*Nov 6 19:31:25.170: ISAKMP (83727): ID payload
next-payload : 6
type : 3
USER FQDN : a@vrf2.com
protocol : 17
port : 500
length : 18
*Nov 6 19:31:25.170: ISAKMP:(83727):Total payload length: 18
*Nov 6 19:31:25.182: ISAKMP (83727): constructing CERT payload for cn=HUB,ou=isbu,o=cisco,hostname=HUB.cisco.com,serialNumber=1234D
*Nov 6 19:31:25.182: ISKAMP: growing send buffer from 1024 to 3072
*Nov 6 19:31:25.186: ISAKMP:(83727): using the MSCA trustpoint's keypair to sign
*Nov 6 19:31:25.194: ISAKMP:(83727): sending packet to 14.0.0.2 my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Nov 6 19:31:25.198: ISAKMP:(83727):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Nov 6 19:31:25.198: ISAKMP:(83727):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE
 
*Nov 6 19:31:25.198: ISAKMP:(83727):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
*Nov 6 19:31:25.198: ISAKMP:(83727):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
 
*Nov 6 19:31:25.238: ISAKMP (83727): received packet from 14.0.0.2 dport 500 sport 500 fvrf (R) QM_IDLE
*Nov 6 19:31:25.238: ISAKMP: set new node -134314170 to QM_IDLE
*Nov 6 19:31:25.242: ISAKMP:(83727): processing HASH payload. message ID = -134314170
*Nov 6 19:31:25.242: ISAKMP:(83727): processing SA payload. message ID = -134314170
*Nov 6 19:31:25.242: ISAKMP:(83727):Checking IPSec proposal 1
*Nov 6 19:31:25.242: ISAKMP: transform 1, ESP_3DES
*Nov 6 19:31:25.242: ISAKMP: attributes in transform:
*Nov 6 19:31:25.242: ISAKMP: encaps is 1 (Tunnel)
*Nov 6 19:31:25.242: ISAKMP: SA life type in seconds
*Nov 6 19:31:25.242: ISAKMP: SA life duration (basic) of 3600
*Nov 6 19:31:25.242: ISAKMP: SA life type in kilobytes
*Nov 6 19:31:25.242: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
*Nov 6 19:31:25.242: ISAKMP: authenticator is HMAC-SHA
*Nov 6 19:31:25.242: ISAKMP:(83727):atts are acceptable.
*Nov 6 19:31:25.242: ISAKMP:(83727): processing NONCE payload. message ID = -134314170
*Nov 6 19:31:25.242: ISAKMP:(83727): processing ID payload. message ID = -134314170
*Nov 6 19:31:25.242: ISAKMP:(83727): processing ID payload. message ID = -134314170
*Nov 6 19:31:25.242: ISAKMP:(83727):QM Responder gets spi
*Nov 6 19:31:25.242: ISAKMP:(83727):Node -134314170, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*Nov 6 19:31:25.242: ISAKMP:(83727):Old State = IKE_QM_READY New State = IKE_QM_SPI_STARVE
*Nov 6 19:31:25.242: ISAKMP:(83727): Creating IPSec SAs
*Nov 6 19:31:25.246: inbound SA from 14.0.0.2 to 15.0.0.2 (f/i) 1/714
(proxy 12.0.0.2 to 13.0.0.2)
*Nov 6 19:31:25.246: has spi 0x917AD879 and conn_id 0
*Nov 6 19:31:25.246: lifetime of 3600 seconds
*Nov 6 19:31:25.246: lifetime of 4608000 kilobytes
*Nov 6 19:31:25.246: outbound SA from 15.0.0.2 to 14.0.0.2 (f/i) 1/714
(proxy 13.0.0.2 to 12.0.0.2)
*Nov 6 19:31:25.246: has spi 0xC54A5A05 and conn_id 0
*Nov 6 19:31:25.246: lifetime of 3600 seconds
*Nov 6 19:31:25.246: lifetime of 4608000 kilobytes
*Nov 6 19:31:25.246: ISAKMP: Failed to find peer index node to update peer_info_list
*Nov 6 19:31:25.250: ISAKMP:(83727): sending packet to 14.0.0.2 my_port 500 peer_port 500 (R) QM_IDLE
*Nov 6 19:31:25.250: ISAKMP:(83727):Node -134314170, Input = IKE_MESG_INTERNAL, IKE_GOT_SPI
*Nov 6 19:31:25.250: ISAKMP:(83727):Old State = IKE_QM_SPI_STARVE New State = IKE_QM_R_QM2
*Nov 6 19:31:25.270: ISAKMP (83727): received packet from 14.0.0.2 dport 500 sport 500 fvrf (R) QM_IDLE
*Nov 6 19:31:25.274: ISAKMP:(83727):deleting node -134314170 error FALSE reason "QM done (await)"
*Nov 6 19:31:25.274: ISAKMP:(83727):Node -134314170, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*Nov 6 19:31:25.274: ISAKMP:(83727):Old State = IKE_QM_R_QM2 New State = IKE_QM_PHASE2_COMPLETE
*Nov 6 19:32:15.282: ISAKMP:(83727):purging node -134314170
 

Command Output for show crypto isakmp sa [detail] for the Responder

Router# show crypto isakmp sa vrf vrf2
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
15.0.0.2 14.0.0.2 QM_IDLE 83727 ACTIVE prof2
 
IPv6 Crypto ISAKMP SA
 
Router# show crypto isakmp sa detail vrf vrf2
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA
 
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
 
83727 15.0.0.2 14.0.0.2 vrf2 ACTIVE 3des md5 rsig 1 23:59:15
Engine-id:Conn-id = :15727
 
IPv6 Crypto ISAKMP SA
 

Assigning the Group Name to the Peer

To associate a group name with an ISAKMP profile that will be assigned to a peer, perform the following steps beginning in global configuration mode:

Command
Purpose

Step 1

Router(config)# crypto isakmp profile profile-name

Defines an ISAKMP profile and enters ISAKMP profile configuration mode

  • profile-name —Name of the user profile.

Step 2

Router (conf-isa-prof)# client configuration group group-name

Accepts the name of a group that will be assigned to a peer when the peer is assigned this crypto ISAKMP profile.

  • group-name —Name of the group to be associated with the peer.

Verifying the Group Name to Peer Assignation Configuration

To verify that a group has been assigned to a peer, enter the debug crypto isakmp command.

The debug crypto isakmp command displays messages about IKE events.

The following debug crypto isakmp output shows that the peer has been matched to the ISAKMP profile named “certpro” and that it has been assigned a group named “new_group.”

Initiator Configuration

crypto isakmp profile certpro
ca trust-point 2315
ca trust-point LaBcA
match certificate cert_map
client configuration group new_group
! The statement on the above line will assign the group "new_group" to any peer that
matches the ISAKMP profile "certpro."
initiate mode aggressive
 

Command Output for debug crypto isakmp for the Responder

Router# debug crypto isakmp
6d23h: ISAKMP (0:268435461): received packet from 192.0.0.2 dport 500 sport 500 Global (R)
MM_KEY_EXCH
6d23h: ISAKMP: Main Mode packet contents (flags 1, len 892):
6d23h: ID payload
6d23h: FQDN <Router1.cisco.com> port 500 protocol 17
6d23h: CERT payload
6d23h: SIG payload
6d23h: KEEPALIVE payload
6d23h: NOTIFY payload
6d23h: ISAKMP:(0:5:HW:2):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
6d23h: ISAKMP:(0:5:HW:2):Old State = IKE_R_MM4 New State = IKE_R_MM5
6d23h: ISAKMP:(0:5:HW:2): processing ID payload. message ID = 0
6d23h: ISAKMP (0:268435461): ID payload
next-payload : 6
type : 2
FQDN name : Router1.cisco.com
protocol : 17
port : 500
length : 28
6d23h: ISAKMP:(0:5:HW:2):: peer matches *none* of the profiles
6d23h: ISAKMP:(0:5:HW:2): processing CERT payload. message ID = 0
6d23h: ISAKMP:(0:5:HW:2): processing a CT_X509_SIGNATURE cert
6d23h: ISAKMP:(0:5:HW:2): peer's pubkey isn't cached
6d23h: ISAKMP:(0:5:HW:2): OU = green
6d23h: ISAKMP:(0:5:HW:2): certificate map matches certpro profile
6d23h: ISAKMP:(0:5:HW:2): Trying to re-validate CERT using new profile
6d23h: ISAKMP:(0:5:HW:2): Creating CERT validation list: 2315, LaBcA,
6d23h: ISAKMP:(0:5:HW:2): CERT validity confirmed.
6d23h: ISAKMP:(0:5:HW:2):Profile has no keyring, aborting key search
6d23h: ISAKMP:(0:5:HW:2): Profile certpro assigned peer the group named new_group
 

For complete configuration information for certificate to ISAKMP profile mapping, refer to this URL:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gt_isakp.html

For certificate to ISAKMP profile mapping configuration examples, see the “Certificate to ISAKMP Profile Mapping Configuration Examples” section.

Configuring an Encrypted Preshared Key

The Encrypted Preshared Key feature allows you to securely store plain text passwords in type 6 (encrypted) format in NVRAM.

Encrypted Preshared Key Configuration Guidelines and Restrictions

Follow these guidelines and restrictions when configuring an encrypted preshared key:

  • Old ROM monitors (ROMMONs) and boot images cannot recognize the new type 6 passwords. If you boot from an old ROMMON, you can expect errors.
  • If the password (master key) is changed, or reencrypted, using the key config-key password-encryption command, the list registry passes the old key and the new key to the application modules that are using type 6 encryption.
  • If the master key that was configured using the key config-key password-encryption command is deleted from the system, a warning is printed (and a confirm prompt is issued) that states that all type 6 passwords will become useless. As a security measure, after the passwords have been encrypted, they will never be decrypted in the Cisco IOS software. However, passwords can be reencrypted.

Caution If the password configured using the key config-key password-encryption command is lost, it cannot be recovered. The password should be stored in a safe location.

  • If you later unconfigure password encryption using the no password encryption aes command, all existing type 6 passwords are left unchanged, and as long as the password (master key) that was configured using the key config-key password-encryption command exists, the type 6 passwords will be decrypted as and when required by the application.
  • Because no one can “read” the password (configured using the key config-key password-encryption command), there is no way that the password can be retrieved from the router. Existing management stations cannot “know” what it is unless the stations are enhanced to include this key somewhere, in which case the password needs to be stored securely within the management system. If configurations are stored using TFTP, the configurations are not standalone, meaning that they cannot be loaded onto a router. Before or after the configurations are loaded onto a router, the password must be manually added (using the key config-key password-encryption command). The password can be manually added to the stored configuration but is not recommended because adding the password manually allows anyone to decrypt all passwords in that configuration.
  • If you enter or cut and paste cipher text that does not match the master key, or if there is no master key, the cipher text is accepted or saved, but the following alert message is printed:
ciphertext>[for username bar>] is incompatible with the configured master key
 
  • If a new master key is configured, all the plain keys are encrypted and made type 6 keys. The existing type 6 keys are not encrypted. The existing type 6 keys are left as is.
  • If the old master key is lost or unknown, you have the option of deleting the master key using the no key config-key password-encryption command. Deleting the master key using the no key config-key password-encryption command causes the existing encrypted passwords to remain encrypted in the router configuration. The passwords will not be decrypted.

Configuring an Encrypted Preshared Key

To configure an encrypted preshared key, perform the following task beginning global configuration mode:

 

Command
Purpose

Step 1

Router(config)# key config-key password-encryption

Stores a type 6 encryption key in private NVRAM.

Note the following:

  • If you are entering the key interactively (using the Enter key) and an encrypted key already exists, you will be prompted for the following:
Old key, New key, and Confirm key
 
  • If you are entering the key interactively but an encryption key is not present, you will be prompted for the following:
New key and Confirm key
 
  • If you are removing a password that is already encrypted, you will see the following prompt:
WARNING: All type 6 encrypted keys will become unusable. Continue with master key deletion? [yes/no] :

Step 2

Router(config)# password-encryption aes

Enables the encrypted preshared key.

Verifying the Encrypted Preshared Key Configuration

To verify that a new master key has been configured and that the keys have been encrypted with the new master key, enter the password logging command. The following is an example of its output:

Router(config)# password logging
 
Router(config)# key config-key password-encrypt
 
New key:
Confirm key:
Router(config)#
01:40:57: TYPE6_PASS: New Master key configured, encrypting the keys with
the new master keypas
 
Router(config)# key config-key password-encrypt
Old key:
New key:
Confirm key:
Router (config)#
01:42:11: TYPE6_PASS: Master key change heralded, re-encrypting the keys
with the new master key
01:42:11: TYPE6_PASS: Mac verification successful
01:42:11: TYPE6_PASS: Mac verification successful
01:42:11: TYPE6_PASS: Mac verification successful
 

For complete configuration information for the Encrypted Preshared Key feature, refer to this URL:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_epsk.html

For an encrypted preshared key configuration example, see the “Encrypted Preshared Key Configuration Example” section.

Configuring Call Admission Control for IKE

Call Admission Control (CAC) for IKE allows you to limit the number of simultaneous IKE security associations (SAs) that a router can establish.


Note Call Admission Control is supported in Cisco IOS Release 12.2(33)SRA and later releases.


There are two ways to limit the number of IKE SAs that a router can establish to or from another router:

  • Configure an absolute IKE SA limit by entering the crypto call admission limit command.

When an IKE SA limit is defined, the router no longer accepts or initiates new IKE SA requests when this value has been reached as follows: When there is a new SA request from a peer router, IKE determines if the number of active IKE SAs plus the number of SAs being negotiated meets or exceeds the configured SA limit. If the number is greater than or equal to the limit, the new SA request is rejected and a syslog is generated. This log contains the source destination IP address of the SA request.

  • Configure a system resource limit by entering the call admission limit command.

When a system resource limit is defined, the router no longer accepts or initiates new IKE SA requests when the specified level of system resources is being used as follows: Call Admission Control (CAC) polls a global resource monitor so that IKE knows when the router is running short of CPU cycles or memory buffers. You can configure a resource limit, from 1 to 100000, that represents a level of system resources. When that level of the system resources is being used, IKE no longer accepts or initiates new IKE SA requests.

CAC is applied to new SAs (that is, when an SA does not already exist between the peers) and rekeying SAs. Every effort is made to preserve existing SAs. Only new SA requests will ever be denied due to a lack of system resources or because the configured IKE SA limit has been reached.

Configuring the IKE Security Association Limit

To configure an IKE Security Association limit, perform the following steps beginning in global configuration mode. When an IKE SA limit is defined, the router no longer accepts or initiates new IKE SA requests when the limit has been reached:

Command
Purpose

Step 1

Router(config)# crypto call admission limit { ike { sa number | in-negotiation-sa number }}

Specifies the maximum number of IKE SAs that the router can establish before IKE no longer accepts or initiates new SA requests.

  • sa number —Number of active IKE SAs allowed on the router. The range is 0 to 99999.
  • in-negotiation-sa number —Number of in-negotiation IKE SAs allowed on the router. The range is 10 to 99999.
Note An ISAKMP connection needs to be built in two directions. If you have 500 spokes in your network, you should set this value at a minimum of 1000 (500 x 2).

Step 2

Router(config)# exit

Returns to privileged EXEC mode.

Configuring a System Resource Limit

To configure a system resource limit, perform the following steps beginning in global configuration mode. When an IKE SA limit is defined, the router no longer accepts or initiates new IKE SA requests when the specified level of system resources is being used.

Command
Purpose

Step 1

Router(config)# call admission limit charge

Instructs IKE to stop initiating or accepting new SA requests (that is, calls for CAC) when the specified level of system resources is being used.

  • charge —Level of the system resources that, when used, causes IKE to stop accepting new SA requests. Valid values are 1 to 100000.

Step 2

Router(config)# exit

Returns to privileged EXEC mode.

Clearing Call Admission Statistics

To clear the Call Admission Control counters that track the number of accepted and rejected Internet Key Exchange (IKE) requests, use the clear crypto call admission statistics command in global configuration mode:

Router(config)# clear crypto call admission statistics

Verifying the Call Admission Control for IKE Configuration

To verify that Call Admission Control has been configured, enter the show call admission statistics and the show crypto call admission statistics commands.

The show call admission statistics command monitors the global CAC configuration parameters and the behavior of CAC.

Router# show call admission statistics
Total Call admission charges: 0, limit 25
Total calls rejected 12, accepted 51
Load metric: charge 0, unscaled 0
 

The show crypto call admission statistics command monitors crypto CAC statistics.

Router# show crypto call admission statistics
-----------------------------------------------------------
Crypto Call Admission Control Statistics
-----------------------------------------------------------
System Resource Limit: 0 Max IKE SAs 0
Total IKE SA Count: 0 active: 0 negotiating: 0
Incoming IKE Requests: 0 accepted: 0 rejected: 0
Outgoing IKE Requests: 0 accepted: 0 rejected: 0
Rejected IKE Requests: 0 rsrc low: 0 SA limit: 0
 

For more complete configuration information for Call Admission Control for IKE, refer to the following URL:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gtcallik.html

For Call Admission Control for IKE configuration examples, see the “Call Admission Control for IKE Configuration Examples” section.

Configuring Dead Peer Detection

Dead Peer Detection (DPD), defined in RFC 3706, is a mechanism used to detect dead IPSec peers. IPSec is a peer-to-peer type of technology. It is possible that IP connectivity may be lost between peers due to routing problems, peer reloading, or some other situation. This lost connectivity can result in black holes where traffic is lost. DPD, based on a traffic-detection method, is one possible mechanism to remedy this situation.


Note The periodic option of the crypto isakmp keepalive command is only supported as of Cisco IOS Release 12.2(33)SRA; the on-demand option is supported in all releases.


DPD supports two options: on-demand or periodic. The on-demand approach is the default. With on-demand DPD, messages are sent on the basis of traffic patterns. For example, if a router must send outbound traffic and the liveliness of the peer is questionable, the router sends a DPD message to query the status of the peer. If a router has no traffic to send, it never sends a DPD message. If a peer is dead, and the router never has any traffic to send to the peer, the router will not find out until the IKE or IPSec security association (SA) has to be rekeyed (the liveliness of the peer is unimportant if the router is not trying to communicate with the peer). On the other hand, if the router has traffic to send to the peer, and the peer does not respond, the router will initiate a DPD message to determine the state of the peer.

With the periodic option, you can configure your router so that DPD messages are “forced” at regular intervals. This forced approach results in earlier detection of dead peers. For example, if a router has no traffic to send, a DPD message is still sent at regular intervals, and if a peer is dead, the router does not have to wait until the IKE SA times out to find out.

DPD is configured using the crypto isakmp keepalive command. DPD and Cisco IOS keepalives function on the basis of a timer. If the timer is set for 10 seconds, the router will send a “hello” message every 10 seconds (unless, of course, the router receives a “hello” message from the peer). The benefit of Cisco IOS keepalives and periodic DPD is earlier detection of dead peers. However, Cisco IOS keepalives and periodic DPD rely on periodic messages that have to be sent with considerable frequency. The result of sending frequent messages is that the communicating peers must encrypt and decrypt more packets.

DPD and Cisco IOS keepalive features can be used in conjunction with multiple peers in the crypto map to allow for stateless failover. DPD allows the router to detect a dead IKE peer, and when the router detects the dead state, the router deletes the IPSec and IKE SAs to the peer. If you configure multiple peers, the router will switch over to the next listed peer for a stateless failover.

DPD Configuration Guidelines and Restrictions

When configuring DPD, follow these guidelines and restrictions:

  • When the crypto isakmp keepalive command is configured, the Cisco IOS software negotiates the use of Cisco IOS keepalives or DPD, depending on which protocol the peer supports.
  • If you do not configure the periodic option using the crypto isakmp keepalive command, the router defaults to the on-demand approach.
  • Before configuring periodic DPD, you should ensure that your IKE peer supports DPD. Implementations that support DPD include the Cisco VPN 3000 concentrator, Cisco PIX Firewall, Cisco VPN Client, and Cisco IOS software in all modes of operation—site-to-site, Easy VPN remote, and Easy VPN server.
  • Using periodic DPD potentially allows the router to detect an unresponsive IKE peer with better response time when compared to on-demand DPD. However, use of periodic DPD incurs extra overhead. When communicating to large numbers of IKE peers, you should consider using on-demand DPD instead.
  • When you configure DPD using the crypto isakmp keepalive seconds command, the seconds argument specifies the interval between DPD messages. In the case of on-demand DPD, the actual interval may be up to twice the configured value.

Configuring a Dead Peer Detection Message

To allow the router to send DPD messages to the peer, perform the following task:

 

Command
Purpose

Router# crypto isakmp keepalive seconds [ retries ] [ periodic | on-demand ]

Converts Switch 1 to standalone mode.

  • seconds —Specifies the number of seconds between DPD messages; the range is from 10 to 3600 seconds.
  • retries —(Optional) Specifies the number of seconds between DPD retries if the DPD message fails; the range is from 2 to 60 seconds. If unspecified, the default is 2 seconds.
  • periodic —(Optional) Specifies that the DPD messages are sent at regular intervals.
  • on-demand —(Optional) Specifies that DPD retries are sent on demand. This is the default behavior.

Note Because the on-demand option is the default, the on-demand keyword does not appear in configuration output.


Verifying the DPD Configuration

To verify that DPD is enabled, use the show crypto isakmp sa detail command in global mode:

Router# show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
 
C-id Local Remote I-VRF Encr Hash Auth DH Lifetime Cap.
273 11.0.0.2 11.0.0.1 ivrf21 3des sha psk 2 01:59:35 D
Connection-id:Engine-id = 273:2(hardware)
 

For more complete configuration information for Cisco IOS Dead Peer Detection (DPD) support, refer to the Cisco IOS Security Command Reference, Release 12.3.

For DPD configuration examples, see the “Dead Peer Detection Configuration Examples” section.

Understanding IPSec NAT Transparency

The IPSec NAT transparency feature introduces support for IP Security (IPSec) traffic to travel through Network Address Translation (NAT) or Port Address Translation (PAT) points in the network by addressing many known incompatibilities between NAT and IPSec.

Before the introduction of this feature, a standard IPSec virtual private network (VPN) tunnel would not work if there were one or more NAT or PAT points in the delivery path of the IPSec packet. This feature allows IPSec to operate through a NAT/PAT device.

For detailed information on NAT Transparency, refer to the following URL:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftipsnat.html

IPSec NAT Transparency Configuration Guidelines and Restrictions

When configuring IPSec NAT transparency, follow these guidelines and restrictions:

  • For non-GRE over IPSec configurations, NAT transparency is supported in both tunnel and transport modes.
  • For point-to-point GRE over IPSec configurations, NAT transparency is supported only in tunnel mode.
  • For DMVPN configurations, NAT transparency is supported only in transport mode.

Configuring NAT Transparency

NAT transparency is a feature that is auto-detected by the IPSec VPN SPA. There are no configuration steps. If both VPN devices are NAT transparency-capable, NAT transparency is auto-detected and auto-negotiated.

Disabling NAT Transparency

You might want to disable NAT transparency if you already know that your network uses IPSec-awareness NAT (SPI-matching scheme). To disable NAT transparency, use the following command in global configuration mode:

Router(config)# no crypto ipsec nat-transparency udp-encapsulation
 

Configuring NAT Keepalives

By default, the NAT keepalive feature is disabled. To configure your router to send NAT keepalive packets, enter the crypto isakmp nat keepalive command in global configuration mode:

Router(config)# crypto isakmp nat keepalive seconds
 

In this command, seconds specifies the number of seconds between keepalive packets; range is between 5 to 3,600 seconds.

For a NAT keepalives configuration example, see the “ISAKMP NAT Keepalive Configuration Example” section.

Verifying the NAT Configuration

To verify the NAT configuration, enter the show crypto ipsec sa command:


Note When you first enter the show crypto ipsec sa command, the packet counters may not show the correct values. Repeat the command to show the updated values.


Router# show crypto ipsec sa
 
interface:GigabitEthernet5/0/1
Crypto map tag:testtag, local addr. 10.2.80.161
 
local ident (addr/mask/prot/port):(10.2.80.161/255.255.255.255/0/0)
remote ident (addr/mask/prot/port):(100.0.0.1/255.255.255.255/0/0)
current_peer:100.0.0.1:4500
PERMIT, flags={origin_is_acl,}
#pkts encaps:109, #pkts encrypt:109, #pkts digest 109
#pkts decaps:109, #pkts decrypt:109, #pkts verify 109
#pkts compressed:0, #pkts decompressed:0
#pkts not compressed:0, #pkts compr. failed:0, #pkts decompress failed:0
#send errors 90, #recv errors 0
 
local crypto endpt.:10.2.80.161, remote crypto endpt.:100.0.0.1:4500
path mtu 1500, media mtu 1500
current outbound spi:23945537
 
inbound esp sas:
spi:0xF423E273(4095992435)
transform:esp-des esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
slot:0, conn id:200, flow_id:1, crypto map:testtag
sa timing:remaining key lifetime (k/sec):(4607996/2546)
IV size:8 bytes
replay detection support:Y
 
inbound ah sas:
 
inbound pcp sas:
 
outbound esp sas:
spi:0x23945537(596923703)
transform:esp-des esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
slot:0, conn id:201, flow_id:2, crypto map:testtag
sa timing:remaining key lifetime (k/sec):(4607998/2519)
IV size:8 bytes
replay detection support:Y
 
outbound ah sas:
 
outbound pcp sas:
 

For complete configuration information for Cisco IOS IPSec NAT transparency support, refer to this URL:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftipsnat.html

Configuration Examples

This section provides examples of the following configurations:

Advanced Encryption Standard Configuration Example

The following example configures the Advanced Encryption Standard (AES) 256-bit key:

crypto isakmp policy 10
encr aes 256
authentication pre-share
 

ISAKMP Keyrings Configuration Examples

The following examples show how to limit the scope of an Internet Security Association and Key Management Protocol (ISAKMP) profile or ISAKMP keyring configuration to a local termination address or interface:

ISAKMP Profile Bound to a Local Interface Configuration Example

The following example configures an ISAKMP profile bound to a local interface:

crypto isakmp profile prof1
keyring key0
match identity address 11.0.0.2 255.255.255.255
local-address serial2/0

ISAKMP Keyring Bound to a Local Interface Configuration Example

The following example configures an ISAKMP keyring bound only to interface serial2/0:

crypto keyring key0
local-address serial2/0
pre-shared-key address 11.0.0.2 key 12345

ISAKMP Keyring Bound to a Local IP Address Configuration Example

The following example configures an ISAKMP keyring bound only to IP address 10.0.0.2:

crypto keyring key0
local-address 11.0.0.1
pre-shared-key address 11.0.0.2 key 12345

Certificate to ISAKMP Profile Mapping Configuration Examples

The following examples show how to configure Certificate to ISAKMP Profile Mapping:

Certificates Mapped to the ISAKMP Profile on the Basis of Arbitrary Fields Configuration Example

The following example shows that whenever a certificate contains “ou = green,” the ISAKMP profile “cert_pro” will be assigned to the peer:

crypto pki certificate map cert_map 10
subject-name co ou = green
!
crypto isakmp identity dn
crypto isakmp profile cert_pro
ca trust-point 2315
ca trust-point LaBcA
match certificate cert_map

Group Name Assigned to a Peer Associated with an ISAKMP Profile Configuration Example

The following example shows that the group “some_group” is to be associated with a peer that has been assigned an ISAKMP profile:

crypto isakmp profile id_profile
ca trust-point 2315
match identity host domain cisco.com
 
client configuration group some_group

Encrypted Preshared Key Configuration Example

The following example shows a configuration for which a type 6 preshared key has been encrypted:

Router(config)# password encryption aes
Router(config)# key config-key password-encrypt
New key:
Confirm key:
Router(config)#
0:46:40: TYPE6_PASS: New Master key configured, encrypting the keys with
the new master key
Router(config)# exit

Call Admission Control for IKE Configuration Examples

The following examples show how to configure Call Admission Control (CAC) for IKE:

IKE Security Association Limit Configuration Example

The following example shows how to specify that there can be a maximum of 25 SAs before IKE starts rejecting new SA requests:

Router(config)# crypto call admission limit ike sa 25

System Resource Limit Configuration Example

The following example shows how to specify that IKE should drop SA requests when a given level of system resources are being used:

Router(config)# call admission limit 50000

Dead Peer Detection Configuration Examples

The following examples show how to configure Dead Peer Detection (DPD):

On-Demand DPD Configuration Example

The following example shows how to configure on-demand DPD messages. In this example, DPD messages will be sent every 60 seconds and every 5 seconds between retries if the peer does not respond:

Router(config)# crypto isakmp keepalive 60 5

Periodic DPD Configuration Example

The following example shows how to configure periodic DPD messages. In this example, DPD messages are to be sent at intervals of 10 seconds:

Router(config)# crypto isakmp keepalive 10 periodic

ISAKMP NAT Keepalive Configuration Example

The following example shows how to enable NAT keepalives to be sent every 20 seconds:

crypto isakmp policy 1
authentication pre-share
crypto isakmp key 1234 address 56.0.0.1
crypto isakmp nat keepalive 20
!
!
crypto ipsec transform-set t2 esp-des esp-sha-hmac
!
crypto map test2 10 ipsec-isakmp
set peer 56.0.0.1
set transform-set t2
match address 101