GET VPN with GDOI: Group Encrypted Transport

DMVPN and point-to-point IPsec both encrypt by tunnelling, which means the routing topology you designed no longer matches the topology packets actually traverse: tunnel endpoints hide the real next hop, and any-to-any multicast needs either extra mechanisms or full-mesh tunnels. GET VPN takes a different approach — it encrypts packet payloads in place, without a tunnel header, using IPsec SAs distributed by a group key controller. The result is that WAN routing stays native, multicast works, and adding a site requires no new tunnels. This guide covers the GDOI key exchange, the two-device configuration, and the operational checks that show the group is actually rekeying.

Why it is not just IPsec

GDOI (Group Domain of Interpretation, defined in RFC 3547 and extended in RFC 6407) is a group key management protocol: a key server — the Group Controller / Key Server, GCKS — authenticates group members and downloads the policy and keys they should use. Two key types matter. The TEK (traffic encryption key) becomes the IPsec SA that group members use to talk to each other. The KEK (key encryption key) protects the rekey messages the key server sends later, so the group can be rekeyed without new IKE sessions.

Configuring the key server

crypto isakmp policy 10
 authentication pre-share
 encryption aes 256
 hash sha256
 group 14
!
crypto isakmp key GROUP-KEY address 0.0.0.0
!
crypto gdoi group GETVPN-GROUP
 identity number 1234
 server local
  rekey authentication mypubkey rsa GETVPN-KEYS
  rekey transport unicast
  sa ipsec 10
   profile GETVPN-PROFILE
   match address ipv4 GETVPN-TRAFFIC
   replay time window-size 5
   !
  !
 !
!
crypto ipsec profile GETVPN-PROFILE
 set security-association lifetime seconds 3600
 set transform-set GETVPN-TS
!
ip access-list extended GETVPN-TRAFFIC
 permit ip 10.10.0.0 0.0.255.255 10.10.0.0 0.0.255.255

The ACL on the key server defines exactly which traffic is encrypted and is delivered to members — GET VPN does not rely on the member's own ACL for policy. Only deny entries may be configured locally on a member, and those take precedence over what the server downloads, which is the tool you use for a local exemption.

Configuring group members

crypto isakmp policy 10
 authentication pre-share
 encryption aes 256
 hash sha256
 group 14
!
crypto isakmp key GROUP-KEY address 0.0.0.0
!
crypto gdoi group GETVPN-GROUP
 identity number 1234
 server address ipv4 10.0.0.1
!
crypto map GETVPN-MAP 10 gdoi
 set group GETVPN-GROUP
!
interface GigabitEthernet0/0/1
 crypto map GETVPN-MAP

Members share one ISAKMP policy with the key server; that policy protects the GDOI exchange, so it must be strong and identical on both sides. Each member registers with the group ID and receives the TEK and policy.

Lifetimes and rekeying

Two timers govern steady-state behaviour. TEK lifetime determines how long the IPsec SA lasts; the key server rekeys before it expires, pushing a new TEK to all members so traffic never breaks. KEK lifetime governs the rekey SA and should be at least three times the TEK lifetime — with defaults of 86400 seconds for both, that ratio needs deliberate attention. Both values are configured on the key server only and pushed down.

crypto gdoi group GETVPN-GROUP
 server local
  rekey lifetime seconds 86400
  rekey retransmit 10 number 2
  rekey authentication mypubkey rsa GETVPN-KEYS
 !
!
crypto ipsec profile GETVPN-PROFILE
 set security-association lifetime seconds 28800

Verification

show crypto gdoi
show crypto gdoi ks group
show crypto gdoi ks members
show crypto gdoi gm group
show crypto ipsec sa | include "peer|status"
show crypto isakmp sa

On the key server, show crypto gdoi ks members lists registered members with their rekey state — a member stuck in an intermediate state is usually failing authentication or unable to reach the server's rekey address. On a member, show crypto gdoi gm group shows the received policy, the current TEK and the rekey counters. After a rekey, the TEK identifier should change while the underlying IKE session stays up; if sessions are being torn down instead, the KEK lifetime ratio or the rekey transport mode is wrong. Counter-check with the IPsec SA table: encryption counters for the group traffic should climb on both ends while a native traceroute still shows the real WAN path, which is the visible proof that GET VPN is not tunnelling.

Design: where the key server lives and how many you need

The key server is the component that cannot be allowed to fail silently: without it, new members cannot register and the group stops being rekeyed. Two designs are common. A single primary key server with registered members is simple but exposes you to a rekey outage if it dies. A cooperative key server setup — two key servers sharing state — lets either one rekey the group, which is what most production deployments should use once the group is more than a few dozen sites.

Two timers interact with the design. Member ISAKMP SAs are needed only for registration when there is no cooperative key server, so they can be short. With cooperative key servers, the ISAKMP SA must live long enough to keep the servers talking to each other — a short lifetime there breaks the cooperation, not just the member registration.

Time-based anti-replay: the setting people forget

Because GET VPN does not tunnel, packets can arrive over many different paths with widely varying latency. Classic window-based anti-replay either drops legitimate traffic at high jitter or requires impractically deep windows. The answer is time-based anti-replay, configured on the key server and pushed to members, which allows reordering inside a time bound rather than a packet-count bound.

crypto gdoi group GETVPN-GROUP
 server local
  sa ipsec 10
   profile GETVPN-PROFILE
   replay time window-size 5
  !
 !
!
show crypto gdoi ks policy
show crypto ipsec sa | include "replay|window"

Set the window size to cover your worst realistic reordering: on a WAN with multipath, a few seconds is normal, while on a single-path transport a smaller window is defensible. The symptom of getting it wrong is asymmetric: one site reports sporadic packet loss that no interface counter explains, and the IPsec counters on the receiving member show decapsulation failures.

Multicast and the traffic ACL

GET VPN's original use case was protecting native multicast on a service provider WAN, and the ACL model reflects that: the key server defines, statically, which traffic is encrypted. Permit entries encrypt; deny entries leave traffic in the clear. There is no implicit deny in the sense of blocking traffic — non-matching traffic simply is not protected.

ip access-list extended GETVPN-TRAFFIC
 ! unicast site-to-site
 permit ip 10.10.0.0 0.0.255.255 10.20.0.0 0.0.255.255
 ! multicast applications between sites
 permit ip 10.10.0.0 0.0.255.255 239.10.0.0 0.0.255.255
 ! leave routing and management traffic in the clear
 deny   ip any host 224.0.0.5
 deny   ip any host 224.0.0.10
!
show crypto gdoi gm acl
show crypto gdoi ks acl

Keep the control-plane traffic (OSPF 224.0.0.5, IS-IS 224.0.0.10, multicast NTP and so on) out of the encrypted set unless you have a specific reason to protect it — encrypting routing protocol hellos makes troubleshooting and mobile-site convergence markedly harder, and the benefit is negligible on a private WAN.

FAQ

Does GET VPN work over the internet? It can, but GET VPN assumes a relatively trusted transport with native routing between members; the value proposition is a private WAN. Over the public internet, prefer a design with tunnel-based encryption and per-peer authentication, or deploy GET VPN on top of an already encrypted underlay.

How do I add a new site? Configure the member with the group ID and the key server address, apply the crypto map and GDOI map to the WAN interface, and confirm registration on the key server. No other member needs to change, which is the operational point of the design.

What if a member is compromised? Remove it from the group and trigger a rekey; the key server generates a fresh TEK that the removed member cannot decrypt. Also revoke its authentication credential, otherwise it can simply re-register.

Why do my IPsec counters climb on one side only? Asymmetry usually means the traffic ACL differs between members, or one member's local deny entry is exempting traffic the other encrypts. Compare show crypto gdoi gm acl output across the two sites.

Quick reference: what lives where

The manual entries are where interop problems hide. The ISAKMP policy protects the GDOI exchange itself, so a mismatch there produces a registration failure that looks like an authentication problem; and the group ID is a number, not a name, which makes a typo invisible in the configuration file and obvious only in the logs.

Verifying that encryption is really happening

Because GET VPN does not tunnel, a successful ping proves nothing about protection. Confirm with the IPsec counters on both members increasing for the group traffic, and with show crypto gdoi gm group showing a current TEK. A group member that is registered but has no TEK is passing traffic in the clear, which is the most dangerous state this technology has.

Related Reading

Related reading: IPsec IKEv2 Troubleshooting: SA_INIT and IKE_AUTH Debugs, Post-Quantum Cryptography in IPsec and IKEv2, Cisco ASA Site-to-Site IPsec VPN CLI Configuration

原文链接：https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn/m_sec-get-vpn.html