Group Encrypted Transport VPN (GETVPN) is a Cisco-developed VPN solution designed for private WAN environments like MPLS, where encryption is required but tunnels are not. Unlike traditional VPN models such as site-to-site or DMVPN, GETVPN operates without the overhead of point-to-point tunnels, allowing for scalable, meshed network architectures. This is especially valuable in networks where real-time applications like voice and video demand both security and performance.

 

Key Characteristics and Architecture

GETVPN introduces a tunnel-less VPN model that encrypts traffic without encapsulating it in additional headers. This approach eliminates the need for GRE or IPsec tunnels while still ensuring the confidentiality and integrity of the data. The core concept behind GETVPN is a centralized key management system with distributed data encryption. It relies on a group-based model, in which trusted routers (called Group Members, or GMs) receive encryption policies and keys from a Key Server (KS).

Each GM registers with the KS using ISAKMP Phase 1, followed by a GDOI (Group Domain of Interpretation) exchange, during which the KS authenticates and authorizes the GM, providing it with the group’s security policy and keys. This entire process runs over UDP port 848.

 

Key Roles and Terminology

  • Group Members (GMs): These are routers responsible for encrypting and decrypting the actual traffic. They download policies and encryption keys from the Key Server and use these to protect data flows in the network.
  • Key Server (KS): A router that manages and distributes encryption keys and policies. It performs key rotation (or “rekeying”) to maintain security as keys expire. The KS distributes two key types:
    • Traffic Encryption Key (TEK): Used for data encryption in IPSec.
    • Key Encryption Key (KEK): Used to encrypt rekey messages and new TEKs.
  • Cooperative Key Servers (COOP KS): Provide redundancy and load balancing. All KS devices must maintain identical configurations and state. Only one acts as primary, but all participate in key distribution and GM registration processing.

 

Configuration Considerations

When preparing to configure GETVPN, it’s critical to address the ISAKMP Phase 1 policy first. If pre-shared keys are used, those must be properly configured on all key servers. RSA key pairs are also necessary for authentication during the registration process and must be exportable to support redundancy via COOP KS.

GETVPN is configured by defining:

  • Group ID
  • Group ACL
  • IPSec protection profile
  • Rekey policy
  • Optional COOP KS settings

 

IPv6 Support

GETVPN supports IPv6, but only in the Data Plane. The Control Plane must still be IPv4. Mixed mode IPv4/IPv6 configurations are not supported. To verify IPv6 readiness, use the command:

show crypto gdoi feature ipv6-crypto-path

 

Both the group and crypto map must be explicitly configured for IPv6:

crypto gdoi group ipv6 group-name
crypto map ipv6 map-name sequence-number gdoi

 

Network and Design Requirements

A key prerequisite for GETVPN is that all network traffic must be fully routable before encryption is applied. Because the VPN does not encapsulate traffic, there’s no tunneling mechanism to bypass routing challenges. The network must support end-to-end IP routing for the inner IP headers.

Another key requirement is that all Phase 2 IPSec characteristics are configured centrally on the Key Server:

  • Session keys
  • Encryption algorithm (Transform-set)
  • Hash algorithm (Transform-set)
  • Access control lists (ACLs)

These parameters are downloaded by the Group Members during registration and are used to secure data traffic.

 

Advantages of GETVPN

  • Tunnel-less operation: Reduces complexity and overhead compared to GRE/IPSec tunnels.
  • Centralized control: Security policies and encryption parameters are managed in one place (the Key Server), simplifying configuration and updates.
  • Scalability: Suited for large-scale meshed networks, particularly over MPLS WANs.
  • Efficient encryption: GETVPN copies the inner header to the outer header for efficient forwarding, avoiding the need for header encapsulation or mapping.
  • High availability: COOP KS setup provides redundancy and load balancing for secure and reliable key distribution.

 

Limitations and Use Cases

GETVPN is not suitable for public internet scenarios. It is intended strictly for private WAN use cases, such as MPLS environments. Unlike DMVPN or site-to-site VPNs, GETVPN does not provide connectivity between disparate internet-connected sites. It also requires all routers participating in the encryption process to be fully routable and under administrative control.

Because of its design and encryption model, GETVPN is the only Cisco VPN solution that offers any-to-any encryption without tunnels. It is particularly well-suited for environments where performance, security, and centralized policy enforcement are all critical, such as financial institutions, voice-over-MPLS deployments, and global enterprises with large private WAN backbones.

 

Deep Dive into GETVPN Operations, Limitations, and Design Considerations

At the heart of GETVPN is the relationship between Group Members (GMs)—the routers responsible for encrypting traffic, and the Key Server (KS), which manages and distributes encryption policies and keys. A unique feature of GETVPN is its split between Phase 1 and Phase 2 operations. Phase 1, based on ISAKMP, is used for establishing an initial secure channel between the GMs and the Key Server. However, unlike traditional IPSec, where Phase 1 is only used to establish a session key, GETVPN utilizes the GDOI protocol to distribute additional policy information, such as encryption ACLs and transform sets. This exchange happens over UDP port 848, and allows GETVPN to scale and simplify policy distribution in large environments.

One important architectural constraint is that the Key Server cannot act as a Group Member. It must run independently, typically on a dedicated router, to ensure performance and avoid overloading the device handling encryption.

GETVPN is strictly designed to encrypt traffic over private WANs, such as MPLS, and is not compatible with public internet environments. Since GETVPN does not create tunnels, it has a critical routing prerequisite: all internal network traffic must be fully routable across the WAN before encryption. This limitation makes it virtually impossible to use GETVPN in networks where private IP addresses need to traverse the internet unless those addresses are somehow routable, which is highly unlikely. As a result, GETVPN is best suited for any-to-any communication over MPLS backbones or private infrastructure.

From an operational standpoint, GETVPN supports IP header preservation, meaning it encrypts packets while retaining the original IP headers. This is achieved by using ESP (Encapsulating Security Payload) alone—no GRE, no tunnels, no overlays. The original IP header is copied in front of the ESP header, allowing routers to forward traffic efficiently without breaking path visibility.

GETVPN does support NAT under very strict conditions. The NAT process must occur before encryption, which means the router performing NAT must also be a Group Member and must do NAT on the outbound interface prior to encryption. If NAT is performed somewhere in the middle of the path (e.g., on a firewall), the traffic will fail, as ESP-encrypted packets cannot tolerate header changes mid-transit.

 

Comparing GETVPN with DMVPN

While GETVPN is optimal for any-to-any encryption within a private WAN, DMVPN offers more flexibility for hybrid and internet-based networks. DMVPN supports on-demand tunnels, which makes it more resilient for remote site-to-site setups or connections involving dynamic endpoints. However, DMVPN requires GRE/IPSec and can introduce latency and jitter, especially with Phase 3 (on-demand spoke-to-spoke tunnels).

In contrast, GETVPN is about encrypting traffic between fixed routers across the WAN, not about dynamic overlays or extending connectivity across the public internet. It’s more akin to an MPLS IP VPN service with encryption, where consistency, low latency, and centralized control matter more than endpoint flexibility.

 

Policy and Key Server Best Practices

Encryption policies in GETVPN are defined using standard IP ACLs, and it’s common to see rules like encrypting traffic from 10.0.0.0/8 to 10.0.0.0/8, which effectively means “encrypt all internal traffic.” These policies are pushed from the Key Server to the GMs using the GDOI protocol. The Key Server is essentially the central authority that distributes:

  • What to encrypt (crypto ACL)
  • How to encrypt (algorithms like 3DES, AES)
  • Which keys to use
  • Rekeying instructions (TEKs and KEKs)

The Key Server should not perform encryption itself. Best practice is to place the KS on a separate router, isolating policy distribution from data-plane encryption to prevent overload and ensure reliable key management.

GETVPN fills a specific and powerful role in the VPN landscape. It is uniquely suited for tunnel-less encryption in fully routed private WAN environments, where performance and scalability are top priorities. By preserving original IP headers and centralizing control through a Key Server, GETVPN minimizes complexity while maximizing flexibility for real-time and enterprise traffic. Although it’s not a suitable fit for every environment, especially public or NAT-heavy deployments, when used correctly, it delivers robust encryption without compromising routing intelligence.

 

GETVPN Key Concepts and Operational Flow

To ensure a comprehensive understanding of how GETVPN operates at scale, it’s essential to examine key components, including GDOI, the role of the Key Server, rekey mechanisms, and high availability with cooperative key servers.

 

Group Domain of Interpretation (GDOI)

GDOI is the application-layer protocol used by GETVPN for key management. It distributes cryptographic keys and policy information to a group of routers. GDOI traffic uses UDP port 848, and allows for centralized policy enforcement across distributed devices.

 

Key Encryption and Traffic Encryption

The Key Server (KS) plays a vital role in GETVPN’s control plane. It issues two types of keys:

  • Key Encryption Key (KEK): Used to encrypt control messages, especially rekey events, between the Key Server and Group Members (GMs).
  • Traffic Encryption Key (TEK): Used by GMs to encrypt actual enterprise data. TEKs are distributed securely using KEK and are updated based on configurable lifetimes.

The KS is responsible for maintaining IKE Phase 1 and Phase 2 configurations, including encryption algorithms, hash methods, and key lifetimes. GMs only need to support IKE Phase 1 and receive all other configurations from the KS.

 

Rekeying: Keeping Keys Fresh

GETVPN offers two rekeying mechanisms:

  1. Unicast Rekey: The KS sends an individualized rekey message to each GM, and each GM must acknowledge receipt of the message. This ensures the GM is both alive and synchronized with the key policy. If acknowledgments are not received after several retries, the KS may remove the GM from its list.
  2. Multicast Rekey: The KS sends one multicast rekey message to all GMs in the group. In this mode, acknowledgments are not required, which makes it more scalable but slightly less controlled.

 

Group Members (GMs)

A Group Member is a router responsible for encrypting and decrypting traffic. Upon startup, the GM registers with the Key Server using IKE Phase 1. After successful registration, it receives policy and key materials via GDOI and begins protecting enterprise traffic accordingly. All Phase 2 parameters are centrally defined and pushed from the KS, simplifying the GM’s role.

 

Tunnel Header Preservation

One of GETVPN’s unique advantages is Tunnel Header Preservation. Unlike GRE/IPSec-based VPNs (like DMVPN), GETVPN does not encapsulate packets or change IP headers. Instead, it retains the original IP header during encryption. This feature allows seamless forwarding across private WANs (e.g., MPLS), preserving QoS markings and simplifying routing.

 

Time-Based Anti-Replay (TBAR)

To protect against replay attacks, GETVPN leverages Time-Based Anti-Replay (TBAR). When keys are distributed, a countdown timer is triggered on each GM. Any received packet’s timestamp is checked against this timer to determine validity. TBAR removes the need for time synchronization between devices, as time values are centrally managed by the KS and distributed during rekey events.

 

Cooperative Key Servers (COOP KS)

For high availability, GETVPN supports Cooperative Key Servers (COOP KS). You can configure up to eight Key Servers for redundancy. Each GM attempts to register with the first reachable KS in its list. If that server is down, the GM proceeds to the next. If a secondary KS is active and the primary recovers, the primary will reclaim its role automatically (unless configured for priority-based failover behavior).

In COOP deployments, all KS devices share the same state and policy data. Only one actively issues rekey messages at any given time, while the others remain on standby or operate as backups. This ensures uninterrupted key distribution even in the event of KS failure.

 

GETVPN Operational Summary

In practical terms, here’s how a GETVPN deployment functions:

  • The Key Server is configured with IKE Phase 1, Phase 2, encryption policies, hash algorithms, KEK, and TEK lifetimes.
  • The Group Member is only configured with IKE Phase 1. Upon booting, it registers with the KS and receives its policy and key materials.
  • Once this exchange is complete, the GM begins encrypting and decrypting traffic based on centrally defined rules.

In most real-world deployments, 1–2 Key Servers are deployed out-of-band from the data path. However, in CCIE lab environments or simulations, inline KS configurations may be used for simplicity.

 

GETVPN Phases, Rekey Process, and High Availability

GETVPN operates in two main phases: Registration and Rekeying, both of which are essential for maintaining encrypted, policy-driven communication across private networks.

 

Phase 1: Registration

When a Group Member (GM) boots up, it begins the registration phase by contacting the Key Server (KS) to obtain its security policy. This is done using ISAKMP (IKE Phase 1), and GDOI takes over using UDP port 848 to exchange more than just session keys—it also includes policies like:

  • Crypto ACLs (e.g., permit IP any any)
  • Encryption Algorithms (e.g., 3DES)
  • Randomly generated Traffic Encryption Keys (TEKs) for protecting data
  • Key Server Public Key used to authenticate rekey messages
  • Key Encryption Key (KEK) for encrypting rekey messages
  • Pseudotime Synchronization, which doesn’t rely on NTP, but rather tracks relative time between KS and GM

GETVPN uses Main Mode for IKE Phase 1 to secure the initial setup. Phase 2, handled by GDOI, is used to finalize the registration of the GM into a specific group and deliver Phase 2 encryption policy and keys.

 

Phase 2: Rekey Process

By default, GETVPN rekeys every 3600 seconds (1 hour), though this can be adjusted. The rekey process must be tightly synchronized—down to the millisecond—across all Group Members to avoid key mismatches that could disrupt encrypted communications.

The KS tracks the lifetime of each TEK and starts the rekey process when the key approaches expiration (usually at the 10% remaining mark). If a GM doesn’t respond to rekey messages or cannot be reached, the GM is considered out of sync and must re-register with the Key Server.

There are two rekey transport modes:

  • Unicast Rekey (manual acknowledgment):
    The KS sends individual packets to each GM and expects acknowledgments. This method provides more control but does not scale as well.
  • Multicast Rekey (default and scalable):
    A single multicast rekey packet is sent to all GMs simultaneously. No acknowledgment is required, which enables scalability, but this mode cannot fall back to unicast if multicast fails.

Both transport types use a re-register window of 5% of the TEK lifetime. This is the time buffer to allow any missed rekey messages to trigger re-registration before complete key expiration.

 

GETVPN High Availability (HA)

A typical GETVPN production deployment includes 2 to 8 Key Servers for high availability. While a GM can register with any KS, only one KS is designated as primary at any time—the others act as secondaries.

Key Servers communicate using the CooP protocol (Cooperative Protocol) to stay synchronized and share information such as rekey schedules and GM status. If the primary KS fails, a secondary is promoted to primary, and it begins handling rekey responsibilities automatically.

To ensure continuity, all KS devices must share the same RSA key pair, which must be manually exported from the primary and imported into all secondary KS nodes. The rekey message is authenticated using the KS’s private key, so key consistency is critical for GMs to trust incoming messages regardless of which KS sends them.

With its tightly integrated registration and rekeying mechanisms, support for multicast scalability, and robust HA through Cooperative KS configurations, GETVPN offers a highly efficient, tunnel-less VPN solution for private WANs. It remains one of Cisco’s most optimized technologies for any-to-any encryption in MPLS environments, delivering policy-driven security without sacrificing routing intelligence or performance.