When deploying GETVPN, proper verification is critical to ensure your crypto configurations, rekey operations, and tunnel policies are correctly applied and active. Below are essential CLI commands and their interpretations for a healthy GETVPN environment.

1. IKE and IPsec State Checks

Use the show crypto isakmp sa command to verify the ISAKMP Security Association (SA) status between group members (GMs) and the key server (KS). A typical output should display the GDOI_IDLE state and a status of ACTIVE, indicating successful ISAKMP negotiation.

Next, show crypto ipsec sa on a GM helps confirm that an IPsec tunnel exists and provides detailed statistics. Look for non-zero values under encrypt, decrypt, and SPI to validate packet flow. The SPI (Security Parameter Index) confirms active SA binding.

2. GDOI Key Server and Group Member Info

To inspect the group members registered with the key server, run show crypto gdoi ks members. This command displays each GM’s IP, registration status, and how many rekeys were acknowledged or missed. A successful registration shows status as “Registered”, with “Rekey Acks Rcvd” > 0.

On the GM, use show crypto gdoi gm to see which key server it registered to, the assigned ACL, and current SA details. It should also list the rekey statistics;  how many were received and acknowledged.

3. Policy Verification

On the KS, use show crypto gdoi ks policy to verify the KEK and TEK policy parameters. The KEK (Key Encryption Key) section outlines parameters like the encryption algorithm (e.g., 3DES), key size, rekey intervals, and signature info. The TEK (Traffic Encryption Key) portion details the actual data plane policy, including transform set (e.g., esp-aes esp-sha-hmac), ACL used, SPI, and TEK life.

Confirm ACLs using show crypto gdoi ks acl and show crypto gdoi gm acl to ensure traffic selectors match. ACLs are usually downloaded from the KS and must reflect intended crypto traffic.

4. Group Configuration and Rekey Status

Run show crypto gdoi group GETVPN to summarize group-wide status. This includes group identity, number of registered members, key lifetimes, rekey timers, and current IPSec SAs. Key timers like “Remaining Lifetime” and “Time to Rekey” provide a snapshot of the key lifecycle.

The show crypto gdoi ks rekey command lets you verify rekey statistics such as how many rekeys were sent, retransmissions, and remaining lifetimes of both KEK and TEK SAs. All values should reflect normal operations (e.g., KEK life of 400s, IPSec SA life of 3600s).

5. Redundancy with COOP

If you’re running GETVPN with Cooperative Key Server (COOP) functionality, use show crypto gdoi ks and show crypto gdoi ks coop to verify primary and secondary key server synchronization. These commands reveal which KS is primary, the peer’s status, priority, anti-replay sequence numbers, and session health (IKE status should be “Established”).

6. Replay Protection and PKI Certificates

To confirm replay protection, check show crypto gdoi ks replay. If Time-Based Replay is enabled, it will be noted here. You can also inspect PKI trust status via show crypto pki certificates. This will list available certificates and validate the trustpoint used to sign GDOI messages (important if using digital signatures over PSKs).

7. COOP Key Server Policy Checks

With Cooperative Key Servers, it’s crucial that both primary and secondary maintain consistent policies. Run show crypto gdoi ks policy on both the primary (e.g., 1.1.1.1) and secondary (e.g., 5.5.5.5) to validate synchronization.

The KEK policy section confirms encryption (e.g., 3DES), key lengths, and rekey intervals (e.g., 400 seconds with 79 seconds remaining). The TEK policy outlines the data encryption tunnel details—look for matching access lists (like LAN-LIST), transforms (esp-aes esp-sha-hmac), and SPI values.

Consistency in key lifetimes, signatures (IOS-PKI or trustpoint name), and anti-replay settings (window size, rekey timers) is critical for avoiding tunnel dropouts between key servers.

8. Verifying Group Members

Use show crypto ipsec sa on the group member router to verify that it’s receiving the correct group policy and is actively attempting encryption. The current_peer should point to 0.0.0.0, reflecting GETVPN’s peerless nature, and packet counters should increment if traffic flows.

Check the registration health with show crypto gdoi gm. A successful registration will display a Registered status, matching KS IP, re-registration timer, and any received rekey stats. If Rekey Received or ACKs Sent is zero, rekey synchronization might be misconfigured or not yet triggered.

The command show crypto gdoi gm rekey summarizes the rekey success post-registration. Zero counts indicate the device hasn’t yet received or responded to any rekey packets, which is expected immediately after registration or in idle states.

9. Group-Level Visibility

Use show crypto gdoi group GETVPN to validate that the group member received the expected KEK and TEK policies from the KS. You should see Rekeys received counts grow over time, and the ACL used (gdoi_group_GETVPN_temp_acl) should match the KS ACL.

This command also reveals the KEK policy as applied to the GM, including transport type, key lifetime (e.g., 84670 seconds), encryption algorithm (3DES), and key size.

10. ISAKMP Security Association Details

For low-level tunnel diagnostics, show crypto isakmp sa and show crypto isakmp sa detail are your best tools. These commands validate that IKE phase 1 is active and properly authenticated using pre-shared keys or PKI.

The detail view provides insights into encryption (des), hashing (sha), authentication type (psk), Diffie-Hellman group (e.g., group 2), and SA lifetime timers. A status of ACTIVE with an Engine-ID and Conn-ID is a strong sign the ISAKMP negotiation has completed and is holding.

GETVPN Troubleshooting: Interpreting Debug Logs and Fixing Common Issues

Even in well-designed GETVPN deployments, troubleshooting ISAKMP negotiation and policy mismatches is sometimes necessary. Let’s walk through key debugging patterns and their meanings.

Phase 1 Issues: Incompatible Modes or Policies

If ISAKMP cannot start Aggressive or Main Mode, you’ll see messages such as:

ISAKMP:(@):Can not start Aggressive mode, trying Main mode
ISAKMP:(@):incorrect policy settings. Unable to initiate.

This usually indicates a mismatch in phase 1 parameters like authentication method, encryption type, or hashing algorithm. Confirm that both the Key Server and Group Member have aligned IKE phase 1 policies.

Policy Mismatch: Encryption, Hash, or Group

GETVPN failures can often be traced to ISAKMP transform mismatches. For example:

ISAKMP: Checking ISAKMP transform 1 against priority 1 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash
ISAKMP: Encryption algorithm offered does not match policy!

The error above means the peer and KS disagree on the encryption method. Likewise, you might encounter:

ISAKMP: hash MD5
ISAKMP: Hash algorithm offered does not match policy!

In this case, the hashing algorithm doesn’t match. Ensure the hash (MD5 vs SHA) is consistent across all nodes.

Another common issue is a mismatched Diffie-Hellman group:

ISAKMP: default group 2
ISAKMP: Diffie-Hellman group offered does not match policy!

Make sure both ends use the same DH group (e.g., group 2 or group 5).

MM Message 6 Missing: Key Mismatch

If Main Mode (MM) fails to reach message 6, and debug shows:

Old State = IKE_I_MM4 New State = IKE_I_MM5

…but nothing beyond that, it typically indicates a key mismatch. This might be a wrong pre-shared key, or certificate issues if using PKI. Double-check credentials and key distribution.

Review of Useful Debug and Show Commands

To effectively diagnose GETVPN problems, keep these commands at your fingertips:

  • show crypto gdoi – View general GDOI group status
  • debug crypto isakmp – Essential for phase 1 negotiation issues
  • show crypto isa sa – View current ISAKMP Security Associations
  • show crypto gdoi ks members – List registered Group Members on the KS
  • show crypto gdoi ks pol – View the current KEK/TEK policy
  • show crypto gdoi ks acl – Review Proxy IDs and ACLs
  • show crypto gdoi ks coop – Inspect COOP/HA status for redundancy
  • show crypto gdoi ks – Get full KS configuration including COOP state
  • show crypto gdoi gm rekey – Check rekey receipt stats on Group Members
  • show crypto gdoi gm – View detailed group member registration info

With the combination of clear policy alignment, strategic use of debug crypto isakmp, and smart interpretation of rekey stats, troubleshooting GETVPN becomes far more efficient and predictable.