GETVPN Example
A couple of weeks ago I had the good fortune of attending Jeremy Filliben’s CCDE Bootcamp.
It was a great experience, which I will elaborate on in another post. But one of the technology areas I had a bit of difficult with, was GETVPN.
So in this post a I am going to setup a scenario in which a customer has 3 sites, 2 “normal” sites and a Datacenter site. The customer wants to encrypt traffic from Site 1 to Site 2.
Currently the customer has a regular L3VPN service from a provider (which is beyond the scope of this post). There is full connectivity between the 3 sites through this service.
The topology is as follows:
GETVPN consists of a few components, namely the Key Server (KS) and Group Members (GM’s), which is where it derives its name: Group Encrypted Transport. A single SA (Security Association) is used for the encryption. The Key Server distributes the information to the Group Members through a secure transport, where the Group Members then use this information (basically an ACL) to encrypt/decrypt the data packets.
The routing for the topology is fairly simple. (See Routing Diagram) Each client as well as the KeyServer uses a default route to reach the rest of the topology. Each CE router runs eBGP with the provider, where it redistributes the conntected interfaces into BGP for full reachability between the sites.
At this point, lets verify that we have full connectivty through the L3VPN SP.
On CE-1:
CE1#sh ip bgp
BGP table version is 7, local router ID is 192.168.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.1.0/24 0.0.0.0 0 32768 ?
*> 10.10.2.0/24 10.10.1.2 0 100 100 ?
*> 10.10.3.0/24 10.10.1.2 0 100 100 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*> 192.168.23.0 10.10.1.2 0 100 100 ?
*> 192.168.34.0 10.10.1.2 0 100 100 ?
We are learning the routes to the other sites.
And connectivity from Client-1:
Client-1#ping 192.168.34.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.34.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/10/25 ms
The interesting part takes place on the KeyServer along wi th CE1 and CE3.
If we take a look at the configuration on the KeyServer.
First off, we have a regular extended ACL that defines what traffic we want to encrypt. This ACL is the one that gets “downloaded” to CE1 and CE3:
ip access-list extended CRYPTO_ACL permit ip 192.168.12.0 0.0.0.255 192.168.34.0 0.0.0.255 permit ip 192.168.34.0 0.0.0.255 192.168.12.0 0.0.0.255
Next up we have an ISAKMP policy which is used during the information communication with the KeyServer. This policy is present on all the Group Members (GM’s) and the KeyServer:
crypto isakmp policy 10 encr aes 256 hash sha256 authentication pre-share group 2 crypto isakmp key SUPERSECRET address 0.0.0.0
In this example we use a simple Pre Shared Key with the Any address form. This can (and probably should) be either certificate based. However, this complicates matters, so i skipped that.
Next is the transform set for IPsec which will be used. Notice that we use tunnel mode.
crypto ipsec transform-set GET-VPN-TRANSFORM-SET esp-aes esp-sha256-hmac mode tunnel
This transform set is being referenced in a IPsec profile configuration:
crypto ipsec profile GETVPN-PROFILE set transform-set GET-VPN-TRANSFORM-SET
This is nesecary in order for the next configuration, which is the entire GDOI aspect:
crypto gdoi group GDOI-GROUP identity number 100 server local rekey authentication mypubkey rsa GETVPN-KEY rekey transport unicast sa ipsec 1 profile GETVPN-PROFILE match address ipv4 CRYPTO_ACL replay counter window-size 64 no tag address ipv4 192.168.23.1
Here we are creating a GDOI configuration, where we have a unique identifier for this group configuration (100). We are telling the router that its the server. Next is the public key we have created with an name this time (“crypto key generate rsa label “). This is used for rekeying purposes. And notice that we are using unicasting for the key material. This could just as well have been multicast, but again, that requires you have your infrastructure multicast capable and ready.
We then reference our previous IPsec profile and specify our crypt “ACL”. Lastly we specify which “update source” should be used for this server (which the other GM’s will use to communicate to/from).
If we then match this to what is configured on CE1 and CE3:
crypto isakmp policy 10 encr aes 256 hash sha256 authentication pre-share group 2 crypto isakmp key SUPERSECRET address 0.0.0.0 crypto gdoi group GDOI-GROUP identity number 100 server address ipv4 192.168.23.1 crypto map MYMAP 10 gdoi set group GDOI-GROUP crypto map MYMAP
And on the interface towards the SP we apply the crypto map:
CE1#sh run int g1.10 Building configuration... Current configuration : 115 bytes ! interface GigabitEthernet1.10 encapsulation dot1Q 10 ip address 10.10.1.1 255.255.255.0 crypto map MYMAP end
We can see that we have the ISAKMP configuration which I mentioned thats being used for a secure communication channel. Next we simply have the location of our KeyServer and the Identifier and thats pretty much all. Everything else is being learned from the Key Server.
After everything has been configured, you can see the log showing the registration process:
*May 15 10:37:53.245: %CRYPTO-5-GM_REGSTER: Start registration to KS 192.168.23.1 for group GDOI-GROUP using address 10.10.3.1 fvrf default ivrf default *May 15 10:38:23.356: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated *May 15 10:38:23.395: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0x5DB57E80F97A9A1DC16B9DBBCF7CB169 *May 15 10:38:23.395: %GDOI-5-GM_REGS_COMPL: Registration to KS 192.168.23.1 complete for group GDOI-GROUP using address 10.10.3.1 fvrf default ivrf default *May 15 10:38:23.668: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 192.168.23.1 for group GDOI-GROUP & gm identity 10.10.3.1 fvrf default ivrf default
Another form of verification is the “show crypto gdoi” command structure, which gives you alot of information on the process:
CE1#sh crypto gdoi
GROUP INFORMATION
Group Name : GDOI-GROUP
Group Identity : 100
Group Type : GDOI (ISAKMP)
Crypto Path : ipv4
Key Management Path : ipv4
Rekeys received : 0
IPSec SA Direction : Both
Group Server list : 192.168.23.1
Group Member Information For Group GDOI-GROUP:
IPSec SA Direction : Both
ACL Received From KS : gdoi_group_GDOI-GROUP_temp_acl
Group member : 10.10.1.1 vrf: None
Local addr/port : 10.10.1.1/848
Remote addr/port : 192.168.23.1/848
fvrf/ivrf : None/None
Version : 1.0.16
Registration status : Registered
Registered with : 192.168.23.1
Re-registers in : 1580 sec
Succeeded registration: 1
Attempted registration: 3
Last rekey from : 0.0.0.0
Last rekey seq num : 0
Unicast rekey received: 0
Rekey ACKs sent : 0
Rekey Received : never
DP Error Monitoring : OFF
IPSEC init reg executed : 0
IPSEC init reg postponed : 0
Active TEK Number : 1
SA Track (OID/status) : disabled
allowable rekey cipher: any
allowable rekey hash : any
allowable transformtag: any ESP
Rekeys cumulative
Total received : 0
After latest register : 0
Rekey Acks sents : 0
ACL Downloaded From KS 192.168.23.1:
access-list permit ip 192.168.12.0 0.0.0.255 192.168.34.0 0.0.0.255
access-list permit ip 192.168.34.0 0.0.0.255 192.168.12.0 0.0.0.255
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs) : 84613
Encrypt Algorithm : 3DES
Key Size : 192
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 2352
TEK POLICY for the current KS-Policy ACEs Downloaded:
GigabitEthernet1.10:
IPsec SA:
spi: 0xA3D6592E(2748733742)
KGS: Disabled
transform: esp-aes esp-sha256-hmac
sa timing:remaining key lifetime (sec): (1815)
Anti-Replay(Counter Based) : 64
tag method : disabled
alg key size: 16 (bytes)
sig key size: 32 (bytes)
encaps: ENCAPS_TUNNEL
Among the most interesting is the KEK policy and the ACL thats in place.
If we then verify from Client-1, we can see that we have a couple of seconds timeout while the encryption is being setup, and from there we have connectivity:
Client-1#ping 192.168.34.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.34.1, timeout is 2 seconds: ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 2/2/2 ms
So from something thats in theory very complex, this is very efficient from a both a configuration as well as a control-plane point of view. I know it certainly helped me understand the steps involved in setting GETVPN to create this lab, so I hope its been relevant for you as well!