Welcome to IP Blog of Dream: January 2013

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

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

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

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

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^)/

Welcome to IP Blog of Dream

Wednesday, January 2, 2013

GETVPN Using Multicast Distribution on the KS