Courseiva
VPNGlobal Config

crypto isakmp policy [priority]

Creates or modifies an ISAKMP (IKE) policy for IPsec VPN negotiations, defining encryption, authentication, and key exchange parameters.

Definition: crypto isakmp policy [priority] is a Cisco IOS global config command. Creates or modifies an ISAKMP (IKE) policy for IPsec VPN negotiations, defining encryption, authentication, and key exchange parameters.

Overview

The `crypto isakmp policy [priority]` command is a cornerstone of IPsec VPN configuration on Cisco IOS devices. It creates or modifies an Internet Security Association and Key Management Protocol (ISAKMP) policy, which defines the parameters used during Phase 1 of IKE (Internet Key Exchange) negotiations. ISAKMP, also known as IKE, is responsible for establishing a secure, authenticated channel between two VPN peers before any actual data encryption (IPsec Phase 2) occurs. This command is essential for any network engineer deploying site-to-site or remote-access VPNs, as it dictates the encryption algorithm (e.g., AES, 3DES), authentication method (pre-shared key or RSA signatures), hash algorithm (SHA, MD5), Diffie-Hellman group, and the lifetime of the security association. Without a properly configured ISAKMP policy, IPsec peers cannot agree on how to protect the initial key exchange, and the VPN tunnel will fail to establish.

The networking concept behind ISAKMP is the establishment of a secure control channel. In IPsec VPNs, two phases exist: Phase 1 (IKE) creates a secure tunnel for negotiating Phase 2 parameters, and Phase 2 (IPsec) creates the actual data encryption tunnel. The ISAKMP policy defines the security parameters for Phase 1. When two peers attempt to establish a VPN, they exchange their configured ISAKMP policies and try to find a match. The peer with the lower priority number (higher priority) sends its policy list; the other peer checks if it has a matching policy (same encryption, hash, auth, DH group, lifetime). If a match is found, Phase 1 proceeds; otherwise, the negotiation fails. This command is used when you need to define or modify these parameters. It is typically one of the first steps in VPN configuration, followed by setting the pre-shared key (`crypto isakmp key`) and then defining IPsec transform sets and crypto maps.

Alternatives to this command include using IKEv2 (via `crypto ikev2 proposal`), which is more modern and flexible, but IKEv1 (ISAKMP) remains widely deployed for legacy compatibility. In some scenarios, you might use a default policy (Cisco IOS has a built-in default ISAKMP policy with low security), but best practice is to define explicit policies. The command operates in global configuration mode and requires privilege level 15. Changes take immediate effect on the running configuration but do not affect existing tunnels until they renegotiate (e.g., after a clear crypto sa). The command is stored in the running config and can be saved to startup config. A common mistake is forgetting that the policy priority number determines the order of negotiation; lower numbers are tried first. Also, the lifetime parameter is often overlooked—if not set, it defaults to 86400 seconds (1 day), which may be too long for some security policies.

Syntax·Global Config
crypto isakmp policy [priority]

When to Use This Command

  • Setting up a site-to-site VPN between two branch offices using pre-shared keys.
  • Configuring a remote access VPN for mobile workers with certificate-based authentication.
  • Establishing a VPN tunnel to a cloud provider (e.g., AWS VPN) with matching IKE parameters.
  • Upgrading an existing VPN policy to use stronger encryption (e.g., AES-256) for compliance.

Parameters

ParameterSyntaxDescription
priority<1-10000>Unique identifier for the ISAKMP policy. Lower numbers have higher priority and are tried first during negotiation. Valid range is 1 to 10000. Common mistake: using the same priority for multiple policies (overwrites the existing one) or not remembering that the peer must have a matching policy with the same parameters.
encryptiondes | 3des | aes | aes 192 | aes 256Encryption algorithm for Phase 1. Options: des (56-bit, weak, avoid), 3des (168-bit, legacy), aes (128-bit), aes 192 (192-bit), aes 256 (256-bit). Default is des. Common mistake: using weak encryption like DES in production; always use AES.
hashsha | sha256 | sha384 | sha512 | md5Hash algorithm for integrity verification. Options: sha (SHA-1, 160-bit), sha256, sha384, sha512 (more secure), md5 (128-bit, weak). Default is sha. Common mistake: using MD5 which is considered insecure.
authenticationpre-share | rsa-sig | rsa-encrAuthentication method. Options: pre-share (pre-shared key), rsa-sig (RSA signatures using certificates), rsa-encr (RSA encrypted nonces, rarely used). Default is rsa-sig. Common mistake: forgetting to configure the pre-shared key with `crypto isakmp key` when using pre-share.
group1 | 2 | 5 | 14 | 15 | 16 | 19 | 20 | 21 | 24Diffie-Hellman group for key exchange. Options: 1 (768-bit), 2 (1024-bit), 5 (1536-bit), 14 (2048-bit), 15 (3072-bit), 16 (4096-bit), 19 (256-bit ECP), 20 (384-bit ECP), 21 (521-bit ECP), 24 (2048-bit with 256-bit subgroup). Default is 1 (weak). Common mistake: using group 1 or 2 in modern networks; use group 14 or higher.
lifetime<60-86400>Lifetime of the ISAKMP security association in seconds. Range 60 to 86400. Default is 86400 (1 day). Common mistake: setting too short a lifetime causes frequent renegotiation; too long reduces security.

Command Examples

Create ISAKMP policy with pre-shared key and AES-256

crypto isakmp policy 10
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 14
 lifetime 86400

Policy priority 10 is created. 'encr aes 256' sets encryption to AES-256. 'authentication pre-share' uses pre-shared keys. 'group 14' sets Diffie-Hellman group 14 (2048-bit). 'lifetime 86400' sets the SA lifetime to 86400 seconds (24 hours).

View configured ISAKMP policies

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

The output shows the configured policy (priority 10) with AES-256, SHA-512, pre-shared key, DH group 14, and 86400s lifetime. The default policy uses weak DES, SHA-1, RSA signatures, DH group 1 (768-bit), and same lifetime. For CCNA, note that default is weak and should be replaced.

Understanding the Output

The 'show crypto isakmp policy' command displays all configured ISAKMP policies in order of priority (lower number = higher priority). Each policy shows encryption algorithm (e.g., DES, 3DES, AES), hash algorithm (MD5, SHA-1, SHA-256, etc.), authentication method (pre-share, rsa-sig, dsa-sig), Diffie-Hellman group (1, 2, 5, 14, etc.), and lifetime in seconds. The default policy is always present with weak settings.

In a real network, you should ensure policies match between peers; mismatched parameters cause VPN negotiation failure. Good values: AES-256, SHA-256 or higher, DH group 14 or higher, pre-shared key or certificates. Bad values: DES, MD5, DH group 1.

Watch for 'no volume limit' which is normal; volume-based lifetime is rarely used.

Configuration Scenarios

Site-to-Site VPN with Pre-Shared Key and AES-256

Two branch offices need a secure VPN tunnel over the internet. Both routers are Cisco IOS devices. The goal is to establish an IPsec VPN using strong encryption and authentication.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2 R1 LAN: 192.168.1.0/24, R2 LAN: 192.168.2.0/24

Steps

  1. 1.Step 1: Enter global configuration mode on R1: configure terminal
  2. 2.Step 2: Create ISAKMP policy with priority 10: crypto isakmp policy 10
  3. 3.Step 3: Set encryption to AES 256: encryption aes 256
  4. 4.Step 4: Set hash to SHA-256: hash sha256
  5. 5.Step 5: Set authentication to pre-share: authentication pre-share
  6. 6.Step 6: Set Diffie-Hellman group 14: group 14
  7. 7.Step 7: Set lifetime to 3600 seconds: lifetime 3600
  8. 8.Step 8: Exit policy configuration: exit
  9. 9.Step 9: Configure pre-shared key: crypto isakmp key MySecretKey address 10.0.12.2
  10. 10.Step 10: Repeat similar steps on R2 with matching parameters.
Configuration
! R1 Configuration
crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 3600
crypto isakmp key MySecretKey address 10.0.12.2
! Additional IPsec transform set and crypto map configuration needed

Verify: Use `show crypto isakmp policy` to display configured policies. Expected output shows policy 10 with AES256, SHA256, pre-share, group 14, lifetime 3600. Also use `show crypto isakmp sa` to see active Phase 1 SAs after negotiation.

Watch out: Ensure both peers have identical ISAKMP policy parameters (encryption, hash, auth, group, lifetime). A mismatch in any parameter will cause negotiation failure. Also, the pre-shared key must match exactly.

Remote Access VPN with Certificate Authentication

A company wants to allow remote employees to connect to the corporate network using IPsec VPN with certificate-based authentication (RSA signatures). The headend router acts as the VPN concentrator.

Topology

Remote Client (AnyConnect)---Internet---(Gi0/0)Headend Router Headend LAN: 10.10.10.0/24

Steps

  1. 1.Step 1: On the headend router, enter global config: configure terminal
  2. 2.Step 2: Create ISAKMP policy with priority 20: crypto isakmp policy 20
  3. 3.Step 3: Set encryption to AES 128: encryption aes
  4. 4.Step 4: Set hash to SHA: hash sha
  5. 5.Step 5: Set authentication to rsa-sig: authentication rsa-sig
  6. 6.Step 6: Set group 2: group 2
  7. 7.Step 7: Set lifetime to 86400: lifetime 86400
  8. 8.Step 8: Exit and configure PKI trustpoint and certificates (not shown here).
Configuration
! Headend Router
crypto isakmp policy 20
 encryption aes
 hash sha
 authentication rsa-sig
 group 2
 lifetime 86400
! PKI and certificate configuration required

Verify: Use `show crypto isakmp policy` to verify policy 20. Use `show crypto isakmp sa` to see Phase 1 SAs. For certificate issues, use `debug crypto pki`.

Watch out: Certificate authentication requires proper PKI infrastructure. Ensure the router has a valid certificate and the remote client trusts the CA. The ISAKMP policy must use rsa-sig, and the peer's certificate must be valid.

Troubleshooting with This Command

When troubleshooting ISAKMP policy issues, the first step is to verify the configured policies on both peers using `show crypto isakmp policy`. Healthy output lists each policy with its parameters in a clear table. Problem indicators include missing policies, mismatched parameters, or default policies that are too weak. Focus on the encryption, hash, authentication, group, and lifetime fields. If the peer cannot find a matching policy, the negotiation fails silently or with a 'no acceptable proposal' message in debugs.

Common symptoms this command helps diagnose: (1) VPN tunnel not coming up – check if both peers have at least one matching ISAKMP policy. (2) Slow VPN establishment – often due to mismatched DH groups (e.g., group 1 vs group 2). (3) Security compliance issues – weak algorithms like DES or MD5 may be flagged. (4) Frequent renegotiation – check lifetime values; if one side has a much shorter lifetime, it will trigger rekey often.

Step-by-step diagnostic flow: 1. On each peer, run `show crypto isakmp policy` and compare parameters. 2. If no match, modify one peer's policy to align. 3. Use `debug crypto isakmp` to see negotiation messages. Look for 'No acceptable proposal' or 'Policy not found'. 4. Verify pre-shared keys with `show crypto isakmp key` (if using pre-share). 5. Check that the peer's IP address is correct in the key command. 6. For certificate issues, use `show crypto pki certificates` and `debug crypto pki`. 7. Clear existing SAs with `clear crypto sa` to force renegotiation after changes.

Correlate with other commands: `show crypto ipsec sa` shows Phase 2 SAs; if Phase 1 fails, Phase 2 will not exist. `show crypto isakmp sa detail` provides more details on active SAs, including peer IP and status. `debug crypto isakmp` is powerful but verbose; use with caution in production. Also, `show crypto engine connections active` can show encryption engine statistics. Remember that ISAKMP policy changes only affect new negotiations; existing tunnels continue until they rekey or are cleared.

CCNA Exam Tips

1.

CCNA exam tip: Remember that lower priority number means higher priority; policy 10 is preferred over policy 20.

2.

CCNA exam tip: Default ISAKMP policy uses DES and MD5/SHA-1; you must configure a stronger policy for security.

3.

CCNA exam tip: The 'group' command sets Diffie-Hellman group; group 14 (2048-bit) is commonly tested.

4.

CCNA exam tip: Lifetime is in seconds; default 86400 (24 hours). Shorter lifetimes increase security but cause more frequent renegotiation.

Common Mistakes

Mistake: Forgetting to configure the same ISAKMP policy parameters on both VPN peers, causing negotiation failure.

Mistake: Using a weak encryption (DES) or hash (MD5) that is not secure and may be rejected by modern peers.

Mistake: Setting a very short lifetime (e.g., 120 seconds) causing excessive rekeying and CPU load.

crypto isakmp policy [priority] vs crypto ipsec transform-set [name] esp-aes esp-sha-hmac

Both commands are fundamental to IPsec VPN configuration but operate at different phases: crypto isakmp policy defines IKE phase 1 parameters for key exchange, while crypto ipsec transform-set specifies phase 2 protection for actual data traffic. They are often confused because both involve setting encryption and authentication algorithms, yet serve distinct roles within a VPN policy.

Aspectcrypto isakmp policy [priority]crypto ipsec transform-set [name] esp-aes esp-sha-hmac
ScopePhase 1 (IKE) policyPhase 2 (IPsec) transform set
Configuration modeGlobal configurationGlobal configuration
PersistenceRemains in running config until deletedRemains in running config until deleted
PrecedenceLower priority number = higher preferenceNo precedence; referred by name in crypto map
Typical useDefine encryption, hash, DH group, lifetime for IKEDefine encryption and integrity algorithms for ESP or AH

Use crypto isakmp policy [priority] when configuring the IKE phase 1 parameters that authenticate peers and establish a secure tunnel for IPsec key negotiation.

Use crypto ipsec transform-set [name] esp-aes esp-sha-hmac when specifying the encryption and integrity algorithms for protecting actual IPsec data traffic in a crypto map entry.

Platform Notes

In IOS-XE (e.g., Catalyst 9000 switches, ISR 4000 series), the `crypto isakmp policy` command syntax is identical to classic IOS. However, IOS-XE 16.x and later strongly recommend using IKEv2 (`crypto ikev2 proposal`) for new deployments. The output of `show crypto isakmp policy` may include additional fields like 'FIPS' status.

On NX-OS (Nexus switches), the equivalent command is `crypto ikev1 policy <priority>` (for IKEv1) or `crypto ikev2 proposal <name>` (for IKEv2). NX-OS uses a different structure; for example, `crypto ikev1 policy 10` then subcommands like `encryption aes-256`, `hash sha256`, `authentication pre-shared`, `group 14`, `lifetime 3600`. Note the hyphen in 'pre-shared' and 'aes-256'.

On ASA firewalls, the equivalent is `crypto ikev1 policy <priority>` (or `crypto ikev2 policy <priority>` for IKEv2) with similar subcommands. ASA syntax uses `encryption aes-256`, `hash sha`, `authentication pre-share`, `group 14`, `lifetime 3600`. The ASA also supports `crypto ikev1 enable` to activate IKE on an interface.

In IOS-XR (e.g., ASR 9000), the command is `crypto ikev1 policy <priority>` under the IKE profile configuration. IOS-XR uses a different configuration hierarchy; you must first create an IKE profile and then associate the policy. Overall, while the concept is consistent across platforms, the exact syntax and configuration flow vary.

Always consult the platform-specific documentation.

Related Commands

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions