Group Encrypted Transport (GET) VPN is slightly different and has quite different use cases from more traditional point to point IPSEC VPN where each point to point VPN is quite distinct in its own right. The most import thing to remember at GET VPN is the "G" means group and the whole group is one single security association!! For traditional VPNs mutliple SPIs can use muliple keys and they number of SA's scales directly with the number of VPN Peers. For GET we'll only have one single shared key (call the "TEK" or Traffic Encryption Key) encrypting and decrypting all the traffic between all members of the VPN "domain"! This means we can scale much more than traditional VPNs. To do this key "sharing" GET VPN uses a device(s) called Key Servers. These are responsible for securely sharing the TEK among all the group/domain members participating in the VPN along with polices to define the "interesting traffic" etc. All group members contact the KS to obtain the TEK and policy for what traffic to encrypt. The initial communication between a new group member (GM) and Key Server (KS) also needs to be secure so accomplish this GET VPN uses an already proven protocol, IKE :) IKE is also used for continued key distribution from the KS to GMs (rekeying) and to protect these transmissions we obviously cant use the TEK so another key is used called the Key Encryption Key (KEK) to protect this IKE tunnel from KS to GM.

One feature GET does not provide over traditional VPNs is tunnelling or encapsulation as we just encrypt the payload data so source/destination IPs etc stay unmodified in the IP header. This means full IP connectivity before we enables GET VPN is a requirement. A side benefit of this single SA and no header modification/tunneling is that if the underlying network supports multicast we can send/encrypt once and that will still be delivered by the network to all devices that need it allowing us again to scale very nicely vs sending/encrypting multiple multicast packets to leave the same interface in traditional point to point vpn networks. It does mean GET VPN is not suitable for general usage over the internet though.

For the Lab we'll be using the topology below and the GNS3 topology and config files can be found [here]. We already have full connectivity between all IPs configured and we'll go through the tunnel setup. Middle-Man is completely unaware of the GET VPN (even though the payload is encrypted) and is only there to represent a transit network for the group members network.

Steps to configure

  1. IP connectivity - A requirement
  2. IKE/ISAKMP profile - Initial secure connection to KS
  3. Key Server (KS) - Shares TEK securely, controls polices and handles re-keying
  4. Group Member (GM) - Encrypt the traffic defined by the KS over the GDOI (Group Domain of Interpretation)

IP Connectivity

Done? (but as ever worth testing yourself) :D The Middle-Man router could easily represent a L3VPN cloud or any other network we have end to end connectivity (of all subnets) on.E.g we can ping from to

ISAKMP profile

This is used for the initial connectivity from the GM to KS and as ever both the KS and GM need to have one common IKE policy defined that matches exactly on both devices. We'll be using the config below on all devices in our lab:
KEYS-1(config)#crypto isakmp policy 10 
KEYS-1(config-isakmp)#authentication pre-share 
KEYS-1(config-isakmp)#encryption aes 256 
KEYS-1(config-isakmp)#hash sha 
KEYS-1(config-isakmp)#group 5 
KEYS-1(config-isakmp)# exit
KEYS-1(config)#crypto isakmp key 0 MYISAKMPKEY address
We could configure specific keys but in this case we're not labbing IKE so lets make it easy for ourselves and define a key we'll accept from any source :) Confirm on each with show crypto isakmp policy or similar. Just to be clear this isnt required on the Middle-Man or any transit router.

Key Server

So far we've configured any GET VPN specific config at all but now with the KS config we will! There are a few steps to getting a usable Key Server up and running

Key Encryption Key (KEK)

The IKE policy we created above is used for the initial connection to the KS but after this our KEK is used to protect all communication from the KS to the GM. The KEK uses RSA keys to protect it so we need to generate this for the KEK:
KEYS-1(config)#crypto key generate rsa label GETVPN modulus 2048            
The name for the keys will be: GETVPN

% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...[OK]


We'll reference this key when we configure the KS config for our GET VPN so it is important to label it and reuse the name later on. Also worth noting if you have more than one KS in the domain for failover etc you will need to make this key exportable and copy it to all other KS.


In traditional IPSEC VPN we use transform sets and ACLs to define what should be encrypted and how it should be encrypted. GET VPN still uses this in a very similar config but the difference being in that this becomes a policy for the group and is "pushed" out from the KS to each GM to allow all GMs to have a common IPSEC policy across the group. First off we create our match ACL to encrypt all traffic to/from the range then create the IPSEC transform set/profile just as we usually would under a more traditional point to point VPN.
KEYS-1(config)#ip access-list extended 100 
KEYS-1(config-ext-nacl)#permit ip 
KEYS-1(config)#crypto ipsec transform-set GETVPN-SET ah-sha-hmac esp-aes 256 esp-sha-hmac
KEYS-1(config)#crypto ipsec profile GETVPN-PRO
KEYS-1(ipsec-profile)#set transform-set GETVPN-SET 
That defines our policy we'll "push" so we have a policy and with our KEK a secure way to initially connect to the KS. Now configure the KS to use what we have configured so far. Note we can only use esp for GET VPN transform sets! So no AH options

Group Config

The group needs something to identify itself and this can either be a number or and address. We'll use the same address as the IP of the KS we're going to connect to. This identity number can really be anything but needs to match on all GM and KSs in the group.
KEYS-1(config)#crypto gdoi group GETVPN-GRP
KEYS-1(config-gdoi-group)#identity ?
  address  Set the identity of the group as an address
  number   Set the identity of the group as a number

KEYS-1(config-gdoi-group)#identity address ipv4

Server Config

The server definition takes place under the group configuration section of configuration mode and when we define "local" this drops us into a different context so we can configure the local server setup and that local server config will reference our IPSEC policies from earlier (what and how to encrypt)
KEYS-1(config-gdoi-group)#server local 
KEYS-1(gdoi-local-server)# !

Group Member

Group member config is reasonably straight forward as you just define the IP of the KS and identity of the group to join (for this Lab we're using the KS IP) then tie that to a traditional configuration construct of a crypto map. Although notice that we dont need to define 'traditional' things transform sets or defining interesting traffic as this is all pushed from the KS after we join the group.This config is exactly the same for all our GM routers
GM-1(config)#crypto gdoi group GETVPN-GROUP
GM-1(config-gdoi-group)#identity address ipv4
GM-1(config-gdoi-group)#server address ipv4 
GM-1(config)#crypto map GETVPN-MAP 10 gdoi 
% NOTE: This new crypto map will remain disabled until a valid
	group has been configured.
GM-1(config-crypto-map)#set group GETVPN-GROUP 
GM-1(config)#int fa 0/0
GM-1(config-if)#crypto map GETVPN-MAP 
*Mar  1 01:51:32.279: %CRYPTO-5-GM_REGSTER: Start registration to KS for group GETVPN-GROUP using address
*Mar  1 01:51:32.307: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
*Mar  1 01:51:32.667: %GDOI-5-GM_REKEY_TRANS_2_UNI: Group GETVPN-GROUP transitioned to Unicast Rekey.
*Mar  1 01:51:32.707: %GDOI-5-GM_REGS_COMPL: Registration to KS complete for group GETVPN-GROUP using address
So add all GMs to the group :) ... Job done.


Now we have all GMs sharing a single SA to encrypt and decrypt all the traffic over a transit network so lets confirm that!


Notice the rekeying connection does not use standard IKEv1 port of 500 rather IKEv2 port of UDP/848.
GM-2#show crypto isakmp sa        
dst             src             state          conn-id slot status         GDOI_REKEY        1003    0 ACTIVE    GDOI_IDLE         1001    0 ACTIVE         GDOI_REKEY        1002    0 ACTIVE


GM-2#show crypto isakmp peers
Peer: Port: 848 Local:
Phase1 id:

We should also see periodic messages similar to this, from KS:

*Mar  1 02:01:45.903: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GETVPN-GRP from address with seq # 1

Then on GM:

*Mar  1 02:00:26.163: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GETVPN-GROUP from to with seq # 1

As we're using unicast rekeying on the KS each GM will respond with a confirmation when a new TEK is sent to it in this way.

Group Membership

Another good command to verify membership to the group is show crypto gdoi:
GM-2#show crypto gdoi 
Group Name               : GETVPN-GROUP
Group Identity           :
Rekeys received          : 2
IPSec SA Direction       : Both
Active Group Server      :
Group Server list        :
GM Reregisters in        : 2746 secs
Rekey Received(hh:mm:ss) : 00:03:13

Rekeys received          
     Cumulative          : 2
     After registration  : 2
Rekey Acks sent          : 2

ACL Downloaded From KS
access-list permit ip

Rekey Transport Type : Unicast
Lifetime (secs) : 299
Encrypt Algorithm : AES
Key Size : 256
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 2048

IPsec SA:
sa direction:inbound
spi: 0x6263F2E0(1650717408)
transform: esp-256-aes esp-sha-hmac
sa timing:remaining key lifetime (sec): (2532)
Anti-Replay : Disabled

IPsec SA:
    sa direction:outbound
    spi: 0x6263F2E0(1650717408)
    transform: esp-256-aes esp-sha-hmac 
    sa timing:remaining key lifetime (sec): (2532)
    Anti-Replay : Disabled

IPsec SA:
    sa direction:inbound
    spi: 0x8DFED744(2382288708)
    transform: esp-256-aes esp-sha-hmac 
    sa timing:remaining key lifetime (sec): (2803)
    Anti-Replay : Disabled

IPsec SA:
    sa direction:outbound
    spi: 0x8DFED744(2382288708)
    transform: esp-256-aes esp-sha-hmac 
    sa timing:remaining key lifetime (sec): (2803)
    Anti-Replay : Disabled</pre>

Notice the lifetime of the SA and the SPI. The SPI is the same for each direction for each valid key.


We can also confirm this with again more "traditional" commands like show crypto ipsec sa.

Finally ping from one of the loopbacks to another loopback then check the packets are being en/decrypted with show crypto ipsec sa along with running a wireshark between them on the transit network, also noticing we havent modified the source/destination IP headers:

Verify the SPI from wireshark on all the GMs is the same! :)

GM-2#show crypto ipsec sa | i 2E0
     current outbound spi: 0x6263F2E0(1650717408)
      spi: 0x6263F2E0(1650717408)
      spi: 0x6263F2E0(1650717408)

So one single SA encrypting traffic to different destinations that can scale massively with ease :)

More info

Its well worth reading over the Design and Implementation guide on the Cisco site for more detailed info:

As ever any thoughts, suggestions or comments just let me know

m00nie :)