Group Encrypted Transport VPN (GETVPN)

This topic is to discuss the following lesson:

Due to an audit we just had we need to encrypt all traffic going out MPLS, should my ACL include the LANs and BGP/30 network in the ACL on my MPLS router in the datacenter (which is acting as the KS)?
In your lab you used OSPF but we’re running BGP, is it better to use a IGP verse BGP?

Hi Corwyn,

It shouldn’t matter too much that you use BGP. There is one issue with BGP/GETVPN where traffic can be get blackholed if a GM doesn’t receive keys. Take a look at this:

Apparently, the “Routing Awareness for BGP” feature prevents this from happening but that’s something you should test.

I think the answer depends on what “all traffic” exactly means. Is this about data from your LANs or everything? Including control traffic like BGP?

In my example I used loopbacks but you could see those as your LANs. You could encrypt all LAN-to-LAN traffic by adding those subnets in your access-list. If required, you could also add BGP traffic (or any other control plane traffic) to your ACL and let GETVPN encrypt it.

Rene

2 Likes

I’ll encrypt all traffic including BGP but thanks for the link I’ll read about it.

Rene,

can u provide some examples of the use cases of GETVPN?

Hello Ray

Rene explains the difficulties that IPsec presents when you have a multi site WAN deployment. Even with DMVPN, it is difficult and cumbersome to employ IPsec within such a WAN topology.

The advantages of GETVPN will allow you to create a multi site WAN topology with a single IPsec SA, thus simplifying the implementation of IPsec into a multi site WAN topology.

So examples for the use of GETVPN include all multi site WAN topologies that want to employ IPsec in a scalable manner. For example, a corporation with a DMVPN hub and spoke topology with multiple spokes that want to employ IPsec over each and every connection for security and confidentiality.

GETVPN applies to any such multisite WAN topology simplifying its IPsec deployment with a single SA.

I hope this has been helpful!

Laz

Your configuration explanation doesn’t include the ospf portion of the config. Until that is configured pinging between devices won’t work.

Hello Keith

You are correct that OSPF must be configured in order to have this topology work. As you can see below, Rene mentions that OSPF is configured on the GM routers.

Because this was indeed a long lesson, for the purposes of being brief and concise, the actual OSPF configuration was not included in the lesson. It is however available in the configs of the devices at the very end.

I hope this has been helpful!

Laz

Hi everybody. I am trying to undestand the TEK and KEK lifetime.
I copied the topology you explained and did extra change like this:

KS1#show run | s crypto
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 5
 lifetime 86000
crypto isakmp key MY_KEY address 0.0.0.0        
crypto ipsec transform-set TRANSFORM_SET esp-aes esp-sha-hmac 
 mode tunnel
crypto ipsec profile IPSEC_PROFILE
 **set security-association lifetime seconds 120**
 set transform-set TRANSFORM_SET 
crypto gdoi group GDOI_GROUP
 identity number 123
 server local
  **rekey lifetime seconds 360**
  rekey authentication mypubkey rsa RSA_KEYS
  rekey transport unicast
  sa ipsec 10
   profile IPSEC_PROFILE
   match address ipv4 ICMP
   replay counter window-size 64
   no tag
  address ipv4 192.168.1.254
KS1#

I set TEK lifetime: 120 seconds
I set KEK lifetime: 360 seconds

Follow the recomendation of CISCO:
It is recommended that the KEK lifetime value be at least three times greater than the TEK lifetime value

But the problem is when I looked at the logging messages
TEK lifetime update happend each 60 seconds
KEK lifetime update happend each 90 seconds

Like this:

GM1#show log | i SA
*Dec  7 17:05:00.698: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:05:30.702: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0x6909E7561CEB0B36BD3039FD96E75C16
*Dec  7 17:06:00.706: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:07:00.720: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:07:00.720: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0x390DCED8FF0C1465EF383D03FEA0A2E2
*Dec  7 17:08:00.728: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:08:30.731: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0x4C3DBED2CCF6F1B0E72F59CF613F8184
*Dec  7 17:09:00.738: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:10:00.755: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:10:00.755: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0xC2A4FE2157A3E03F398AF1B54EE13518
*Dec  7 17:11:00.766: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:11:30.771: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0x96DAD8BFF3BB06A7E1573C632996CBCD
*Dec  7 17:12:00.776: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:13:00.812: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:13:00.812: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0x41BD870DE6E388DADACB9C5F8238E114
*Dec  7 17:14:00.813: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:14:30.818: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0xC3096D172FCADD883A4FC441DF183384
*Dec  7 17:15:00.813: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:16:00.831: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec  7 17:16:00.832: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0x968892E5804CC8AE1AEBF7CCA2864B

I don’t understand why Its happen, or what is the algoritm to calculate this, Do you know?

Hello Noe

According to the logs you shared, TEK is updated every 60 seconds and KEK every 90. In order to determine why these messages are being sent try issuing the following command:

show crypto gdoi ks policy

This should show the currently active lifetime values for both TEK and KEK. Take a look and let us know the results. Once that’s confirmed, we can then see how to proceed in troubleshooting…

I hope this has been helpful!

Laz

Thanks for your reply. This is the output of the command show crypto gdoi ks policy

KS1#
KS1#
KS1#show crypto gdoi ks policy
Key Server Policy:
For group GDOI_GROUP (handle: 2147483650) server 192.168.1.254 (handle: 2147483650):

  # of teks : 3  Seq num : 1
  KEK POLICY (transport type : Unicast)
    spi : 0xCC24F40DCEA032105661C392ACB9A5E5
    management alg     : disabled    encrypt alg       : AES       
    crypto iv length   : 16          key size          : 32      
    orig life(sec): 360         remaining life(sec): 305       
    time to rekey (sec): 80        
    sig hash algorithm : enabled     sig key length    : 162     
    sig size           : 129       
    sig key name       : RSA_KEYS
    acknowledgement    : Cisco

  TEK POLICY (encaps : ENCAPS_TUNNEL)
    spi                : 0x9CAE4C22
    access-list        : ICMP
    transform          : esp-aes esp-sha-hmac 
    alg key size       : 16            sig key size          : 20        
    orig life(sec)     : 120           remaining life(sec)   : 96        
    tek life(sec)      : 120           elapsed time(sec)     : 24        
    override life (sec): 0             antireplay window size: 64        
    time to rekey (sec): 5         
          
          
  TEK POLICY (encaps : ENCAPS_TUNNEL)
    spi                : 0x9AFB374A
    access-list        : ICMP
    transform          : esp-aes esp-sha-hmac 
    alg key size       : 16            sig key size          : 20        
    orig life(sec)     : 120           remaining life(sec)   : 66        
    tek life(sec)      : 120           elapsed time(sec)     : 54        
    override life (sec): 0             antireplay window size: 64        
    time to rekey (sec): n/a       
          
          
  TEK POLICY (encaps : ENCAPS_TUNNEL)
    spi                : 0xB3BAF7A4
    access-list        : ICMP
    transform          : esp-aes esp-sha-hmac 
    alg key size       : 16            sig key size          : 20        
    orig life(sec)     : 120           remaining life(sec)   : 36        
    tek life(sec)      : 120           elapsed time(sec)     : 84        
    override life (sec): 0             antireplay window size: 64        
    time to rekey (sec): n/a       
          
          
KS1#
KS1#

I found a formula to obtain rekey time in Key Server

image

I my KS log obtain total 3 retrasmision each 30 seconds.

*Dec 17 16:39:18.024: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 3 spi: 0x85C167F44D66C3AFFDA289BAEE2AE52
*Dec 17 16:39:48.061: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 1 spi: 0x56AE30A25EA34D8263D843028FFB944
*Dec 17 16:40:18.043: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 2 spi: 0x56AE30A25EA34D8263D843028FFB944
*Dec 17 16:40:48.067: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 3 spi: 0x56AE30A25EA34D8263D843028FFB944
*Dec 17 16:41:18.077: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 1 spi: 0xCA95B4D75C965A03FDDDC842A003903E
*Dec 17 16:41:48.049: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 2 spi: 0xCA95B4D75C965A03FDDDC842A003903E
*Dec 17 16:42:18.089: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 3 spi: 0xCA95B4D75C965A03FDDDC842A003903E
*Dec 17 16:42:48.059: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 1 spi: 0xBEC9F965F22735F71440DAA68F7FD73
*Dec 17 16:43:18.066: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address 192.168.1.254 with seq # 2 spi: 0xBEC9F965F22735F71440DAA68F7FD73
KS1#  

I read a little bit about it. I guess that GM and KS overlap old and the new IPsec SA SPI, becouse in the document say

“The GM expects a KEK rekey to occur at least 200 seconds prior to the the current KEK expiry”

excellent explanation , i already listen to brain from ine read cisco document i lose the concept… …but but …
you are the best rene ,your language is easy easy & cover more in concepts in few words
god safe you & we always trust you
:heart_eyes::heart_eyes:

1 Like

Hi Rene,
Saw your lesson on GETVPN. I would like to know how can i simulate the (private wan) cloud in GNS3.

Thank you

Regards
Ezzat Fahmy

Hello Ezzat

You should be able to simply connect all routers to a L2 switch. All of the Gi0/1 interfaces of the routers are on the same subnet. The only prerequisite to getting a GETVPN functioning is that there is network connectivity to the key server, whether that is over a switch on the same VLAN or over the internet on disparate subnets.

I hope this has been helpful!

Laz

When you configure the GDOI group with the command crypto gdoi group when configuring GET VPN, you enter GDOI local server configuration mode and not GKM group configuration mode

GDOI local server configuration mode
Device(config-gdoi-group)#

GKM group configuration mode
Device(config-gkm-group)#

Hello Peter

Yes, you are correct, thanks for pointing that out, I will let @ReneMolenaar know.

Thanks again!

Laz

Hi Peter,

When I read your comment the first thing I thought was I did a copy/paste error. It seems the gkm and gdoi commands are merged.Here’s what it looks like on IOSv 15.6(3)M2 and a CSR1000v:

R1#show version 
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(3)M2, RELEASE SOFTWARE (fc2)
R1#show version | include Version
Cisco IOS XE Software, Version 16.06.01
Cisco IOS Software [Everest], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.6.1, RELEASE SOFTWARE (fc2)

Quick test:

R1(config)#crypto gkm ?
  group  Configure a GKM (Group Key Management, GDOI or G-IKEv2) Group

R1(config)#crypto gdoi ?
  group  Configure a GKM (Group Key Management, GDOI or G-IKEv2) Group

R1(config)#crypto gdoi group TEST
R1(config-gkm-group)#

Rene

So I have multiple branch locations throughout the US and am currently experimenting with DMVPN (with OSPF and OSPFv3) to connect the sites. So far so good with that configuration. But in trying to put IPSec on top of this, as mentioned in the lesson, the scaling factor is becoming difficult.

However as the lesson points out, this is not something you’d want to run on the public internet because of the IP routing issue to get to the KS. So what do we do when we need a multiple router system going over the public (not private) Internet? Although this was an interesting discussion, I sort of tossed it out right after the header change in the packets.

Marcos

Hello Marcos

As you mention, this solution is suitable for private networks like MPLS VPN. A more suitable solution for implementing secure VPNs over multiple peers is using an IPSec VTI Virtual Tunnel Interface.

The most scalable solution is the Dynamic VTI as described in the lesson. VTIs can support multicast features, including those required for routing protocols. You can also find a lot of additional information in Cisco documentation including this presentation from a CiscoLive event several years ago.

I hope this has been helpful!

Laz

hello

why we are using this GETVPN with the Private Network it is already Private why we are using IPsec with a Private Network ???