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 (Group Domain of Interpretation)
IP ConnectivityDone? (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 profileThis 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 0.0.0.0 0.0.0.0We 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 policyor similar. Just to be clear this isnt required on the Middle-Man or any transit router.
Key ServerSo 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.
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.
KEYS-1(config)#ip access-list extended 100 KEYS-1(config-ext-nacl)#permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 KEYS-1(config-ext-nacl)#exit KEYS-1(config)#crypto ipsec transform-set GETVPN-SET ah-sha-hmac esp-aes 256 esp-sha-hmac KEYS-1(cfg-crypto-trans)#exit KEYS-1(config)#crypto ipsec profile GETVPN-PRO KEYS-1(ipsec-profile)#set transform-set GETVPN-SET KEYS-1(ipsec-profile)#exitThat 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 ConfigThe 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 18.104.22.168
Server ConfigThe 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 MemberGroup 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 22.214.171.124 GM-1(config-gdoi-group)#server address ipv4 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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/TestingNow 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/RekeyingNotice 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 220.127.116.11 GDOI_REKEY 1003 0 ACTIVE 18.104.22.168 192.168.1.10 GDOI_IDLE 1001 0 ACTIVE 192.168.1.10 22.214.171.124 GDOI_REKEY 1002 0 ACTIVE
IPv6 Crypto ISAKMP SA
GM-2#show crypto isakmp peers
Peer: 126.96.36.199 Port: 848 Local: 192.168.1.10
Phase1 id: 188.8.131.52
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 184.108.40.206 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 220.127.116.11 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 MembershipAnother 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 : 18.104.22.168 Rekeys received : 2 IPSec SA Direction : Both Active Group Server : 22.214.171.124 Group Server list : 126.96.36.199 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 188.8.131.52:
access-list permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
Rekey Transport Type : Unicast
Lifetime (secs) : 299
Encrypt Algorithm : AES
Key Size : 256
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 2048
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.
IPSECWe 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 infoIts well worth reading over the Design and Implementation guide on the Cisco site for more detailed info: http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf
As ever any thoughts, suggestions or comments just let me know