GETVPN Using Multicast Distribution on the KS

Hi and Hello, first of all I want to say Happy New Year, we're now entering the 2013, what a day, one year has just been passed so quickly

in this blog I want to write about the latest VPN Technology from Cisco, which is GETVPN. the Idea of the GETVPN is to overcome the Tunnels configuration that should have been done by the Router, which is in the Large deployment, one router, usually HQ Router, should have handled a ton off VPN tunnel from branch offices. Hey, Cisco has developed DMVPN solution, so we only need one tunnel for all connectivity?!?

that is correct, from the Management perspective, you may have one tunnel in the DMVPN, but from the VPN perspective (Phase-1 & Phase-2 IPSec), you still have a lot of 'established' IPSec Tunnel.

Cisco came with the Idea to create a 'Tunnel-less' IPSec VPN technology, so that every router will not create tunnel to the others.

so, puff, the GETVPN technology was introduced. the GETVPN Technology offers benefit compare to the traditional IPSec VPN Technology, in term of:

- The key Distribution will be handled by separate router, called the Key Server (KS). You could say that the KS will work on the 'Control-Plane' of the Implementation. this KS will not involved in the Data-Plane portion in the IPSec VPN.

- Tunnel-Less IPSec VPN implementation, so that VPN Traffic will rely on the Basic Routing on the environment.

- Can deliver any-to-any VPN implementation much more easily and efficiently ;)

Ok, lets get to the point, in My blog I will show you the deployment of the GETVPN using Multicast Distribution for the communication between KS and Group Members (GM), which are the router that will participate in the VPN Data-Plane. Why using multicast? Since most of the example, especially in the CiscoDoc, at the time of the writing, was done using unicast, So I think it is better to demonstrate something quite different :p

Here are the scenario:

  

• All Loopback Router Address are 150.19.X.X/16
•  Configure The Internetwork topology to allow multicast Traffic.
• Configure GETVPN where R3 will be act as KS and R1,R2, and R4 will be act as GM
•  Key distribution must be Use Multicast address 239.19.19.19
• Traffic from Loopback SW1 to SW2 should be encrypted and vice versa
• Any traffic goes to the multicast address 239.4.4.4 must be encrypted

·         Configure The Internetwork topology to allow multicast Traffic.

R1-R2 ! ip multicast-routing ! Interface loopback0  Ip pim sparse-mode ! Interface fa0/0 – 1  Ip pim sparse-mode ! end

R3&R4 ! ip multicast-routing ! Interface loopback0  Ip pim sparse-mode ! Interface fa0/0  Ip pim sparse-mode ! Interface virtual-template 34  Ip pim sparse-mode ! end

SW1 ! ip multicast-routing ! Interface loopback0  Ip pim sparse-mode ! Interface vlan 12  Ip pim sparse-mode ! end

I Used Bootstrap Router (BSR) to distribute the RP information. In this case, SW1 will act as Randevous-Point (RP) and R3 will act as BSR Announcing Router (BSR Candidate). Note that in order to run BSR, we should use PIM version 2, which is default in Cisco IOS.

SW1 ! ip pim rp-candidate Loopback0 ! End R3 ! ip pim bsr-candidate Loopback0 0 ! end

Verification:

Rack19R1#sh ip pim interface Address          Interface                Ver/   Nbr    Query  DR     DR                                           Mode   Count  Intvl  Prior 150.19.1.1       Loopback0                v2/S   0      30     1      150.19.1.1 10.19.123.1      FastEthernet0/0          v2/S   2      30     1      10.19.123.3 10.19.12.1       FastEthernet0/1          v2/S   2      30     1      10.19.12.7 Rack19R1#show ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.19.123.3       FastEthernet0/0          00:39:27/00:01:41 v2    1 / DR S P G 10.19.123.2       FastEthernet0/0          00:39:39/00:01:41 v2    1 / S P G 10.19.12.2        FastEthernet0/1          00:39:37/00:01:34 v2    1 / S P G 10.19.12.7        FastEthernet0/1          00:39:51/00:01:28 v2    1 / DR S G

Rack19R1-R4#show ip pim bsr-router PIMv2 Bootstrap information   BSR address: 150.19.3.3 (?)   Uptime:      00:39:18, BSR Priority: 0, Hash mask length: 0   Expires:     00:01:17 Rack19SW1#sh ip pim bsr-router PIMv2 Bootstrap information   BSR address: 150.19.3.3 (?)   Uptime:      00:39:49, BSR Priority: 0, Hash mask length: 0   Expires:     00:01:47   Candidate RP: 150.19.7.7(Loopback0)     Holdtime 150 seconds     Advertisement interval 60 seconds     Next advertisement in 00:00:12

Let pretend that some user is joining the Multicast group 239.4.4.4 on VLAN 4

R4 ! interface FastEthernet0/0 ip pim sparse-mode  ip igmp join-group 239.4.4.4 ! end

Let see that SW1 will be elected automatically as RP

Rack19R4#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4   RP 150.19.7.7 (?), v2     Info source: 150.19.3.3 (?), via bootstrap, priority 0, holdtime 150          Uptime: 00:45:43, expires: 00:02:24 Rack19R4#sh ip mroute IP Multicast Routing Table <…SNIP…> (*, 239.4.4.4), 00:43:08/00:02:38, RP 150.19.7.7, flags: SJCL   Incoming interface: Virtual-Access1, RPF nbr 10.19.34.3   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 00:43:08/00:02:38 (*, 224.0.1.40), 00:44:36/00:02:27, RP 0.0.0.0, flags: DCL   Incoming interface: Null, RPF nbr 0.0.0.0   Outgoing interface list:     Loopback0, Forward/Sparse, 00:44:34/00:02:27

Rack19R2#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4   RP 150.19.7.7 (?), v2     Info source: 150.19.3.3 (?), via bootstrap, priority 0, holdtime 150          Uptime: 00:46:06, expires: 00:02:03 Rack19R2#sh ip mroute <…SNIP…> (*, 239.4.4.4), 00:43:39/00:03:09, RP 150.19.7.7, flags: S   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.7   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 00:43:39/00:03:09 (*, 224.0.1.40), 00:46:14/00:02:46, RP 0.0.0.0, flags: DCL   Incoming interface: Null, RPF nbr 0.0.0.0   Outgoing interface list:     Loopback0, Forward/Sparse, 00:46:12/00:02:46

• Configure GETVPN where R3 will be act as KS and R1,R2, and R4 will be act as GM
• Key distribution must be Use Multicast address 239.19.19.19
• Traffic from Loopback SW1 to SW2 should be encrypted and vice versa
• Any traffic goes to the multicast address 239.4.4.4 must be encrypted

In order GETVPN use the Multicast address to distribute the Key, we should create an explicit Access-list, where the source is gotta be the KS and destination is the specified multicast address. Since GETVPN using UDP port 848, in This case we’d better use the default UDP port in the Multicast Address. I tried using the other port, but in my previous lab, the traffic is not getting encrypted (Wheather GNS problem or Config problem), since all the GM get the GDOI configuration normally. So the bottom line was, use the UDP default port!!! J

KS Configuration R3 ! ! crypto isakmp policy 1  encryption des  hash md5  authentication pre-share crypto isakmp key CISCO address 150.19.0.0 255.255.0.0 no-xauth ! ! crypto ipsec transform-set TS_DES_MD5 esp-des esp-md5-hmac ! crypto ipsec profile IPSEC_PROFILE  set transform-set TS_DES_MD5 ! ! ip access-list extended ACL_GETVPN_DATA  permit ip 150.19.8.0 0.0.0.255 150.19.7.0 0.0.0.255  permit ip 150.19.7.0 0.0.0.255 150.19.8.0 0.0.0.255  permit ip any host 239.4.4.4 ! ip access-list extended ACL_GETVPN_MCAST  permit udp host 150.19.3.3 eq 848 host 239.19.19.19 eq 848 ! ! crypto gdoi group GETVPN  identity number 29281  server local   rekey address ipv4 ACL_GETVPN_MCAST   rekey lifetime seconds 300   rekey retransmit 10 number 2   rekey authentication mypubkey rsa IOS_CA   registration interface Loopback0   sa ipsec 1    profile IPSEC_PROFILE    match address ipv4 ACL_GETVPN_DATA    replay time window-size 100   address ipv4 150.19.3.3 ! end

In this case I use the rsa label IOS_CA as my crypto rsa key J

GM Configuration R1,R2,R4 ! crypto isakmp policy 1  hash md5  authentication pre-share crypto isakmp key CISCO address 150.19.0.0  255.255.0.0    no-xauth ! crypto gdoi group GETVPN  identity number 29281  server address ipv4 150.19.3.3 ! crypto map CMAP local-address Loopback0 crypto map CMAP 1 gdoi  set group GETVPN ! Interface F0/0 (on R1 & R2)  Crypto map CMAP ! Interface virtual-template 34 (on R4)  Crypto map CMAP ! end

Verification

On KS Rack19R3#show crypto gdoi GROUP INFORMATION     Group Name               : GETVPN (Multicast)     Group Identity           : 29281     Crypto Path              : ipv4     Key Management Path      : ipv4     Group Members            : 3     IPSec SA Direction       : Both     Group Rekey Lifetime     : 300 secs     Group Rekey         Remaining Lifetime   : 281 secs     Rekey Retransmit Period  : 10 secs     Rekey Retransmit Attempts: 2     Group Retransmit         Remaining Lifetime   : 0 secs       IPSec SA Number        : 1       IPSec SA Rekey Lifetime: 3600 secs       Profile Name           : IPSEC_PROFILE       Replay method          : Time Based       Replay Window Size     : 100       SA Rekey          Remaining Lifetime  : 2942 secs       ACL Configured         : access-list ACL_GETVPN_DATA      Group Server list       : Local Rack19R3#show crypto gdoi ks Total group members registered to this box: 3 Key Server Information For Group GETVPN:     Group Name               : GETVPN     Group Identity           : 29281     Group Members            : 3     IPSec SA Direction       : Both     ACL Configured:         access-list ACL_GETVPN_DATA Rack19R3#show crypto gdoi ks rekey Group GETVPN (Multicast)     Number of Rekeys sent               : 48     Number of Rekeys retransmitted      : 48     KEK rekey lifetime (sec)            : 300         Remaining lifetime (sec)        : 231     Retransmit period                   : 10     Number of retransmissions           : 2     IPSec SA 1  lifetime (sec)          : 3600         Remaining lifetime (sec)        : 2892     Number of registrations after rekey : 1     Multicast destination address       : 239.19.19.19 Rack19R3#show crypto gdoi ks members Group Member Information : Number of rekeys sent for group GETVPN : 49 Group Member ID    : 150.19.1.1  GM Version: 1.0.4  Group ID          : 29281  Group Name        : GETVPN  Key Server ID     : 150.19.3.3 Group Member ID    : 150.19.2.2  GM Version: 1.0.4  Group ID          : 29281  Group Name        : GETVPN  Key Server ID     : 150.19.3.3 Group Member ID    : 150.19.4.4  GM Version: 1.0.4  Group ID          : 29281  Group Name        : GETVPN  Key Server ID     : 150.19.3.3

On GM Rack19R1#show crypto gdoi GROUP INFORMATION     Group Name               : GETVPN     Group Identity           : 29281     Crypto Path              : ipv4     Key Management Path      : ipv4     Rekeys received          : 50     IPSec SA Direction       : Both      Group Server list       : 150.19.3.3     Group member             : 150.19.1.1       vrf: None        Version               : 1.0.4        Registration status   : Registered        Registered with       : 150.19.3.3        Re-registers in       : 159 sec        Succeeded registration: 1        Attempted registration: 1        Last rekey from       : 150.19.3.3        Last rekey seq num    : 0        Multicast rekey rcvd  : 50        allowable rekey cipher: any        allowable rekey hash  : any        allowable transformtag: any ESP     Rekeys cumulative        Total received        : 50        After latest register : 50        Rekey Rcvd(hh:mm:ss)  : 00:00:35  ACL Downloaded From KS 150.19.3.3:    access-list   permit ip 150.19.8.0 0.0.0.255 150.19.7.0 0.0.0.255    access-list   permit ip 150.19.7.0 0.0.0.255 150.19.8.0 0.0.0.255    access-list   permit ip any host 239.4.4.4 KEK POLICY:     Rekey Transport Type     : Multicast     Lifetime (secs)          : 263     Encrypt Algorithm        : 3DES     Key Size                 : 192     Sig Hash Algorithm       : HMAC_AUTH_SHA     Sig Key Length (bits)    : 1024 TEK POLICY for the current KS-Policy ACEs Downloaded:   FastEthernet0/0:     IPsec SA:         spi: 0x5A2932B2(1512649394)         transform: esp-des esp-md5-hmac         sa timing:remaining key lifetime (sec): (2764)         Anti-Replay(Time Based) : 100 sec interval Rack19R1#show crypto gdoi gm rekey Group GETVPN (Multicast)     Number of Rekeys received (cumulative)       : 50     Number of Rekeys received after registration : 50     Multicast destination address                : 239.19.19.19 Rack19R1#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst             src             state          conn-id status 150.19.3.3      150.19.1.1      GDOI_IDLE         1001 ACTIVE 239.19.19.19    150.19.3.3      GDOI_REKEY        1053 ACTIVE

We can see that the Multicast routing table containing IP 239.19.19.19, which is being used for GDOI (Group domain of Interpretation) rekey process

Rack19R2#show ip mroute <…SNIP…> (*, 239.19.19.19), 01:09:40/00:02:45, RP 150.19.7.7, flags: SJCL   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.7   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 01:09:40/00:02:45 (150.19.3.3, 239.19.19.19), 01:09:13/00:02:15, flags: PLR   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.1   Outgoing interface list: Null (*, 239.4.4.4), 01:22:21/00:02:49, RP 150.19.7.7, flags: S   Incoming interface: FastEthernet0/1, RPF nbr 10.19.12.7   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 01:22:21/00:02:49 (*, 224.0.1.40), 01:24:57/00:02:05, RP 0.0.0.0, flags: DCL   Incoming interface: Null, RPF nbr 0.0.0.0   Outgoing interface list:     Loopback0, Forward/Sparse, 01:24:55/00:02:05

Let us verify the encryption process: I will do the ICMP traffic from

1. 10.19.4.8 --> 150.19.7.7, where we will not see the traffic encrypted

Rack19SW2#ping 150.19.7.7 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.19.7.7, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/76/104 ms

2. 150.19.8.8 --> 150.19.7.7 where we will see the traffic will be encrypted

Rack19SW2#ping 150.19.7.7 sou loop 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.19.7.7, timeout is 2 seconds: Packet sent with a source address of 150.19.8.8 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/133/160 ms

Rack19R4#show crypto ipsec sa interface: Virtual-Template34     Crypto map tag: CMAP, local addr 150.19.4.4    protected vrf: (none)    local  ident (addr/mask/prot/port): (150.19.7.0/255.255.255.0/256/0)    remote ident (addr/mask/prot/port): (150.19.8.0/255.255.255.0/256/0)    current_peer 0.0.0.0 port 848      PERMIT, flags={}     #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0     #pkts decaps: 25, #pkts decrypt: 25, #pkts verify: 25     #pkts compressed: 0, #pkts decompressed: 0     #pkts not compressed: 0, #pkts compr. failed: 0     #pkts not decompressed: 0, #pkts decompress failed: 0     #send errors 0, #recv errors 0

 3. 150.19.2.2 à 239.4.4.4, where we will see the traffic will be encrypted

Rack19SW1#ping 239.4.4.4 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds: Packet sent with a source address of 150.19.7.7 Reply to request 0 from 10.19.4.4, 388 ms Reply to request 0 from 10.19.4.4, 528 ms

Rack19R2#show crypto ipsec sa interface: FastEthernet0/0     Crypto map tag: CMAP, local addr 150.19.2.2   protected vrf: (none) <…SNIP…>    local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)    remote ident (addr/mask/prot/port): (239.4.4.4/255.255.255.255/256/0)    current_peer 0.0.0.0 port 848      PERMIT, flags={}     #pkts encaps: 32, #pkts encrypt: 32, #pkts digest: 32     #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0     #pkts compressed: 0, #pkts decompressed: 0     #pkts not compressed: 0, #pkts compr. failed: 0     #pkts not decompressed: 0, #pkts decompress failed: 0     #send errors 0, #recv errors 0 <…SNIP…>

Summary:

GETVPN is quite powerful, it can use the Multicast to distribute the Key Rotation, which is very usefull when we have a lot of GMs (above 1000 for example). And GETVPN natively can encrypt the both Unicast and Multicast Traffic, this will reduce the CPU overhead for the process, since the Control Plane (Key calculation) process will be handled only by KS, so GM can focus on the Traffic Encryption.

GETVPN can simplify the Full-Mesh VPN Deployment in the Enterprise, with the drawback that this technology is Cisco proprietary , at least at the time of this writing.

I hope this would be Informative and I’d like to thank you for reading \(^0^)/