Clonezilla for Disk Imaging and Cloning.

Posted: Saturday, September 6, 2014 by Unknown in Labels:
0

Clonezilla is a partition and disk imaging/cloning program similar to True Image® or Norton Ghost®. It helps you to do system deployment, bare metal backup and recovery. Two types of Clonezilla are available, Clonezilla live and Clonezilla SE (server edition). Clonezilla live is suitable for single machine backup and restore. While Clonezilla SE is for massive deployment, it can clone many (40 plus!) computers simultaneously. Clonezilla saves and restores only used blocks in the harddisk. This increases the clone efficiency. With some high-end hardware in a 42-node cluster, a multicast restoring at rate 8 GB/min was reported.

Features:
-Free (GPL) Software.
-Filesystem supported: (1) ext2, ext3, ext4, reiserfs, reiser4, xfs, jfs, btrfs of GNU/Linux, (2) FAT12, FAT16, FAT32, NTFS of MS Windows, (3) HFS+ of Mac OS, (4) UFS of FreeBSD, NetBSD, and OpenBSD, (5) minix of Minix, and (6) VMFS3 and VMFS5 of VMWare ESX. Therefore you can clone GNU/Linux, MS windows, Intel-based Mac OS, FreeBSD, NetBSD, OpenBSD, Minix and VMWare ESX, no matter it's 32-bit (x86) or 64-bit (x86-64) OS. For these file systems, only used blocks in partition are saved and restored. For unsupported file system, sector-to-sector copy is done by dd in Clonezilla.
-LVM2 (LVM version 1 is not) under GNU/Linux is supported.
-Boot loader, including grub (version 1 and version 2) and syslinux, could be reinstalled.
-Both MBR and GPT partition format of hard drive are supported. Clonezilla live also can be booted on a BIOS or uEFI machine.
-Unattended mode is supported. Almost all steps can be done via commands and options. You can also use a lot of boot parameters to customize your own imaging and cloning.
-One image restoring to multiple local devices is supported.
-Multicast is supported in Clonezilla SE, which is suitable for massively clone. You can also remotely use it to save or restore a bunch of computers if PXE and Wake-on-LAN are supported in your clients.
-The image file can be on local disk, ssh server, samba server, or NFS server.
-Based on Partclone (default), Partimage (optional), ntfsclone (optional), or dd to image or clone a partition. However, Clonezilla, containing some other programs, can save and restore not only partitions, but also a whole disk.
-By using another free software drbl-winroll, which is also developed by us, the hostname, group, and SID of cloned MS windows machine can be automatically changed.

Which Clonezilla Shall I Use ?

Clonezilla Live: Clonezilla live allows you to use CD/DVD or USB flash drive to boot and run clonezilla (Unicast only)
Clonezilla SE: Clonezilla SE is included in DRBL, therefore a DRBL server must first be set up in order to use Clonezilla to do massively clone (unicast, broadcast and multicast are supported)

Dynamic Virtual Tunnel Interface IPsec VPN.

Posted: Sunday, August 24, 2014 by Unknown in Labels:
0

Manually configuring site to site VPN using static virtual tunnel interfaces (VTI) can become out of control as the number of remote sites grows. If you want to set up full mesh connectivity you have to create static VTI interfaces on each peer to all the other peers in you network which is considered to be a big hassle that will cost you time and administrative overhead.

On the other hand, Dynamic VTI - AKA virtual access interfaces - comes as an easy way to connect to multiple VPN peers without the need of adding static VTI interfaces manually pointing to each peer. Using a virtual template on the hub you can dynamically generate virtual tunnel interfaces as needed to reach the VPN peers.

Another important aspect that you should be aware of if you decided to use DVTI VPN is that no directed spoke to spoke communication is possible in such environment simply because DVTI VPN does not use any kind of next hop resolution to reach the remote spokes so spokes cannot talk to each other without passing through the hub.

“In this scenario I will illustrate how to configure DVTI VPN on R1 as a hub to allow spoke to spoke communication between R2 and R3 "

DVTI VPN Hub Configuration: 
IPsec Protection Configuration.
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peers during the control channel setup.
R1(config)#crypto isakmp policy 1
R1(config-isakmp)# encr aes
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 5           

Key Ring Configuration.
-Create a key ring on the hub holding the pre shared keys to authenticate the spokes.
-Identify each peer with its public IP address and associate it with its key.
R1(config)#crypto keyring DVTI-VPN-KEYS
R1(conf-keyring)#  pre-shared-key address 192.168.1.2 key R2-KEY
R1(conf-keyring)#  pre-shared-key address 192.168.1.3 key R3-KEY          

ISAKMP Profile Configuration.
-The ISAKMP profile will authenticate the peers defined with the match statement against the key ring configured and will generate a virtual access interface from the virtual template defined if the peer has been authenticated successfully.
R1(config)#crypto isakmp profile ISAKMP-PROFILE
R1(conf-isa-prof)#   keyring DVTI-VPN-KEYS
R1(conf-isa-prof)#   match identity address 192.168.1.2 255.255.255.255
R1(conf-isa-prof)#   match identity address 192.168.1.3 255.255.255.255
R1(conf-isa-prof)#   virtual-template 1

IKE Phase Two / IPsec Configuration.
-Configure a transform set and define the security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2 / IPsec phase.
-Include the transform set into an IPsec profile as a prerequisite to apply it to the DVTI template as a protection profile.
R1(config)#crypto ipsec transform-set IPSEC-TS esp-aes
R1(cfg-crypto-trans)#crypto ipsec profile IPSEC-PROFILE
R1(ipsec-profile)# set transform-set IPSEC-TS 

Unnumbered Interface and Public Interface Configuration.
-Configure the public interface facing the internet that will be used to connect to the VPN peer and create a loopback interface to barrow its IP address by the tunnel interface. Using a loopback interface will result in independency on a specific physical interface.
R1(config-if)# interface loopback 1
R1(config-if)# ip address 192.168.20.1 255.255.255.255
R1(config-if)#interface FastEthernet0/0
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# no shut         

Dynamic Virtual Tunnel Interface (DVTI) template Configuration.
-Instead of creating two static tunnel interfaces to each peer, you need to configure a dynamic VTI template to generate the VTI dynamically from the template as virtual access interfaces.
-Set the tunnel unnumbered interface and the protocol version (IPV4/IPV6) and the IPsec protection profile.
Notice: We did not specify the tunnel source because the template will generate it dynamically as virtual access interfaces.
R1(config)#interface Virtual-Template1 type tunnel
R1(config-if)# ip unnumbered Loopback1
R1(config-if)# tunnel mode ipsec ipv4
R1(config-if)# tunnel protection ipsec profile IPSEC-PROFILE

Spoke One Configuration.
IPsec Protection Configuration.
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peer during the control channel setup.
-Configure the spoke key to match the key configured on the hub.
R2(config)#crypto isakmp policy 1
R2(config-isakmp)# encr aes
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 5
R2(config-isakmp)#crypto isakmp key R2-KEY address 192.168.1.1

IKE Phase Two / IPsec Configuration.
-Configure a transform set and define the security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2 / IPsec phase.
-Include the transform set into an IPsec profile as a prerequisite to apply it to the VTI tunnel interface as a protection profile.
R2(config)#crypto ipsec transform-set IPSEC-TS esp-aes
R2(cfg-crypto-trans)#crypto ipsec profile IPSEC-PROFILE
R2(ipsec-profile)# set transform-set IPSEC-TS

Unnumbered Interface and Public Interface Configuration.
-Configure the public interface facing the internet that will be used to connect to the VPN peer and create a loopback interface to barrow its IP address by the tunnel interface.
R2(config)#interface Loopback2
R2(config-if)# ip address 192.168.20.2 255.255.255.255
R2(config-if)#interface FastEthernet0/0
R2(config-if)# ip address 192.168.1.2 255.255.255.0
R2(config-if)#no shut

Virtual Tunnel Interface (VTI) Configuration.
-Assign the IP address of the loopback interface to the VTI tunnel interface using the unnumbered command.
-Configure the VTI tunnel source as the public interface that will be used to connect to the VPN peer and the tunnel destination will be the public interface on the peer.
-Set the tunnel mode to IPsec IP Version 4 to enable IPsec protection using IP version 4 and apply the IPsec protection profile to the VTI tunnel interface.
R2(config-if)#interface Tunnel2
R2(config-if)# ip unnumbered Loopback2
R2(config-if)# tunnel source FastEthernet0/0
R2(config-if)# tunnel destination 192.168.1.1
R2(config-if)# tunnel mode ipsec ipv4
R2(config-if)# tunnel protection ipsec profile IPSEC-PROFILE

Spoke Two Configuration.
IPsec Protection Configuration.
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peer during the control channel setup.
-Configure the spoke key to match the key configured on the hub.
R3(config)#crypto isakmp policy 1
R3(config-isakmp)# encr aes
R3(config-isakmp)# authentication pre-share
R3(config-isakmp)# group 5
R3(config-isakmp)#crypto isakmp key R3-KEY address 192.168.1.1

IKE Phase Two / IPsec Configuration.
-Configure a transform set and define the security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2 / IPsec phase.
-Include the transform set into an IPsec profile as a prerequisite to apply it to the VTI tunnel interface as a protection profile.
R3(config)#crypto ipsec transform-set IPSEC-TS esp-aes
R3(cfg-crypto-trans)#crypto ipsec profile IPSEC-PROFILE
R3(ipsec-profile)# set transform-set IPSEC-TS

Unnumbered Interface and Public Interface Configuration.
-Configure the public interface facing the internet that will be used to connect to the VPN peer and create a loopback interface to barrow its IP address by the tunnel interface.
R3(config)#interface Loopback3
R3(config-if)# ip address 192.168.20.3 255.255.255.255
R3(config-if)#interface FastEthernet0/0
R3(config-if)# ip address 192.168.1.3 255.255.255.0
R3(config-if)#no shut

Virtual Tunnel Interface (VTI) Configuration.
-Assign the IP address of the loopback interface to the VTI tunnel interface using the unnumbered command.
-Configure the VTI tunnel source as the public interface that will be used to connect to the VPN peer and the tunnel destination will be the public interface on the peer.
-Set the tunnel mode to IPsec IP Version 4 to enable IPsec protection using IP version 4 and apply the IPsec protection profile to the VTI tunnel interface.
R3(config-if)# ip unnumbered Loopback2
R3(config-if)# tunnel source FastEthernet0/0
R3(config-if)# tunnel destination 192.168.1.1
R3(config-if)# tunnel mode ipsec ipv4
R3(config-if)# tunnel protection ipsec profile IPSEC-PROFILE

Verification:
Verify the Virtual access interfaces.
-Use the “show ip interface brief“to verify that the dynamic VTI template generated virtual access interfaces to reach the VPN spokes also notice that the IP address of the virtual access interfaces will be the IP address of the unnumbered interface configured in the virtual template configuration mode.
R1#sh ip int brief
Interface                          IP-Address      OK? Method     Status                Protocol
FastEthernet0/0            192.168.1.1       YES NVRAM   up                       up
Virtual-Template1          192.168.20.1    YES TFTP        down                 down
Virtual-Access1               192.168.20.1    YES TFTP        up                      up
Virtual-Access2               192.168.20.1    YES TFTP       up                      up
Loopback1                        192.168.20.1    YES NVRAM  up                      up

Verify the IKE phase one SA.
-The DVTI hub will establish two IKE phase one channels with a single bidirectional security association (SA) channel.
R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                    src                   state                     conn-id slot status
192.168.1.1     192.168.1.3     QM_IDLE           1002      0   ACTIVE
192.168.1.1     192.168.1.2     QM_IDLE           1001      0   ACTIVE

IPv6 Crypto ISAKMP SA

Verify the IKE phase two SA.
-Use the “sh crypto engine connections active” command to show all the active security associations including IKE phase one and two security associations in addition to the VPN encrypted/decrypted traffic. You should see two IKE phase one security associations since we have only two spokes and four IPsec security associations or two bidirectional pairs of security associations to and from each spoke.
R1#sh crypto engine connections active
Crypto Engine Connections
   ID   Interface  Type  Algorithm           Encrypt  Decrypt   IP-Address
    1     Fa0/0       IPsec AES                              0        0             192.168.1.1
    2    Fa0/0       IPsec AES                              0        0              192.168.1.1
    3    Fa0/0       IPsec AES                              0        0              192.168.1.1
    4    Fa0/0       IPsec AES                              0        0              192.168.1.1
 1001 Fa0/0       IKE   SHA+AES                   0        0              192.168.1.1
 1002Fa0/0       IKE   SHA+AES                   0        0              192.168.1.1

IPsec Site to Site VPN Using VTI.

Posted: Thursday, August 14, 2014 by Unknown in Labels:
0

The best way to understand VTI-Based Site-to-Site VPN is to put it in comparison with the classic site to site IPsec VPN using crypto maps. Essentially much like the classic site to site IPsec crypto VPN that we all know and love, it uses IKE phase one as the control channel and IKE phase two as the data channel however no need to use a crypto ACL to define the IPsec traffic to encrypt.

You can setup a tunnel interface on each peer to connect the two sites together using a virtual tunnel and apply an IPsec profile to each tunnel interface so traffic going in or out the tunnel interface will be magically encrypted according to the security policy defined in the IPsec profile.

“In this scenario I will illustrate how to configure VTI-Based Site-to-Site VPN between R1 and R2 also you can download the configuration files from here”

R1 Configuration: 
IPsec Protection Configuration.
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peer during the control channel setup.
-Configure the IKE phase one key to authenticate R1 to R2.It is important to match the key configured on R2 otherwise you will break the security association.
R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encr aes
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 2
R1(config-isakmp)#crypto isakmp key CISCO address 192.168.1.2

IKE Phase Two / IPsec Configuration.
-Configure a transform set and define the security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2 / IPsec phase.
-Include the transform set into an IPsec profile as a prerequisite to apply it to the VTI tunnel interface as a protection profile.
R1(config)#crypto ipsec transform-set IPSEC-TRANSFORM-SET esp-aes
R1(cfg-crypto-trans)#crypto ipsec profile IPSEC-PROFILE
R1(ipsec-profile)#set transform-set IPSEC-TRANSFORM-SET

Unnumbered Interface and Public Interface Configuration.
-Configure the public interface facing the internet that will be used to connect to the VPN peer and create a loopback interface to barrow its IP address by the tunnel interface. Using a loop back interface will result in independence on a specific physical interface.
R1(config-if)#interface FastEthernet0/0
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shut
R1(config)#interface Loopback1
R1(config-if)#ip address 1.1.1.1 255.255.255.0

Virtual Tunnel Interface (VTI) Configuration.
-Assign the IP address of the loopback interface to the VTI tunnel interface using the unnumbered command.
-Configure the VTI tunnel source as the public interface that will be used to connect to the VPN peer and the tunnel destination will the public interface on that peer.
-Set the tunnel mode to IPsec IP Version 4 to enable IPsec protection using IP version 4 and apply the IPsec protection profile to the VTI tunnel interface.
R1(config-if)#interface Tunnel0
R1(config-if)#ip unnumbered Loopback1
R1(config-if)#tunnel source FastEthernet0/0
R1(config-if)#tunnel destination 192.168.1.2
R1(config-if)#tunnel mode ipsec ipv4
R1(config-if)#tunnel protection ipsec profile IPSEC-PROFILE

R2 Configuration:
“R2 configuration will be virtually identical to R1 especially the IKE phase 1 and 2 configuration “
IPsec Protection Configuration.
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peer during the control channel setup.
-Configure the IKE phase one key to authenticate R2 to R1.Again it is important to match the key configured on R1 otherwise you will break the security association.
R2(config)#crypto isakmp policy 1
R2(config-isakmp)#encr aes
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#group 2
R2(config-isakmp)#crypto isakmp key CISCO address 192.168.1.1 no-xauth

IKE Phase Two / IPsec Configuration. 
-Configure a transform set and define the security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2 / IPsec phase.
-Include the transform set into an IPsec profile as a prerequisite to apply it to the VTI tunnel interface as a protection profile.
R2(config)#crypto ipsec transform-set IPSEC-TRANSFORM-SET esp-aes
R2(cfg-crypto-trans)#crypto ipsec profile IPSEC-PROFILE
R2(ipsec-profile)#set transform-set IPSEC-TRANSFORM-SET

Unnumbered Interface and Public Interface Configuration.
-Configure the public interface facing the internet that will be used to connect to the VPN peer and create a loopback interface to barrow its IP address by the tunnel interface.
R2(config-if)#interface FastEthernet0/0
R2(config-if)#ip address 192.168.1.2 255.255.255.0
R2(config-if)#no shut
R2(ipsec-profile)#interface Loopback2
R2(config-if)#ip address 2.2.2.2 255.255.255.0

Virtual Tunnel Interface (VTI) Configuration. 
-Assign the IP address of the loopback interface to the VTI tunnel interface using the unnumbered command.
-Configure the VTI tunnel source as the public interface that will be used to connect to the VPN peer and the tunnel destination will be the public interface on the peer.
-Set the tunnel mode to IPsec IP Version 4 to enable IPsec protection using IP version 4 and apply the IPsec protection profile to the VTI tunnel interface.
R2(config-if)#interface Tunnel0
R2(config-if)#ip unnumbered Loopback2
R2(config-if)#tunnel source FastEthernet0/0
R2(config-if)#tunnel destination 192.168.1.1
R2(config-if)#tunnel mode ipsec ipv4
R2(config-if)#tunnel protection ipsec profile IPSEC-PROFILE

Verification:
Verify the IKE phase one SA.
-In general, the IKE phase one channel is a single bidirectional security association (SA) channel on contrast to the IPsec channel which is two unidirectional channels per security association (SA).
R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.1.1     192.168.1.2     QM_IDLE           1002 ACTIVE
IPv6 Crypto ISAKMP SA
 
R2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.1.1     192.168.1.2     QM_IDLE           1002 ACTIVE
IPv6 Crypto ISAKMP SA

Verify the IKE phase two SA.
-The “sh crypto engine connections active” command shows all the active security associations on each peer in addition to the VPN encrypted/decrypted traffic. You should see one IKE phase one security association and two IPsec security associations, one for encrypting the outgoing IPsec packets and another for decrypting the incoming IPsec packets.
R1#sh crypto engine connections active
Crypto Engine Connections
   ID   Type    Algorithm           Encrypt  Decrypt LastSeqN IP-Address
    3     IPsec   AES                       0       27        0 192.168.1.1
    4     IPsec   AES                      29        0        0 192.168.1.1
 1002 IKE     SHA+AES              0        0        0 192.168.1.1

R2#sh crypto engine connections active
Crypto Engine Connections
   ID  Type    Algorithm           Encrypt  Decrypt LastSeqN IP-Address
    3    IPsec   AES                       0       55        0 192.168.1.2
    4    IPsec   AES                      54        0        0 192.168.1.2
 1002 IKE     SHA+AES             0        0        0 192.168.1.2

IPsec Dynamic Multipoint VPN Configuration.

Posted: Sunday, August 10, 2014 by Unknown in Labels:
0

Dynamic Multipoint VPN (DMVPN) is a great way to set up full-mesh connectivity dynamically between VPN peers with simple configuration of hub and spoke design. In this article, I will explain to you the core pieces that make up DMVPNs, including Next Hop Resolution Protocol (NHRP), multipoint GRE tunnel interfaces, dynamic routing protocols, and more. The configuration of IPsec to protect the DMVPN tunnel also is included in this article.

DMVPN is combination of the following technologies:
Next-Hop Resolution Protocol (NHRP): Very similar to the Address Resolution Protocol (ARP), while ARP is responsible for the resolution of layer 3 IP addresses to layer 2 MAC addresses. NHRP is responsible for resolving the Non Broadcast Multi Access (NBMA) IP addresses to their corresponding tunnel IP address to form dynamic tunneling with VPN peers when recalled.

NHRP is a Client-Server protocol, usually the DMVPN hub will play the role of the NHRP Server (NHS) to perform the Tunnel IP address to NBMA IP address resolution process and the DMVPN spokes will register themselves to the NHS as NHRP clients with a mapping of their tunnel IP addresses to their NBMA IP addresses.

Multipoint GRE (mGRE) Tunnel Interfaces: Classic GRE tunnel is point-to-point, but mGRE generalizes this idea by allowing a tunnel to have “multiple” destinations. The destination IP address will be resolved from the mapping present in the NHRP table to setup on demand full mesh connectivity.

Dynamic Routing Protocol (EIGRP, RIP, OSPF, and BGP): Adding a routing protocol is necessary to advertise the remote networks to the VPN peers. The tunnel interface should has split horizon disabled to advertise routes received from the VPN spokes to other VPN spokes using the same interface also you need to configure the DMVPN hub to preserve the source IP address of the routes being advertised by disabling the next-hop-self feature.

Dynamic IPsec encryption: IPsec is not a required piece but recommended to add a layer of security to your environment. IPsec can be added to the DMVPN topology (and usually is) to provide encryption, authentication, and data integrity services for the packets traveling between the mGRE interfaces.

“Make the configuration process modular as possible. First, configure the mGRE tunnel followed by the NHRP protocol. Once you have the tunnel up verify the NHRP resolution then add a routing protocol to advertise remote networks and encrypt the DMVPN traffic using IPsec as the last step"

"You can download the topology used in this scenario and the configuration files from here”

DMVPN Hub Configuration.
mGRE tunnel interface configuration.
-Configure a tunnel interface and configure the tunnel IP address, the tunnel source NBMA interface and interface tunnel mode should be multipoint to allow multiple destinations using the same interface also it is recommended to secure the tunnel with a key that should be the same on all the peers participating in the DMVPN network.
DMVPN-HUB(config)#interface Tunnel 3                                                                    
DMVPN-HUB(config-if)#ip address 192.168.10.3 255.255.255.0
DMVPN-HUB(config-if)#tunnel source FastEthernet0/0
DMVPN-HUB(config-if)#tunnel mode gre multipoint
DMVPN-HUB(config-if)#tunnel key 1122

Next Hop Resolution Protocol ( NHRP ) Configuration.
-Configure DMVPN hub to learn the VPN tunnel IP-to-NBMA IP address mapping dynamically from the NHRP clients using multicast. This command sets the DMVPN-HUB as the NHS sever.
-Secure the NHRP network by configuring a network ID that should be the same on all the DMVPN peers also restrict the NHRP client registration to only clients authenticated using the “NHRP-KEY” authentication key.
-The “shortcut” and “redirect” commands will cause the NHS server to send a redirect message to the NHRP client containing the NBMA IP address of the destination it want to reach to be used as a shortcut path for future communication instead of passing through the DMVPN hub when sending subsequent packets.
DMVPN-HUB(config)#interface Tunnel 3
DMVPN-HUB(config-if)#ip nhrp map multicast dynamic
DMVPN-HUB(config-if)#ip nhrp authentication NHRP-KEY
DMVPN-HUB(config-if)#ip nhrp network-id 1
DMVPN-HUB(config-if)#ip nhrp shortcut
DMVPN-HUB(config-if)#ip nhrp redirect                                                      

Routing Protocol Configuration.
-Configure the EIGRP autonomous system number and the routes to advertise.
DMVPN-HUB(config)#router eigrp 1
DMVPN-HUB(config-router)#network 0.0.0.0

-In this scenario I will use EIGRP to advertise the remote networks, it is important to know that EIGRP as a hybrid protocol is very close to be a distance vector protocols and as a result of this it uses the same loop prevention mechanisms that distance vector protocols uses in particular the split horizon rule. Disable split horizon on the tunnel interface to advertise routes received from EIGRP neighbors to other EIGRP neighbors using the same interface.
-Also disable the “next-hop-self “feature to preserve the source IP address of the received EIGRP routes. If you didn’t disable this feature the DMVPN hub will change the source IP address of the advertised routes to its tunnel IP address and as a result of this the DMVPN spokes will use the DMVPN hub as a tandem hop to communicate with each other instead of communicating directly.
DMVPN-HUB(config)#interface Tunnel 3
DMVPN-HUB(config-if)#no ip split-horizon eigrp 1
DMVPN-HUB(config-if)#no ip next-hop-self eigrp 1                                

IPsec Protection Configuration:
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peers.
-Configure the IKE phase one keys of each peer. It is important to match the keys configured on the spokes otherwise you will break the security association.
DMVPN-HUB(config)#crypto isakmp policy 1
DMVPN-HUB(config-isakmp)#encr aes 256
DMVPN-HUB(config-isakmp)#authentication pre-share
DMVPN-HUB(config-isakmp)#group 5
DMVPN-HUB(config)#crypto isakmp key R1-ISAKMP-KEY address 192.168.1.1
DMVPN-HUB(config)#crypto isakmp key R2-ISAKMP-KEY address 192.168.1.2

IKE Phase Two / IPsec Configuration.
-Configure a transform set and define the security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2 / IPsec phase.
-Nest the transform set into an IPsec profile as a prerequisite to apply it to the tunnel interface as a protection profile.
DMVPN-HUB(config)#crypto ipsec transform-set IPSEC-Transform-Set esp-aes
DMVPN-HUB(cfg-crypto-trans)#crypto ipsec profile IPSE-Profile
DMVPN-HUB(ipsec-profile)#set transform-set IPSEC-Transform-Set

Apply the IPsec profile to the tunnel interface
-In the tunnel configuration mode, enable IPsec protection using the security parameters configured in IPsec Profile.
DMVPN-HUB(config)#interface Tunnel 3           
DMVPN-HUB(config-if)#tunnel protection ipsec profile IPSE-Profile

DMVPN Spoke Configuration(DMVPN-SPOKE-1).
mGRE tunnel interface configuration.
-Very similar to the DMVPN hub tunnel interface configuration. Configure a tunnel interface and configure the tunnel IP address, the tunnel source NBMA interface and interface tunnel mode should be multipoint to allow multiple destinations using the same interface also it is recommended to secure the tunnel with a key that should be the same on all the peers participating in the DMVPN network.
Note: The source of the tunnel interface is identified by the NBMA interface name not the IP address. This allows dynamic addressing on the NBMA interface without interrupting the tunnel operation after IP address changes.
DMVPN-SPOKE-1(config-if)#tunnel source FastEthernet0/0
DMVPN-SPOKE-1(config-if)#tunnel mode gre multipoint
DMVPN-SPOKE-1(config-if)#tunnel key 1122

NHRP Configuration.
-Configure DMVPN spoke to register with the NHS using its tunnel IP address and since the NHRP client cannot reach the NHS server directly using its tunnel IP address you need to create a static NHRP map to resolve the NHS tunnel IP Address to the NBMA IP address.
-Configure the NHRP client to send any multicast traffic to the NHS server.
-Configure the network ID and the authentication key to match configuration on the NHS server.
-Enable shortcut on all the NHRP clients to use the shortcut path received from the NHS server.
DMVPN-SPOKE-1(config)#interface Tunnel 1
DMVPN-SPOKE-1(config-if)#ip nhrp nhs 192.168.10.3
DMVPN-SPOKE-1(config-if)#ip nhrp map 192.168.10.3 192.168.1.3
DMVPN-SPOKE-1(config-if)#ip nhrp map multicast 192.168.1.3
DMVPN-SPOKE-1(config-if)#ip nhrp authentication NHRP-KEY
DMVPN-SPOKE-1(config-if)#ip nhrp network-id 1
DMVPN-SPOKE-1(config-if)#ip nhrp shortcut

Routing Protocol Configuration.
-Configure the EIGRP autonomous system number to match the number configured on the DMVPN hub to establish a neighborship and the routes to advertise.
DMVPN-SPOKE-1(config)#router eigrp 1                   
DMVPN-SPOKE-1(config-router)#network 0.0.0.0

IPsec Configuration:
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peers.
-Configure the IKE phase 1 keys of each peer. It is important to match the keys configured on the DMVPN hub and spokes.
DMVPN-SPOKE-1(config)#crypto isakmp policy 1
DMVPN-SPOKE-1(config-isakmp)#encr aes 256
DMVPN-SPOKE-1(config-isakmp)#authentication pre-share
DMVPN-SPOKE-1(config-isakmp)#group 5
DMVPN-SPOKE-1(config-isakmp)#exit
DMVPN-SPOKE-1(config)#crypto isakmp key R3-ISAKMP-KEY address 192.168.1.3
DMVPN-SPOKE-1(config)#crypto isakmp key R2-ISAKMP-KEY address 192.168.1.2

IKE Phase Two / IPsec Configuration.
-Configure a transform set and define then security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2/ IPsec phase.
-Nest the transform set into an IPsec profile as a prerequisite to apply it to the tunnel interface as a protection profile as we did before on the DMVPN hub.
DMVPN-SPOKE-1(config)#crypto ipsec transform-set IPSEC-Transform-Set esp-aes
DMVPN-SPOKE-1(cfg-crypto-trans)#crypto ipsec profile IPSE-Profile
DMVPN-SPOKE-1(ipsec-profile)#set transform-set IPSEC-Transform-Set

Apply the IPsec profile to the tunnel interface
-In the tunnel configuration mode, enable IPsec protection using the security parameters configured in IPsec Profile.
DMVPN-SPOKE-1(config)#interface Tunnel 1               
DMVPN-SPOKE-1(config-if)#tunnel protection ipsec profile IPSE-Profile

DMVPN Spoke Configuration(DMVPN-SPOKE-2).
mGRE tunnel interface configuration.
-The configuration of DMVPN-SPOKE-2 will be virtually identical to the DMVPN-SPOKE-1 configuration. Configure a tunnel interface and configure the tunnel IP address, the tunnel source NBMA interface and interface tunnel mode should be multipoint to allow multiple destinations using the same interface also it is recommended to secure the tunnel with a key that should be the same on all the peers participating in the DMVPN network.
DMVPN-SPOKE-1(config)#interface Tunnel 2
DMVPN-SPOKE-1(config-if)# ip address 192.168.10.2 255.255.255.0
DMVPN-SPOKE-1(config-if)#tunnel source FastEthernet0/0
DMVPN-SPOKE-1(config-if)#tunnel mode gre multipoint
DMVPN-SPOKE-1(config-if)#tunnel key 1122

NHRP Configuration.
-Configure DMVPN spoke to register with the NHS using its tunnel IP address and since the NHRP client cannot reach the NHS server directly using its tunnel IP address you need to create a static NHRP map to resolve the NHS tunnel IP Address to the NBMA IP address.
-Configure the NHRP client to send any multicast traffic to the NHS server.
-Configure the network ID and the authentication key to match configuration on the NHS server.
-Enable shortcut on all the NHRP clients to use the shortcut path received from the NHS server.
DMVPN-SPOKE-2(config)#interface tunnel 2
DMVPN-SPOKE-2(config-if)#ip nhrp nhs 192.168.10.3
DMVPN-SPOKE-2(config-if)#ip nhrp map 192.168.10.3 192.168.1.3
DMVPN-SPOKE-2(config-if)#ip nhrp map multicast 192.168.1.3
DMVPN-SPOKE-2(config-if)#ip nhrp authentication NHRP-KEY
DMVPN-SPOKE-2(config-if)#ip nhrp network-id 1
DMVPN-SPOKE-2(config-if)#ip nhrp shortcut

Routing Protocol Configuration.
-Configure the EIGRP autonomous system number to match the number configure on the DMVPN hub and spokes to establish a neighborship and the routes to advertise.
DMVPN-SPOKE-2(config)#router eigrp 1                      
DMVPN-SPOKE-2(config-router)#network 0.0.0.0

IPsec Configuration:
IKE Phase One / Internet Security and Key Management Protocol (ISAKMP) Configuration.
-Create an IKE phase 1 policy and define the encryption, authentication and Diffie-Hellman group to negotiate a security association with the VPN peers.
-Configure the IKE phase 1 keys of each peer. It is important to match the keys configured on the hub and spokes.
DMVPN-SPOKE-2(config)#crypto isakmp policy 1
DMVPN-SPOKE-2(config-isakmp)# encr aes 256
DMVPN-SPOKE-2(config-isakmp)# authentication pre-share
DMVPN-SPOKE-2(config-isakmp)# group 5
DMVPN-SPOKE-2(config-isakmp)#exit
DMVPN-SPOKE-2(config)#crypto isakmp key R3-ISAKMP-KEY address 192.168.1.3
DMVPN-SPOKE-2(config)#crypto isakmp key R1-ISAKMP-KEY address 192.168.1.1

IKE Phase Two /IPsec Configuration.
-Configure a transform set and define then security parameters to negotiate a security association to be used for data encryption and integrity during IKE phase 2/IPsec phase.
-Nest the transform set into an IPsec profile as a prerequisite to apply it to the tunnel interface as a protection profile.
DMVPN-SPOKE-2(config)#crypto ipsec transform-set IPSEC-Transform-Set esp-aes
DMVPN-SPOKE-2(cfg-crypto-trans)#crypto ipsec profile IPSE-Profile
DMVPN-SPOKE-2(ipsec-profile)#set transform-set IPSEC-Transform-Set

Apply the IPsec profile to the tunnel interface
-In the tunnel configuration mode, enable IPsec protection using the security parameters configured in IPsec Profile.
DMVPN-SPOKE-2(config)#interface Tunnel 2
DMVPN-SPOKE-2(config-if)#tunnel protection ipsec profile IPSE-Profile

Verification:
Tunnel status Verification.
-Use the “Show ip interface brief” to verify that the tunnel interface up and also verify the status of the NBMA interface used as the tunnel source.
DMVPN-HUB#sh ip interface brief
Interface                    IP-Address       OK?  Method     Status                Protocol
FastEthernet0/0         192.168.1.3       YES  NVRAM  up                      up
Tunnel3                        192.168.10.3     YES  NVRAM  up                      up

Next Hop Resolution Protocol (NHRP) Verification:
NHRP Verification on the NHS Server.
-If the NHRP clients have registered successfully with the NHS server, you should see their tunnel IP address to NBMA IP address mappings dynamically learned by the NHS server.
DMVPN-HUB#sh ip nhrp brief                                        
Target                      Via                    NBMA            Mode     Intfc   Claimed
192.168.10.1/32      192.168.10.1    192.168.1.1     dynamic  Tu3     <   >
192.168.10.2/32      192.168.10.2    192.168.1.2     dynamic  Tu3     <   >

NHRP Verification on the NHRP Clients.
-The same command on the NHS server but different output. Notice that on the NHRP client a static mapping to reach the NHS server will be used by the clients for registration and the dynamic destinations the NHS server has resolved.
DMVPN-SPOKE-1#sh ip nhrp brief                      
Target                      Via                    NBMA            Mode     Intfc   Claimed
192.168.10.1/32      192.168.10.1    192.168.1.1     dynamic  Tu1     <   >
192.168.10.2/32      192.168.10.2    192.168.1.2     dynamic  Tu1     <   >
192.168.10.3/32      192.168.10.3    192.168.1.3     static       Tu1     <   >

DMVPN-SPOKE-2#sh ip nhrp brief
   Target             Via            NBMA           Mode   Intfc   Claimed
192.168.10.1/32      192.168.10.1    192.168.1.1     dynamic  Tu2     <   >
192.168.10.2/32      192.168.10.2    192.168.1.2     dynamic  Tu2     <   >
192.168.10.3/32      192.168.10.3    192.168.1.3     static   Tu2     <   >

DMVPN Verification:
DMVPN Verification on the hub.
-Use the “Show dmvpn” command to list the active DMVPN tunnels.Two tunnels on the DMVPN hub one to each spoke learned via the NHRP client registration.
DMVPN-HUB#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
=================================================================

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

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1    192.168.1.1          192.168.10.1       UP     00:19:55     D
     1    192.168.1.2          192.168.10.2       UP     00:19:50     D

DMVPN Verification on the Spokes.
-The same command on the DMVPN Hub but different output. There is a static mapping on each spoke pointing to the DMVPN Hub in addition to the dynamically learned mappings.
Notice:On DMVPN-SPOKE-1 a dynamic mapping has been resolved by the DMVPN hub to DMVPN-SPOKE-2 and vice verse on DMVPN-SPOKE2. 
DMVPN-SPOKE-1#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
=================================================================

Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,

 # Ent  Peer NBMA Addr  Peer Tunnel Add  State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1    192.168.1.2           192.168.10.2        UP     00:08:35     D
     1    192.168.1.3           192.168.10.3        UP     00:22:09     S

DMVPN-SPOKE-2#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
=================================================================

Interface: Tunnel2, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,

 # Ent  Peer NBMA Addr    Peer Tunnel Add    State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.1.1                192.168.10.1         UP     00:09:53     D
     1 192.168.1.3                192.168.10.3         UP     00:23:21     S

IKE Phase One / ISAKMP Verification.
-Use the “Show crypto isakmp sa” command on the DMVPN hub to list the IKE phase 1 security associations (SA) negotiated with the DMVPN spokes.
DMVPN-HUB#sh crypto isakmp sa
DMVPN-HUB#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                    src                   state                     conn-id  status
192.168.1.3     192.168.1.2     QM_IDLE           1002     ACTIVE
192.168.1.3     192.168.1.1     QM_IDLE           1001     ACTIVE

IPv6 Crypto ISAKMP SA            
-The same command on the hub but different output.
DMVPN-SPOKE-1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                    src                   state                     conn-id  status
192.168.1.1     192.168.1.2     QM_IDLE           1002     ACTIVE
192.168.1.2     192.168.1.1     QM_IDLE           1003     ACTIVE
192.168.1.3     192.168.1.1     QM_IDLE           1001     ACTIVE
                                                          
IPv6 Crypto ISAKMP SA

DMVPN-SPOKE-2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst                    src                   state                     conn-id  status
192.168.1.1     192.168.1.2     QM_IDLE           1002     ACTIVE
192.168.1.2     192.168.1.1     QM_IDLE           1003     ACTIVE
192.168.1.3     192.168.1.2     QM_IDLE           1001     ACTIVE

IPv6 Crypto ISAKMP SA

IKE Phase Two/ IPsec Verification
-Use the “Show crypto ipsec sa” command on the hub and spokes to verify the incoming and outgaining IPsec tunnels used for data protection in addition to the number of IPsec packets that have been sent and received to and from each peer.

-By executing the command on the DMVPN hub we can see two peers (DMVPN-SPOKE-1 and DMVPN-SPOKE-2) on the same tunnel interface and two IPsec channels for each peer one for incoming traffic and a second for outgoing traffic.
DMVPN-HUB#sh crypto ipsec sa

interface: Tunnel3
    Crypto map tag: Tunnel3-head-0, local addr 192.168.1.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.3/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.1.2/255.255.255.255/47/0)
   current_peer 192.168.1.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 435, #pkts encrypt: 435, #pkts digest: 435
    #pkts decaps: 440, #pkts decrypt: 440, #pkts verify: 440
    #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

     local crypto endpt.: 192.168.1.3, remote crypto endpt.: 192.168.1.2
     path mtu 1500, ip mtu 1500, ip mtu idb (none)
     current outbound spi: 0x40CFEDF(67960543)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x13D4D63D(332715581)
        transform: esp-aes ,
        in use settings ={Tunnel, }
        conn id: 3, flow_id: 3, sibling_flags 80000040, crypto map: Tunnel3-head-0
        sa timing: remaining key lifetime (k/sec): (4270510/1666)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)
      spi: 0x3052AE7(50670311)
        transform: esp-aes ,
        in use settings ={Tunnel, }
        conn id: 5, flow_id: 5, sibling_flags 80000040, crypto map: Tunnel3-head-0
        sa timing: remaining key lifetime (k/sec): (4314821/1666)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x60F27B46(1626504006)
        transform: esp-aes ,
        in use settings ={Tunnel, }
        conn id: 4, flow_id: 4, sibling_flags 80000040, crypto map: Tunnel3-head-0
        sa timing: remaining key lifetime (k/sec): (4270510/1666)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)
      spi: 0x40CFEDF(67960543)
        transform: esp-aes ,
        in use settings ={Tunnel, }
        conn id: 6, flow_id: 6, sibling_flags 80000040, crypto map: Tunnel3-head-0
        sa timing: remaining key lifetime (k/sec): (4314821/1666)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.3/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.1.1/255.255.255.255/47/0)
   current_peer 192.168.1.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 440, #pkts encrypt: 440, #pkts digest: 440
    #pkts decaps: 440, #pkts decrypt: 440, #pkts verify: 440
    #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

     local crypto endpt.: 192.168.1.3, remote crypto endpt.: 192.168.1.1
     path mtu 1500, ip mtu 1500, ip mtu idb (none)
     current outbound spi: 0x691AD4EE(1763366126)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x27537935(659781941)
        transform: esp-aes ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: 1, sibling_flags 80000040, crypto map: Tunnel3-head-0
        sa timing: remaining key lifetime (k/sec): (4344661/1659)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x691AD4EE(1763366126)
        transform: esp-aes ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: 2, sibling_flags 80000040, crypto map: Tunnel3-head-0
        sa timing: remaining key lifetime (k/sec): (4344660/1659)
        IV size: 16 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:


Summary: Forgive me! This is probably one of the longest articles on my blog but now you see how all the component of DMVPN work together including mGRE tunnel interfaces, NHRP and IPsec. We have not covered some other major topics like DMVPN redundancy with multiple hubs and NAT traversal with NHRP. Those advanced topics probably require a separate post, since this one has grown too big already.