GETVPN Configuration: Key Server, Group Members, and GDOI

GETVPN is the strangest member of the IPsec VPN family to configure, because most of what you expect to type is not there. There is no peer statement. There is no crypto ACL on the site routers. There is no tunnel interface. Almost the entire configuration lives on one box (the key server) and the sites get a six-line paste that is identical everywhere.

If you have not read GETVPN Explained yet, read that first for the model (key server, group member, GDOI, KEK, TEK) and for the packet capture that shows why GETVPN needs a private WAN. This article is the build. Key server first, then group members, then verification, every command run on Cisco IOS XE and every piece of output below copied from the console.

The lab: two key servers (KS1 10.100.0.11, KS2 10.100.0.12), two group members (GM1 10.100.0.21, GM2 10.100.0.22), all cat8000v running IOS XE 17.18.02 on a shared private WAN core, 10.100.0.0/24. GM1's protected LAN is 10.20.10.0/24, GM2's is 10.30.10.0/24. Everything in this article is verified on that platform. GDOI is fully supported on cat8000v 17.18.02 and every GETVPN command below was accepted, which is worth stating plainly because the internet is full of people asking whether it still exists on modern IOS XE. It does.

Step 1: The Key Server, Block by Block

The key server is where all the policy lives. Build it in this order, because later blocks reference earlier ones.

1a. ISAKMP policy and pre-shared keys

GDOI registration is protected by an IKEv1 phase 1 SA. That means a group member and a key server must first authenticate to each other before the key server will hand over anything. So you need an ISAKMP policy and a key per member.

crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key PingLabz-GETVPN-01 address 10.100.0.21
crypto isakmp key PingLabz-GETVPN-01 address 10.100.0.22

Note what those two key statements point at: the group members, 10.100.0.21 and 10.100.0.22. The key server needs a key for every member that will register to it. (In production you would use certificates rather than a shared PSK across every site, which is exactly the argument for a PKI, but a PSK keeps this lab focused on GDOI.)

This is the one place in GETVPN where you configure something per remote router, and even here it is per member, not per pair of members. There is no N-squared anywhere.

1b. Transform set and IPsec profile

These describe the data-plane encryption the group will use. They live on the key server because the key server is the thing that decides policy. Group members never see a transform set in their own config, they receive it.

crypto ipsec transform-set PLZ-GET-TS esp-aes 256 esp-sha256-hmac
 mode tunnel
crypto ipsec profile PLZ-GET-PROF
 set transform-set PLZ-GET-TS

mode tunnel is not a contradiction of "GETVPN has no tunnels." GETVPN uses ESP tunnel mode encapsulation and then copies the original IP header into the outer header instead of writing its own. That is header preservation, and you can see the result in the GM output later (encaps: ENCAPS_TUNNEL).

1c. The group policy ACL, and why it is not a crypto ACL

This is the block that trips people who come to GETVPN from crypto maps. It looks like a crypto ACL. It is not one.

ip access-list extended PLZ-GET-POLICY
 permit ip 10.20.10.0 0.0.0.255 10.30.10.0 0.0.0.255
 permit ip 10.30.10.0 0.0.0.255 10.20.10.0 0.0.0.255
 permit ip 192.168.99.0 0.0.0.255 10.30.10.0 0.0.0.255
 permit ip 10.30.10.0 0.0.0.255 192.168.99.0 0.0.0.255

Two things are different from a crypto map ACL, and both matter:

Look at the ACL again with that in mind. It lists both directions of every flow: 10.20.10.0 to 10.30.10.0, and 10.30.10.0 to 10.20.10.0. That is not redundancy. Every member receives this same ACL, so GM1 needs to match the outbound direction and GM2 needs to match its own outbound direction, and they are reading the identical policy. One symmetric ACL covers both.

Get this wrong and you get the classic GETVPN failure: traffic encrypts one way and arrives at the far end as an ESP packet the receiver has no policy for. Write it symmetric. Always.

1d. The RSA rekey key

The key server signs its rekey messages so that group members can verify they came from a legitimate key server and not from an attacker. That signature needs an RSA keypair.

crypto key generate rsa modulus 2048 label PLZ-REKEY-KEY exportable

The exportable keyword looks optional. It is not, if you have any intention of adding a second key server later. COOP key servers must share the same RSA rekey keypair, and you cannot export a key you did not mark exportable at generation time. Generate it exportable now or regenerate it later under pressure. (The full story, including the exact syslog you get when the keys do not match, is in GETVPN redundancy: COOP key servers and rekey survival.)

1e. The GDOI group with server local

Now assemble it. This is the block that makes the router a key server.

crypto gdoi group PLZ-GETVPN
 identity number 4321
 server local
  rekey algorithm aes 256
  rekey authentication mypubkey rsa PLZ-REKEY-KEY
  rekey transport unicast
  rekey lifetime seconds 900
  sa ipsec 1
   profile PLZ-GET-PROF
   match address ipv4 PLZ-GET-POLICY
   replay counter window-size 64
  address ipv4 10.100.0.11

Line by line:

One warning about ordering that costs people real time: if you later add redundancy for COOP, address ipv4 must already be configured. Configure the local address early and you will never see that error.

Step 2: The Group Member (Prepare To Be Underwhelmed)

Here is the entire GETVPN configuration on GM1:

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-CMAP

That is it. Read what is absent:

• No peer. There is no set peer anywhere. The crypto map is a gdoi map, not an ISAKMP map.
• No crypto ACL. There is no match address. The member has no idea what to encrypt until the key server tells it.
• No transform set. Downloaded.
• No mention of GM2. None. GM1 does not know GM2 exists.

The only remote addresses in the entire block are the two key servers. And GM2's configuration is identical to GM1's, character for character. Not "similar." Not "mirrored." Identical.

That is the sentence to hold onto, because it is the whole scaling argument. Adding site number 47 to a GETVPN group means pasting the same nine lines onto a new router, with no change to the 46 routers already running and no change to the key server other than one ISAKMP key. Adding site 47 to a full-mesh crypto map deployment means touching 46 other routers.

The message IOS gives you, and why it is not an error

Apply the crypto map before the group has registered and IOS says:

% NOTE: This new crypto map will remain disabled until a valid group has been configured.

That is normal. It is telling you the truth: a gdoi crypto map has no policy of its own, so until the router registers to a key server and downloads a group policy, the map has nothing to enforce and stays inert. If it persists after you have configured the group, your registration is failing (check reachability to the key server on UDP 848, the group identity number, and the ISAKMP key).

Step 3: Verify From the Group Member

show crypto gdoi on a member is the single most useful command in GETVPN. It answers four questions at once: did I register, what policy did I get, how are rekeys protected, and what key am I encrypting with.

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

Registration status : Registered is the pass/fail line. Registered with : 10.100.0.11 tells you it picked KS1 (it tries the server list in order). Re-registers in : 692 sec is worth noting: a group member re-registers periodically, which is how it survives a key server going away and coming back.

The policy it downloaded

 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.255

Compare that against PLZ-GET-POLICY on the key server. It is the same ACL. It is not configured on GM1 and never will be. The words "Downloaded From KS" are doing all the work here: this is the centralised policy model made visible. Change the ACL once on the key server, and every member picks up the change.

The KEK policy

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)    : 2352

Every value here traces back to a line on the key server: rekey transport unicast, rekey algorithm aes 256, rekey lifetime seconds 900 (counting down through 849). Sig Key Length (bits) : 2352 is the encoded length of the 2048-bit RSA rekey key the key server signs with. The KEK protects the rekeys. It does not protect user data.

The TEK policy, and the SPI

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_TUNNEL

This is the key that actually encrypts data, and the transform matches PLZ-GET-TS exactly. Now run the same command on the other member:

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-hmac

Same SPI: 0xE1F309BF. Two different routers, one shared SA. If you only run one verification command after building a GETVPN group, run this one on two members and compare the SPI. Matching SPIs means the group is genuinely a group.

The session table, for the shock value

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/2115

UP-ACTIVE, encrypting, peer 0.0.0.0, port 848 (GDOI). If you came from crypto maps or DMVPN, this line is the moment GETVPN stops being abstract. There is no peer because there is no tunnel.

Step 4: Verify From the Key Server

The key server has its own pair of commands, and they are the fastest way to answer "did that new site actually come up?"

KS1#show crypto gdoi ks
Total group members registered to this box: 2
Key Server Information For Group PLZ-GETVPN:
    Group Name               : PLZ-GETVPN
    Group Identity           : 4321
    Group Type               : GDOI (ISAKMP)
    Group Members            : 2
    IPSec SA Direction       : Both
    ACL Configured:
        access-list PLZ-GET-POLICY

Total group members registered to this box: 2 is the health check. IPSec SA Direction : Both confirms the symmetric policy is being applied in both directions, which is the key server's read of the ACL you wrote in step 1c.

For the roster, go one level deeper:

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.11

Both members registered, both to KS1. In a hundred-site deployment this command is your inventory: if a site is missing here, it is not encrypting, and the fault is registration (ISAKMP key, reachability, group identity), not the data plane.

Step 5: Pass Real Traffic

The final proof. Ping between the two protected LANs, sourcing from the loopbacks that the group policy ACL permits, in both directions:

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 ms

One hundred percent both ways, and the #pkts enc'ed counter in show crypto session detail climbing to prove it went through ESP rather than around it. Always check the counter as well as the exclamation marks: a GETVPN group whose crypto map has not activated will happily pass traffic in clear text and the ping still succeeds. The ping proves reachability. The encryption counter proves encryption.

Troubleshooting Order

When a member does not come up, work in this order. It follows the dependency chain, so you never chase a symptom whose cause is one layer down.

Point 7 is the one that catches people migrating a lab onto a real network. GETVPN's outer header carries the original LAN addresses, so if your core cannot route 10.30.10.0/24, no amount of crypto configuration will save you. That constraint is explained in full, with the packet capture, in GETVPN Explained.

Key Takeaways

• All policy lives on the key server. ISAKMP policy, transform set, IPsec profile, the group ACL, the RSA rekey key, and the crypto gdoi group ... server local block. Members get a paste.
• The group policy ACL is symmetric and singular. Write both directions of every flow. It is one ACL for the whole group, not a per-peer mirror image, and it is the thing that gets pushed to every member.
• Generate the RSA rekey key as exportable. You cannot export it later, and COOP key servers must share the same keypair.
• The group member config is nine lines and has no peer and no ACL. GM1 and GM2 are identical. That is the entire scaling story.
• % NOTE: This new crypto map will remain disabled until a valid group has been configured. is expected, not an error. A gdoi crypto map is inert until registration completes.
• Verify with show crypto gdoi on the member for registration status, the downloaded ACL, the KEK policy, and the TEK SPI. Compare the SPI across two members, it must match.
• Verify with show crypto gdoi ks and show crypto gdoi ks members on the key server for the registered roster.
• Check the encryption counter, not just the ping. An inactive crypto map passes traffic in clear text and the ping still returns 100 percent.
• GDOI is fully supported on cat8000v IOS XE 17.18.02. Every command in this article was accepted and verified on that image.

Next, make it survivable: two key servers, priority-based election, real failover syslog, and the RSA rekey key trap that silently kills a group at the next rekey interval, in GETVPN redundancy: COOP key servers and rekey survival. For the rest of the family (IKEv2, crypto maps, VTIs, DMVPN, FlexVPN, certificate authentication, and VRF-aware designs), the IPsec VPN pillar is the index.