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
IP connectivity - A requirement
IKE/ISAKMP profile - Initial secure connection to KS
Key Server (KS) - Shares TEK securely, controls polices and handles re-keying
Group Member (GM) - Encrypt the traffic defined by the KS over the GDOI (GroupDomain 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 10.1.1.1 to 10.3.3.3.
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:
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]
KEYS-1(config)#^Z
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.
IPSEC!
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 10.0.0.0/8 range then create the IPSEC transform set/profile just as we usually would under a more traditional point to point VPN.
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
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)#
KEYS-1(config-gdoi-group)#
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 1.1.1.1
GM-1(config-gdoi-group)#server address ipv4 1.1.1.1
GM-1(config-gdoi-group)#exit
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-crypto-map)#exit
GM-1(config)#int fa 0/0
GM-1(config-if)#crypto map GETVPN-MAP
GM-1(config-if)#
*Mar 1 01:51:32.279: %CRYPTO-5-GM_REGSTER: Start registration to KS 1.1.1.1 for group GETVPN-GROUP using address 192.168.1.6
*Mar 1 01:51:32.307: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
GM-1(config-if)#
*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 1.1.1.1 complete for group GETVPN-GROUP using address 192.168.1.6
GM-1(config-if)#
So add all GMs to the group :) ... Job done.
Confirmation/Testing
Now we have all GMs sharing a single SA to encrypt and decrypt all the 10.0.0.0/8 traffic over a transit network so lets confirm that!
KEK/Rekeying
Notice the rekeying connection does not use standard IKEv1 port of 500 rather IKEv2 port of UDP/848.
GM-2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
192.168.1.10 1.1.1.1 GDOI_REKEY 1003 0 ACTIVE
1.1.1.1 192.168.1.10 GDOI_IDLE 1001 0 ACTIVE
192.168.1.10 1.1.1.1 GDOI_REKEY 1002 0 ACTIVE
We should also see periodic messages similar to this, from KS:
KEYS-1#
*Mar 1 02:01:45.903: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GETVPN-GRP from address 1.1.1.1 with seq # 1
Then on GM:
GM-2#
*Mar 1 02:00:26.163: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GETVPN-GROUP from 1.1.1.1 to 192.168.1.10 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 INFORMATION
Group Name : GETVPN-GROUP
Group Identity : 1.1.1.1
Rekeys received : 2
IPSec SA Direction : Both
Active Group Server : 1.1.1.1
Group Server list : 1.1.1.1
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 1.1.1.1:
access-list permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs) : 299
Encrypt Algorithm : AES
Key Size : 256
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 2048
TEK POLICY:
FastEthernet0/0:
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.
IPSEC
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 :)
