Every VPN technology you have configured up to now has a peer. A crypto map has a peer statement. A GRE over IPsec tunnel has a tunnel destination. DMVPN has an NHRP next-hop server. Even FlexVPN, which abstracts the whole thing behind IKEv2, still ends up with a peer address in the session table. That peering model is the reason full-mesh IPsec does not scale: N sites means N(N-1)/2 tunnels, and every one of them needs a peer, a crypto ACL, and a pair of SAs.
GETVPN (Group Encrypted Transport VPN) throws that model out. There is no tunnel. There is no peer. There is no per-peer crypto ACL. Every site pulls the same key from a central key server and encrypts to everyone at once. It is the one VPN in the IPsec VPN family where the phrase "tunnel mesh" does not apply, because there is no mesh to build.
That sounds like magic until you look at a packet capture. Then it becomes obvious, and it also becomes obvious why GETVPN cannot cross the public internet. This article walks the model (key server, group member, GDOI, KEK, TEK) and then proves every claim with real output from a Cisco IOS XE lab: two key servers, two group members, a private WAN core, and a packet capture that tells you exactly what GETVPN is doing to your headers.
Lead With the Weirdest Output in Networking
Before any theory, look at what show crypto session reports on a GETVPN group member. This is a router that is actively encrypting traffic to another site right now:
GM1#show crypto session detail
Interface: GigabitEthernet2
Session status: UP-ACTIVE
Peer: 0.0.0.0 port 848 fvrf: (none) ivrf: (none)
IPSEC FLOW: permit ip 10.20.10.0/255.255.255.0 10.30.10.0/255.255.255.0
Outbound: #pkts enc'ed 18 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2115Peer: 0.0.0.0. The session is UP-ACTIVE, packets are being encrypted (18 of them), and the peer is all zeroes. That is not a bug and it is not an uninitialised field. A group member does not have a peer. It has a group. The crypto session is a relationship with a policy, not with another router.
And port 848 is not ISAKMP (500) or NAT-T (4500). Port 848 is GDOI, the Group Domain of Interpretation (RFC 6407), the protocol a group member uses to talk to the key server. That single line tells you the entire architecture: the control plane points at a key server on UDP 848, and the data plane points at nobody in particular.
The GETVPN Model in Four Nouns
GETVPN has a small vocabulary, and once you have it the rest of the technology falls out of it.
GDOI is the glue. It is the registration and rekey protocol (UDP 848) that a GM uses to say "I am a member of group 4321, give me the policy" and that a KS uses to answer with the ACL, the KEK, and the TEK. Registration itself is protected by an IKE phase 1 SA, so the group secret is never handed out in the clear.
The mental shift is this: in a normal IPsec deployment, keys are negotiated pairwise between two routers. In GETVPN, keys are distributed from one source to many routers. Nobody negotiates with anybody. Everyone gets told.
Proof: One Group, One SA, One SPI
If every member really shares the same key, then every member must show the same SPI (Security Parameter Index), the value that identifies an IPsec SA. In a pairwise VPN, every tunnel has its own SPI pair, and two different routers will never show the same one.
Here is GM1, a group member at the 10.20.10.0/24 site:
GM1#show crypto gdoi
Group Name : PLZ-GETVPN
Group Identity : 4321
Group Type : GDOI (ISAKMP)
Rekeys received : 0
Group Server list : 10.100.0.11
10.100.0.12
Group member : 10.100.0.21 vrf: None
Registration status : Registered
Registered with : 10.100.0.11
Re-registers in : 692 sec
Succeeded registration: 1
TEK POLICY for the current KS-Policy ACEs Downloaded:
GigabitEthernet2:
IPsec SA:
spi: 0xE1F309BF(3790801343)
transform: esp-256-aes esp-sha256-hmac
sa timing:remaining key lifetime (sec): (3550)
Anti-Replay(Counter Based) : 64
encaps: ENCAPS_TUNNELAnd here is GM2, a completely different router at the 10.30.10.0/24 site:
GM2#show crypto gdoi | include Group member|Registration status|spi:|transform:
Group member : 10.100.0.22 vrf: None
Registration status : Registered
spi: 0xE1F309BF(3790801343)
transform: esp-256-aes esp-sha256-hmacThe same SPI. 0xE1F309BF on both routers. That is not a coincidence and it is not a display quirk. It is one SA, shared by the whole group. Add a hundred more sites and every one of them will show 0xE1F309BF until the next rekey, at which point all of them will roll to the same new SPI together.
This is the difference between N-squared and N. A twenty-site full mesh with crypto maps is 190 tunnels and 380 SAs to build, monitor, and troubleshoot. A twenty-site GETVPN group is one SA that twenty routers happen to hold a copy of.
KEK Versus TEK, From the Real Output
The same show crypto gdoi on GM1 prints both key policies. They do different jobs and it is worth being precise about which is which.
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs) : 849
Encrypt Algorithm : AES
Key Size : 256
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 2352If an attacker got the TEK, they could read group traffic. If they got the KEK, they could read the rekeys and therefore get every future TEK. That hierarchy is exactly why the KEK gets its own lifetime and its own signature, and why the RSA key that signs rekeys matters so much (a point that becomes a genuine trap once you add a second key server, which is its own article).
The Hero Capture: Header Preservation
Now the part that makes GETVPN click. We ran a packet capture on the link between GM1 and the WAN core while GM1 pinged GM2's LAN, source 10.20.10.1 (GM1's Loopback10) to 10.30.10.1 (GM2's Loopback10). Those are LAN addresses. The routers' WAN addresses are 10.100.0.21 and 10.100.0.22.
Here is what was on the wire:
No. Time Source Destination Proto Info
1 0.000000 10.20.10.1 10.30.10.1 ESP ESP (SPI=0xe1f309bf)
2 0.010547 10.30.10.1 10.20.10.1 ESP ESP (SPI=0xe1f309bf)
3 0.016432 10.20.10.1 10.30.10.1 ESP ESP (SPI=0xe1f309bf)
4 0.016939 10.30.10.1 10.20.10.1 ESP ESP (SPI=0xe1f309bf)
5 0.020745 10.20.10.1 10.30.10.1 ESP ESP (SPI=0xe1f309bf)
6 0.021049 10.30.10.1 10.20.10.1 ESP ESP (SPI=0xe1f309bf)Read the Source and Destination columns again. Those are the original LAN addresses, sitting in the outer IP header of an ESP packet, on the WAN. Not the routers. The payload is genuinely encrypted (it is ESP, with our group SPI), but the addresses are in clear text and they are the endpoints' addresses, not the encryptors' addresses.
Compare that with a conventional crypto-map site-to-site VPN, where the outer header is always the two routers:
The official name for this is tunnel mode with header preservation. GETVPN still uses ESP in tunnel mode (the GM output says encaps: ENCAPS_TUNNEL), but instead of writing its own outer header it copies the original one. You get the ESP encapsulation without the address rewrite.
The Consequence Nobody Says Out Loud
This is the section that matters most, and it is the one that most GETVPN explainers skip. Header preservation is not a neat trick. It is a design constraint with two large, unavoidable consequences, and both of them fall directly out of that capture.
1. The transport network must be able to route your LAN addresses
If the outer destination on the wire is 10.30.10.1, then every router between GM1 and GM2 has to know how to forward a packet to 10.30.10.1. RFC 1918 space, on the WAN, in the clear.
On the public internet that is a dead end. No ISP will route 10.30.10.1 for you, and even if your sites had public addresses on their LANs, you would be handing the internet a full map of your internal topology in every packet header. GETVPN cannot be deployed across the public internet. Not "should not," not "is discouraged." It structurally cannot, because the transport is being asked to route addresses it does not have.
What GETVPN is designed for is a private WAN: an MPLS L3VPN from a carrier, a private leased-line or Metro Ethernet core, or any transport where your own prefixes are already reachable end to end. That is the classic deployment, and it is not an accident. GETVPN exists precisely because enterprises were handed an MPLS VPN by a carrier, told it was "private," and then asked by an auditor to prove the carrier could not read their traffic. GETVPN encrypts the payload while leaving the carrier's routing completely undisturbed.
2. The same property is why there is no tunnel mesh
Here is the flip side, and it is the payoff. Why does GETVPN need no tunnels? Because the underlay already knows how to get from any site to any other site. The MPLS VPN routes 10.20.10.0/24 to 10.30.10.0/24 natively. GETVPN does not have to build a path, it only has to encrypt what is already flowing along the path the WAN provides.
A tunnel exists to create reachability where reachability did not exist, and to carry addresses the transport cannot route. GETVPN has neither problem. So it does not need a tunnel, and because it does not need a tunnel, it does not need a mesh, and because it does not need a mesh, it scales linearly and gives you any-to-any encryption for free.
Those two consequences are the same fact seen from opposite ends. You trade internet capability for mesh-free any-to-any encryption. That is the whole bargain, and it is why the technology choice is really a transport choice.
Practical fallout worth knowing
- QoS still works. Because the original header survives (including DSCP), your carrier's QoS classification on the MPLS core keeps working on encrypted traffic. With a classic tunnel, the carrier sees only your tunnel endpoints and one DSCP value unless you copy it out explicitly.
- Multicast works natively. A multicast packet keeps its group destination address in the outer header, so the WAN replicates it exactly as it would in clear text. No tunnel replication, no GRE.
- NAT breaks it. Any device that rewrites addresses between two group members breaks header preservation and therefore breaks the anti-replay and the SA match.
- Your addresses are visible on the WAN. The payload is confidential, the topology is not. On a private WAN that is usually an acceptable trade. On the internet it is not.
GETVPN Versus DMVPN Versus Classic IPsec
These three get compared constantly and the comparison is usually mushy. Be honest about it: they solve different transport problems, and the right question is not "which is best" but "what is my WAN."
The honest summary: if your WAN is the internet, you want DMVPN (or FlexVPN, or SD-WAN). If your WAN is a private core or a carrier MPLS VPN and you need any-to-any encryption without building a mesh, you want GETVPN. If you have two sites and a deadline, a point-to-point VTI is fine and nobody will judge you. These are complements, and large enterprises routinely run GETVPN on the MPLS underlay and DMVPN on the internet underlay simultaneously.
What the Group Member Config Actually Looks Like
The theory is only convincing if the config matches it. Here is the entire GETVPN configuration on GM1, straight from the lab:
crypto isakmp key PingLabz-GETVPN-01 address 10.100.0.11
crypto isakmp key PingLabz-GETVPN-01 address 10.100.0.12
crypto gdoi group PLZ-GETVPN
identity number 4321
server address ipv4 10.100.0.11
server address ipv4 10.100.0.12
crypto map PLZ-GET-CMAP 10 gdoi
set group PLZ-GETVPN
interface GigabitEthernet2
crypto map PLZ-GET-CMAPCount what is missing. No peer address. No crypto ACL. No transform set. No mention of GM2, or of 10.30.10.0/24, or of any other site at all. The only IP addresses in the whole block are the two key servers. GM2's config is identical, and site number one hundred would get the same paste.
The policy (what to encrypt, and to where) is not on the group member. It is downloaded, and you can see it arrive:
ACL Downloaded From KS 10.100.0.11:
access-list permit ip 10.20.10.0 0.0.0.255 10.30.10.0 0.0.0.255
access-list permit ip 10.30.10.0 0.0.0.255 10.20.10.0 0.0.0.255
access-list permit ip 192.168.99.0 0.0.0.255 10.30.10.0 0.0.0.255
access-list permit ip 10.30.10.0 0.0.0.255 192.168.99.0 0.0.0.255That ACL is not configured on GM1. It came from the key server over GDOI. Change the group policy once, on the KS, and every member in the group picks it up at the next rekey. That is the operational win, and it is what people mean when they say GETVPN "centralises policy." The full build (key server first, then members, then verification) is walked line by line in the GETVPN configuration article.
Does It Actually Pass Traffic
Yes, and encrypted, in both directions, first try:
GM1#ping 10.30.10.1 source Loopback10 repeat 8
!!!!!!!!
Success rate is 100 percent (8/8), round-trip min/avg/max = 5/9/30 ms
GM2#ping 10.20.10.1 source Loopback10 repeat 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/11/34 msAnd on the key server side, the group is visible as exactly what it is: a membership list.
KS1#show crypto gdoi ks members
Group Member ID : 10.100.0.21 GM Version: 1.0.26
Group ID : 4321
Group Name : PLZ-GETVPN
GM State : Registered
Key Server ID : 10.100.0.11
Group Member ID : 10.100.0.22 GM Version: 1.0.26
Group ID : 4321
GM State : Registered
Key Server ID : 10.100.0.11Two members, one group, one key. No tunnels anywhere in the topology.
The Obvious Objection: Isn't the Key Server a Single Point of Failure?
Half yes, and the half that is "yes" is smaller than you think.
The key server is a control plane element. It is not in the data path, which the peer 0.0.0.0 output already hinted at. If the key server disappears, group members carry on encrypting with the TEK they already hold. Traffic keeps flowing. What they lose is the ability to re-register and to receive a rekey, so the group degrades on a timer rather than falling over instantly. We tested this by shutting the key server down, and the pings stayed at 100 percent.
The real answer is COOP (cooperative key servers): run two or more, with priorities, and let them elect a primary. It works, and there is one trap involving the RSA rekey key that will silently kill your group at the next rekey interval if you get it wrong. We hit it on purpose. That is covered in GETVPN redundancy: COOP key servers and rekey survival.
Key Takeaways
- GETVPN has no peer and no tunnel.
show crypto sessionon a group member reportsPeer: 0.0.0.0 port 848. Port 848 is GDOI, the group key distribution protocol. The session is with a policy, not with a router. - One group, one key, one SPI. GM1 and GM2 both showed SPI
0xE1F309BF. Every member of the group shares the same TEK, so there is one SA no matter how many sites you add. - Header preservation is the defining property. The ESP outer header carried 10.20.10.1 to 10.30.10.1, the original LAN addresses, not the routers' WAN addresses. A classic crypto map would have shown the routers instead.
- That is why GETVPN needs a private WAN. The transport must be able to route your internal prefixes, because they are on the wire. GETVPN over the public internet is not a bad idea, it is structurally impossible. MPLS L3VPN is the classic deployment.
- And it is why there is no mesh. The underlay already provides any-to-any reachability, so GETVPN only has to encrypt, not to build paths. Mesh-free any-to-any encryption is what you buy with the transport constraint.
- KEK protects rekeys, TEK protects data. Both are pushed from the key server. The group member's own config contains no policy at all, only the address of the key servers.
- The group member config is the shortest in the IPsec family. Two ISAKMP keys, a GDOI group, a crypto map with
set group. Identical on every site. That is the scaling story in six lines. - Pick by transport. Private WAN or MPLS and you need any-to-any: GETVPN. Internet underlay: DMVPN. Two sites: a VTI. They are complements, not competitors.
Everything above was captured on Cisco IOS XE (cat8000v 17.18.02) in a lab with two key servers, two group members, and a shared private WAN core. For the rest of the family (IKEv1, IKEv2, crypto maps, VTIs, DMVPN, FlexVPN, certificate authentication, and VRF-aware designs), start at the IPsec VPN pillar, then build this one yourself with the GETVPN configuration walkthrough.
