Back
Lesson 4 of 7

GETVPN for Group Encryption

Objective

In this lesson you will learn the theory behind GETVPN (Group Encrypted Transport VPN) — a WAN encryption approach that provides group keying and data-plane encryption without creating pairwise tunnels — and compare it to an IPsec VTI-based design using the exact CLI primitives shown in the reference material. You will not configure a true GDOI/GETVPN Key Server (GKM) here (those commands are not available in our reference), but you will configure an IKEv2/IPsec VTI hub-and-spoke topology (exact commands from the reference) so you can see the practical differences between tunnel-based encryption and the group-based model GETVPN provides. In production, GETVPN matters when many sites need to communicate through a service provider backbone without forming N×N tunnels and while maintaining a single group policy and rekeying model.

Quick Recap

This lesson re-uses the same Hub/Spoke topology shown in Lesson 1. No new physical devices are added. We will use the following IP addresses exactly as in the reference material.

ASCII topology (exact IPs shown on every interface):

Hub (Firewall-HUB) ----- Internet ----- SpokeA (Firewall-SPOKE1) Hub Outside IP: 10.0.0.254 Spoke Outside IP: 10.0.0.253

Virtual Tunnel Interfaces (VTI) used for IPsec:

  • SpokeA Tunnel1 IP: 172.16.1.5/31 (peer 10.0.0.253)
  • SpokeA Tunnel2 IP: 172.16.1.7/31 (peer 10.0.0.254)
  • Hub will learn VTI routes from spokes (V routes via IKEv2)

Device table

DeviceRoleOutside IP
Firewall-HUBHub firewall (hub for VTIs/BGP)10.0.0.254
Firewall-SPOKE1Spoke firewall10.0.0.253

IP addressing used on VTIs (spoke shown below):

InterfaceIP Address
Tunnel1 (Spoke)172.16.1.5 255.255.255.254
Tunnel2 (Spoke)172.16.1.7 255.255.255.254
Hub borrowed loopback / VTI source (examples)172.16.1.253 /32 and 172.16.1.254 /32

Environment notes:

  • Domain names and credentials in examples use lab.nhprep.com and Lab@123 where illustrative values are needed.
  • Organization: NHPREP

Key Concepts

Before any CLI, understand these theoretical points. These are critical to grasp the WHY behind GETVPN and how a VTI-based IPsec topology differs.

  • GETVPN (GDOI) model: GETVPN centralizes distribution of group keys and policies from a Key Management Server (KMS/GCKS). Encryption is applied directly to routed traffic across the WAN — there are no per-peer tunnels. Think of GETVPN like a broadcast encryption fabric where all group members share a common set of policy and keys distributed securely by the KMS.

  • VTI (Virtual Tunnel Interface) model: VTIs create point-to-point logical interfaces (tunnels). Each VTI behaves like a network interface with its own IP and can participate in routing protocols (BGP, OSPF). For N spokes, you have either ephemeral VTIs or static VTIs per spoke; routing for spoke prefixes is shared across the VTIs.

  • Packet flow & policy differences: With GETVPN, packets are routed normally and encrypted based on group policy; intermediate routers (service provider) see only encrypted payloads but regular IP headers. With VTI/IPsec, traffic is encapsulated in IPsec tunnels — routing and encapsulation are tightly coupled with the IPsec endpoints.

  • Key distribution and scaling: GETVPN's KMS handles group rekeying (efficient for many sites). With IKEv2 + VTIs, each peer/session uses pairwise IKE exchanges (unless solution supports route learning via IKEv2), which scales differently and increases per-peer state on the hub.

  • Routing interplay: In the provided reference, IKEv2 can learn VTI routes and BGP is used to advertise spokes' routes. In production, GETVPN reduces tunnel state but you still need routing (usually BGP/OSPF) across the WAN so spokes can reach each other’s prefixes.

Tip: Think of GETVPN as “one shared vault key” distributed by a central key manager; VTIs are “many locked boxes” where each box is a tunnel between two endpoints.

Step-by-step configuration

We will perform a VTI-based hub-and-spoke configuration using the reference commands so you can observe the operational differences versus GETVPN. Each step shows the exact commands, why they matter, and a verification output.

Step 1: Configure IKEv2 policy and enable on outside

What we are doing: Configure IKEv2 policy parameters that establish the secure control channel (IKE SA). This defines the cryptographic algorithms IKEv2 will use; in production you should choose strong algorithms. These settings are similar to what a KMS/GKM would trust for key management in GETVPN environments — strong IKE parameters are still critical.

configure terminal
crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
exit
crypto ikev2 enable outside
exit

What just happened: The IKEv2 policy created (priority 10) specifies AES-256 encryption, SHA-384 integrity and PRF, and Diffie-Hellman group 19. Enabling IKEv2 on the outside interface allows the firewall to accept IKEv2 negotiations on that interface. IKEv2 handles peer authentication and establishes the IKE SA that will negotiate IPsec SAs.

Real-world note: Use high-strength primitives to protect the IKE channel; a compromised IKE channel undermines all subsequent group or tunnel key material.

Verify:

show crypto ikev2 policy
Policy 10
  Encryption: aes-256
  Integrity: sha384
  PRF: sha384
  DH Group: 19

Step 2: Create IPsec proposal and profile used by VTIs

What we are doing: Define the IPsec ESP transform (encryption/integrity) and bind it into an IPsec profile which the VTI interfaces will reference. This profile is the data-plane policy for how payloads will be encrypted over the tunnels.

configure terminal
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1
exit
crypto ipsecprofile VTI
 set ikev2 ipsec-proposal IPSEC_PROP
exit

What just happened: The IPSEC_PROP proposal sets the ESP transform: AES for encryption and SHA-1 for integrity (as per the reference commands). The ipsecprofile named VTI tells the platform which IPsec proposal to use for tunnel protection. When the VTI interface references this profile, all packets encapsulated on that VTI will use this ESP transform.

Real-world note: GETVPN separates control from data — the data plane algorithms here should match the operational policy that a KMS would enforce if using group encryption.

Verify:

show running-config crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1

Step 3: Configure spoke tunnel interfaces and tunnel-groups

What we are doing: Configure two VTI interfaces and associate tunnel-groups for the remote peers with IKEv2 pre-shared keys. This sets up peer authentication and creates interface-based tunnels that will carry encrypted traffic.

configure terminal
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 exit
tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 exit
interface Tunnel1
 nameif VTI
 ip address 172.16.1.5 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
exit
interface Tunnel2
 nameif VTI2
 ip address 172.16.1.7 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.254
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
exit

What just happened: Two tunnel-groups were created for the remote peers and both use IKEv2 pre-shared key authentication with the shared key "cisco" (from the reference). The Tunnel1 and Tunnel2 interfaces are created and bound to the IPsec profile VTI. These are point-to-point logical interfaces that will bring up IPsec SAs to their remote endpoints. The tunnel IPs are the VTI addresses that can participate in routing.

Real-world note: GETVPN avoids creating these per-peer tunnels altogether; you use tunnel interfaces like this when you want interface-level control and routing over IPsec.

Verify:

show running-config tunnel-group 10.0.0.253
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco

show running-config interface Tunnel1
interface Tunnel1
 nameif VTI
 ip address 172.16.1.5 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

Step 4: Configure static VTI route entries (spoke-side)

What we are doing: Add routes that point to the VTI endpoints so the firewall knows how to reach the remote VTI IPs. With IKEv2 route learning this is optional, but the reference shows explicit routeVTI commands in older deployments.

configure terminal
routeVTI 172.16.1.253 255.255.255.255 172.16.1.253 1
routeVTI2 172.16.1.254 255.255.255.255 172.16.1.254 1
exit

What just happened: These routeVTI entries create static host routes pointing to the remote VTI IPs via the corresponding VTI next-hops. They ensure the local device has a next-hop to send traffic destined for the tunnel endpoints into the correct VTI. In the reference, these were used before IKEv2 route learning became available.

Real-world note: When using a borrowed loopback or dynamic client addressing, route learning via IKEv2 avoids manual routeVTI entries — reducing operational overhead for many spokes.

Verify:

show route
S* 0.0.0.0/0 [1/0] via <next-hop>
V 172.16.1.253/32 is directly connected, Tunnel1
V 172.16.1.254/32 is directly connected, Tunnel2

Step 5: Configure BGP to exchange spoke prefixes with hub

What we are doing: Enable BGP using AS 65000 and peer with the VTI addresses. BGP is used to advertise connected networks and to allow hub/spoke route exchange; this mimics the requirement in both GETVPN and VTI topologies — you still need a routing protocol so spokes can reach one another.

configure terminal
router bgp 65000
 timers bgp 5 15 0
 address-family ipv4 unicast
  neighbor 172.16.1.253 remote-as 65000
  neighbor 172.16.1.253 activate
  neighbor 172.16.1.254 remote-as 65000
  neighbor 172.16.1.254 activate
  redistribute connected
 exit
exit

What just happened: BGP was configured with AS 65000 and neighbors that match the VTI addresses. The configuration redistributes connected routes into BGP so that the hub and spokes share the VTI-related prefixes. In GETVPN deployments, you also need routing; GETVPN is complementary to routing protocols.

Real-world note: Use BGP to control path selection in dual-hub topologies and to advertise the supernet that represents spokes as described in the reference.

Verify:

show bgp ipv4 unicast neighbors
BGP neighbor is 172.16.1.253, remote AS 65000, internal link
  BGP version 4, remote router ID 172.16.1.253
  Neighbor capabilities: Route Refresh
...
BGP neighbor is 172.16.1.254, remote AS 65000, internal link
  BGP version 4, remote router ID 172.16.1.254
  Neighbor capabilities: Route Refresh

Verification Checklist

  • Check 1: IKEv2 policy present — verify with show crypto ikev2 policy and confirm encryption and DH group.
  • Check 2: IPsec profile applied to Tunnel interfaces — verify with show running-config interface Tunnel1 and confirm tunnel protection ipsec profile VTI.
  • Check 3: VTI route entries visible as V routes — verify with show route and confirm V 172.16.1.253/32 and V 172.16.1.254/32.
  • Check 4: BGP adjacency with VTI peers — verify with show bgp ipv4 unicast neighbors and confirm neighbors 172.16.1.253 and 172.16.1.254 are active.

Common Mistakes

SymptomCauseFix
IKEv2 SA never establishesMismatched IKEv2 policy or pre-shared-keyEnsure crypto ikev2 policy parameters match on both peers and PSK (cisco) is identical in tunnel-group ipsec-attributes
No V routes visible on HubVTI tunnel not up or routeVTI not configured before IKEv2 route learningConfirm Tunnel interfaces are up and tunnel protection ipsec profile VTI is applied; add routeVTI entries if IKEv2 route learning is not available
BGP neighbors not formingBGP neighbor IP mismatch or routing missingVerify VTI IPs, ensure show route contains route to neighbor, and that neighbor <ip> remote-as 65000 matches peer
Multiple spokes cannot reach each otherHub not redistributing connected VTI routes or missing supernet advertisementOn Hub, redistribute connected and advertise a supernet (as described in the reference) so spoke VTI routes propagate

Key Takeaways

  • GETVPN provides group-based encryption without per-peer tunnels by distributing keys and policy from a Key Management Server; this dramatically reduces per-site state for large WAN fabrics.
  • The VTI/IKEv2 approach creates interface-based tunnels which simplify routing and integration with routing protocols (like BGP) — but scales differently than GETVPN because each peer typically requires tunnel state.
  • In production, you must still run routing (BGP/OSPF) in either model so spokes can reach each other’s prefixes; the reference configuration uses BGP and redistributes connected routes to advertise VTI routes.
  • Operationally, GETVPN is best when you need many-to-many encrypted connectivity over an untrusted WAN without building explicit tunnels; VTI is better when you need precise per-peer control, interface semantics, and integration with routing per tunnel.

Important: This lesson used the exact IKEv2/IPsec VTI commands from the reference to demonstrate the practical configuration and to contrast the behavior with GETVPN. True GETVPN (GDOI) configuration requires commands and a GKM not present in the reference; the configuration here helps you understand the functional differences and operational trade-offs you must consider in real-world deployments.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security