GET VPN (GNS3 Lab)
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)
Done? (but as ever worth testing yourself) 😀 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.
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 0.0.0.0 0.0.0.0
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.
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.
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)#exit
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
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 22.214.171.124
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 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 126.96.36.199 GM-1(config-gdoi-group)#server address ipv4 188.8.131.52 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 184.108.40.206 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 220.127.116.11 complete for group GETVPN-GROUP using address 192.168.1.6 GM-1(config-if)#
So add all GMs to the group 🙂 … Job done.
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!
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 18.104.22.168 GDOI_REKEY 1003 0 ACTIVE 22.214.171.124 192.168.1.10 GDOI_IDLE 1001 0 ACTIVE 192.168.1.10 126.96.36.199 GDOI_REKEY 1002 0 ACTIVE IPv6 Crypto ISAKMP SA GM-2#show crypto isakmp peers Peer: 188.8.131.52 Port: 848 Local: 192.168.1.10 Phase1 id: 184.108.40.206
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 220.127.116.11 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 18.104.22.168 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.
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 : 22.214.171.124 Rekeys received : 2 IPSec SA Direction : Both Active Group Server : 126.96.36.199 Group Server list : 188.8.131.52 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 184.108.40.206: 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
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 🙂
Its 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