Monday, March 9, 2015

DMVPN w GETVPN for encryption



I thought it would be cool to lab out a combination of DMVPN (Dynamic Multipoint VPN, utilizing multipoint GRE dynamic tunnels) with the integration of GETVPN. Group Encrypted Transport VPN, which utilizes a key server that distributes group keys to it's registered members and controls the group security associations between the peers. GETVPN does not use static ipsec tunnels or create the VPN frame work....you would need to have a vpn in place...DMVPN in this example, although GETVPN is best suited over MPLS.  BTW...a great guide for setting up and understanding DMVPN can be found here at firewall.cx:

CONFIGURING CISCO DYNAMIC MULTIPOINT VPN (DMVPN)


Below is my GNS 3 lab diagram. I started by using a single router to represent the internet. I also Port Address Translated the 2 spoke and hub routers public interfaces to allow the private hosts to communicate with the rest of the "Internet" to add some realism. The DMVPN config is below





------------------------------------------------------------------------------------------------------------------------

interface Tunnel0
 description mGRE DMVPN Tunnel





 ip address 192.168.1.1 255.255.255.0
 no ip redirects



 no ip split-horizon eigrp 1

no ip next-hop-self eigrp 1






ip nhrp authentication DMVPN

ip nhrp map multicast dynamic




 ip nhrp network-id 1


 tunnel source 11.11.11.1



 tunnel mode gre multipoint

router eigrp 1
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0
These are the pertinent  parts of the DMVPN config. Nothing special with the physical interfaces- just assign them IPs and activate them. All the config is done on the tunnel interface- which is the fist thing you'll create.

This the hub config. You'll want to use a private address network for your tunnel interfaces.

You will definitely need to disable split-horizon for the EIGRP process running on the tunnel interface. If you don't, your spokes will never get eachothers routes, only the updates from the hubs routes will be present on the spokes. Also if you want direct communication\routes between spoke routers, and not send all traffic via the hub, then disable next-hop-self as well for your EIGRP,

Set your authentication string to allow queries and updates to the NHRP database

Map multicast traffic to the spokes dynamically- this is used and necessary for routing protocols that use multicast packets (ie EIGRP in this case) in their routing updates.

Set the network ID- which will be the same for all participating routers in the VPN cloud.

Your tunnel source is the public facing interface IP.

This command enables the tunnel interface as a multipoint GRE tunnel.

This is your basic advertising of your routers networks- you'll need to add the tunnel network as well in order for EIGRP adjacencies to form.

--------------------------------------------------------------------------------------------------------------------------
Next is the spoke config for the VPN........

--------------------------------------------------------------------------------------------------------------------------





interface Tunnel0
 description mGRE DMVPN Tunnel
 ip address 192.168.1.3 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp map 192.168.1.1 11.11.11.1
 ip nhrp map multicast 11.11.11.1
 ip nhrp network-id 1






 ip nhrp nhs 192.168.1.1

 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

router eigrp 1
 network 10.3.3.0 0.0.0.255
 network 192.168.1.0
ip route 0.0.0.0 0.0.0.0 33.33.33.254


ip access-list extended NATISP
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 10.3.3.0 0.0.0.255 10.0.0.0 0.255.255.255
 permit ip 10.3.3.0 0.0.0.255 any

Almost the same thing for the spokes...but here are the differences:





Maps the hubs NHS tunnel IP to it's public IP

Send multicast traffic to the hub, so that the hub processes it- this is essential for EIGRP to form adjacencies! They will not form otherwise, unless maybe you specify static EIGRP neighbors from hub to spoke, which use unicast instead.

This command tells the spoke who the hub NHRP router is-- in this case GM-R1

The tunnel source is specified as the public interface itself and not the IP- this can be used in case the IP changes dynamically.


I also have a static default route pointing to my ISP router so that clients behind my spoke router can get out to the internet.

What I did here is, deny the private networks in including the tunnel network, from being being natted. I had PAT overloaded the public interface on the spoke routers so that clients can NAT out to the internet, but we obviously don't want the VPN traffic to NAT.

--------------------------------------------------------------------------------------------------------------------------
The other spoke is the same exact thing as the first one....

At this point you should see the peers that have GRE tunnels- as expected, there are 2 tunnels connected to the hub router:

GM-R1#show dmvpn

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 33.33.33.3          192.168.1.3    UP 03:07:36     D
     1 44.44.44.44         192.168.1.4    UP 02:59:23     D


You should have EIGRP neighborships between the hub and each spoke:

GM-R1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   192.168.1.4             Tu0                      10 02:10:58  166  1470  0  31
0   192.168.1.3             Tu0                      10 02:14:55  179  1470  0  28

And, if all is well each router should have routes to the other routers networks- and you should be able to ping and pass traffic at this point.

GM-R4#show ip route

Gateway of last resort is 44.44.44.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 44.44.44.254
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D        10.1.1.0/24 [90/26882560] via 192.168.1.1, 02:12:47, Tunnel0
D        10.3.3.0/24 [90/28162560] via 192.168.1.1, 02:00:59, Tunnel0
C        10.4.4.0/24 is directly connected, FastEthernet0/1
L        10.4.4.4/32 is directly connected, FastEthernet0/1
      44.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        44.44.44.0/24 is directly connected, FastEthernet0/0
L        44.44.44.44/32 is directly connected, FastEthernet0/0
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Tunnel0
L        192.168.1.4/32 is directly connected, Tunnel0


Ok......so here's the GETVPN part...utilizing the GDOI protocol running on UDP port 848. The IKE SAs are setup between the group members and the Key Server...communicating over the public internet. Since my key server sits behind R1 on the private network, I had to port forward UDP 848 and IKE 500 and 4500 (when behind NAT, which is my case) on R1- I used a static NAT mapping IP 11.11.11.5 to the private IP of the KS server......

I'll start with the Key Server setup here:

--------------------------------------------------------------------------------------------------------------------------


KS-R5(config)#crypto key generate rsa label VPNKEY1 modulus 1024 exportable


crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
 lifetime 14400
crypto isakmp key getvpn address 0.0.0.0      


crypto ipsec transform-set TRANS1 esp-aes esp-sha-hmac
 mode tunnel
!
crypto ipsec profile IPSEC1
 set transform-set TRANS1


crypto gdoi group GDOI1
 identity number 1
 server local
  rekey algorithm aes 128
  rekey lifetime seconds 14400
  rekey retransmit 15 number 2
  rekey authentication mypubkey rsa VPNKEY1
  rekey transport unicast
  sa ipsec 10
   profile IPSEC1
   match address ipv4 GETVPN-ACL
   replay counter window-size 64
  address ipv4 10.1.1.5

crypto map CRYPTO1 10 gdoi
 set group GDOI1

no ip routing
ip default-gateway 10.1.1.1

ip access-list extended GETVPN-ACL
 deny   udp any eq 848 any eq 848
 permit gre any any

You'll want to create an RSA keypair here, to use for signing the packets.


ISAKMP policy is defined here. I lazily used the 0.0.0.0 (any ip) as the "allowed" addresses for the key usage among the GDOI members. You would want to restrict these to the public facing IP addresses of your member routers- use one line per address.


Your ipsec transform set and encryption types are set here.


Ipsec profile specifying your transform set




The gdoi group settings here. Note the reference to the rsa key generated earlier. You will also match the traffic that is to be encrypted via an ACL....and reference the ipsec profile you just created (IPSEC1)





You actually don't need to enable the crypto map on the interface of the key server since it sits on the private network-but I left it here for reference.


Here, I disabled routing and set the KS's default gateway as if it was just a host unit.

 I denied the gdoi control traffic on udp port  848 here....and permitted GRE tunnel packets, which includes everything running through the DMVPN. This ACL will be downloaded by the member routers too.


--------------------------------------------------------------------------------------------------------------------------

Here's is one of the Group Member routers- R1-you'll do the same for R3 and 4, with the exception of addressing the KS by it's statically natted public IP.

--------------------------------------------------------------------------------------------------------------------------

ip nat inside source list NATISP interface FastEthernet0/0 overload
ip nat inside source static udp 10.1.1.5 500 11.11.11.5 500 extendable
ip nat inside source static udp 10.1.1.5 848 11.11.11.5 848 extendable
ip nat inside source static udp 10.1.1.5 4500 11.11.11.5 4500 extendable

crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
 lifetime 14400
crypto isakmp key getvpn address 10.1.1.5


crypto gdoi group GDOI1
 identity number 1
 server address ipv4 10.1.1.5
!
!
crypto map CRYPTO1 10 gdoi
 set group GDOI1

interface FastEthernet0/0
 ip address 11.11.11.1 255.255.255.0
 ip nat outside
 speed auto
 duplex auto
 crypto map CRYPTO1

With this router- I Natted an additional public IP (11.11.11.5) to the necessary ports on the KS server sitting on the private network.






Isakmp policy here, and, with this router, I referenced the KS server by it's real private IP address- on R3 and 4, you'll use the public natted IP defined above to reach the KS.



GDOI group- basically specifying the KS server- same thing here- use the public natted IP address of the KS on the remote routers- use the real IP here.


Tie it in w the crypto map- CRYPTO1



"Turn on" the Crypto map for the outside public facing interface.


--------------------------------------------------------------------------------------------------------------------------

As soon as you enable the crypto map on the outside interface- the member router should register with the KS, and display the console output similar to below:

GM-R1(config-if)#crypto map CRYPTO1
GM-R1(config-if)#
*Mar 9 22:05:44.991: %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.1.5 for group GDOI1 using address 10.1.1.1
GM-R1(config-if)#
*Mar 9 22:05:45.007: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
GM-R1(config-if)#
*Mar 9 22:06:06.455: %GDOI-5-GM_REKEY_TRANS_2_UNI: Group GDOI1 transitioned to Unicast Rekey.
*Mar 9 22:06:06.459: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated
*Mar 9 22:06:06.475: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Mar 9 22:06:06.583: %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.1.5 complete for group GDOI1 using address 10.1.1.1
*Mar 9 22:06:06.643: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 10.1.1.5 for group GDOI1 & gm identity 10.1.1.1

On the KS server, after configuring the other member routers, you should see Security Associations with each of the 3 member routers, as shown here:

KS-R5#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.1.5        11.11.11.1      GDOI_IDLE         1007 ACTIVE
10.1.1.5        44.44.44.44     GDOI_IDLE         1008 ACTIVE
10.1.1.5        33.33.33.3      GDOI_IDLE         1005 ACTIVE

This will show you group info, number of members, key lifetimes, group ACL etc

KS-R5#show crypto gdoi
GROUP INFORMATION

    Group Name               : GDOI1 (Unicast)
    Group Identity           : 1
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Group Members            : 3
    IPSec SA Direction       : Both
    Group Rekey Lifetime     : 14400 secs
    Group Rekey
        Remaining Lifetime   : 9195 secs
    Rekey Retransmit Period  : 15 secs
    Rekey Retransmit Attempts: 2
    Group Retransmit
        Remaining Lifetime   : 0 secs

      IPSec SA Number        : 10
      IPSec SA Rekey Lifetime: 3600 secs
      Profile Name           : IPSEC1
      Replay method          : Count Based
      Replay Window Size     : 64
      SA Rekey
         Remaining Lifetime  : 2213 secs
      ACL Configured         : access-list GETVPN-ACL

     Group Server list       : Local

This is the SA from a member router perspective

GM-R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
33.33.33.3      10.1.1.5        GDOI_REKEY        1004 ACTIVE
11.11.11.5      33.33.33.3      GDOI_IDLE         1003 ACTIVE

And again, GDOI info from a group member router- reference the KS via it's public IP

GM-R3#show cry gdoi
GROUP INFORMATION

    Group Name               : GDOI1
    Group Identity           : 1
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Rekeys received          : 1
    IPSec SA Direction       : Both

     Group Server list       : 11.11.11.5

    Group member             : 33.33.33.3       vrf: None
       Version               : 1.0.4
       Registration status   : Registered
       Registered with       : 11.11.11.5
       Re-registers in       : 1426 sec
       Succeeded registration: 2
       Attempted registration: 6
       Last rekey from       : 10.1.1.5
       Last rekey seq num    : 6
       Unicast rekey received: 1
       Rekey ACKs sent       : 1
       Rekey Rcvd(hh:mm:ss)  : 01:27:29
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 1
       After latest register : 0
       Rekey Acks sents      : 1

 ACL Downloaded From KS 11.11.11.5:
   access-list   deny udp any port = 848 any port = 848
   access-list   permit gre any any

KEK POLICY:
    Rekey Transport Type     : Unicast
    Lifetime (secs)          : 8521
    Encrypt Algorithm        : AES
    Key Size                 : 128
    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: 0x4F0F578E(1326405518)
        transform: esp-aes esp-sha-hmac
        sa timing:remaining key lifetime (sec): (1540)
        Anti-Replay : Disabled



At this point, you'll want to send some pings over the network via the tunnel-  the encaps and decaps should increment, confirming that the traffic is indeed being encrypted via GETVPN. 

GM-R3#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: CRYPTO1, local addr 33.33.33.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 964, #pkts encrypt: 964, #pkts digest: 964
    #pkts decaps: 438, #pkts decrypt: 438, #pkts verify: 438
    #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 64

     local crypto endpt.: 33.33.33.3, remote crypto endpt.: 0.0.0.0
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x501F7AB8(1344240312)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x501F7AB8(1344240312)
--------------------------------------------------------------------------------------------------------------------------

So there you have it- 2 cool vpn technologies combined - hope this is helpful and thanks for reading. Also, here's a few excellent references on DMVPN , GETVPN, and IPSEC\IKE\ISAKMP in general.

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/901-cisco-router-dmvpn-configuration.html

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/getvpn-solution-managed-services/prod_white_paper0900aecd804c363f.html



Also, here are the GNS3 Lab files- downloadable here:

Download Lab








No comments:

Post a Comment