Cisco DMVPN can be used to encrypt traffic between the organization and numerous partner sites, guaranteeing network segmentation by preventing spoke-to-spoke transmission even through the hub.
What is Dynamic Multipoint - VPN?
DMVPN or Dynamic Multipoint VPN is a Cisco solution that provides site-to-site VPN tunnels over the public WAN. It allows two different branch locations to communicate with each other over a secure tunnel. DMVPN provides scalable VPNs that are easy to implement and manage.
DMVPN works in combination with generic routing encapsulation (GRE) for tunneling, IPsec to provide a secure overlay network, and Next Hop Resolution Protocol (NHRP).
As we know multipoint GRE over IPsec works fine for fewer sites however the number of VPN gateways increases the more challenges and configurations will be required.
We'll go through each component's purpose and function in-depth, assuming the reader has a general concept of what DMVPN is and a solid knowledge of IPsec/CEF. In this post, we'll go over three stages of DMVPN evolution.
1) Hub and Spoke Phase 1 (mGRE hub, p2p GRE spokes)
2) Hub and Spoke with Spoke-to-Spoke tunnels (Phase 2) (mGRE everywhere)
A separate post will be necessary to cover DMVPN Phase 3. This is due to major modifications to NHRP resolution logic (NHRP redirects and shortcuts), which are better shown when the prior two stages are well understood. However, there will be some hints concerning Phase 3 in this post.
GRE Multipoint
Let's start with the most fundamental DMVPN construction block: the multipoint GRE tunnel. GRE tunnels are typically point-to-point, however, mGRE expands on this concept by allowing tunnels to have many destinations.
This may appear reasonable if the tunnel destination address is multicast. The tunnel might be used to successfully transport the same information (for example, a video stream) to various locations on top of a multicast-enabled network.
In fact, Cisco IOS uses mGRE for Multicast VPN implementation in this way. If tunnel endpoints need to exchange unicast packets, a specific glue is needed to map tunnel IP addresses to endpoint routers' physical or real IP addresses. As we'll see later, this adhesive is known as NHRP.
It's worth noting that if you source multiple mGRE tunnels from the same interface (for example, Loopback0) of a single router, GRE can use a special "multiplexor" field in the tunnel header to distinguish them.
This is known as the "tunnel key," and it can be defined under tunnel configuration. In fact, until IOS 12.3(14)T or 12.3(11)T3, the use of a "tunnel key" was required – the mGRE tunnel would not start until the key was configured. You can configure a tunnel without the key since the aforementioned versions.
Also Read: MPLS + MPLS VPN Configuration Step By Step
Next Hop Resolution Protocol (NHRP)
Now, let's get to the part of DMVPN that truly makes it dynamic - NHRP. RFC 2332 defined the protocol quite some time ago to create a routing optimization scheme within NBMA (non-broadcast multiple access) networks such as ATM, Frame-Relay, and SMDS. The general idea was to use SVC (switched virtual circuits) to create temporary shortcuts in the NBMA cloud that were not fully meshed. NHRP performs a similar function to ARP in that it resolves L3 to L2 addresses, but it does so in a more efficient manner, making it suitable for partially meshed NBMA clouds that support dynamic layer 2 connections.
Next Hop Resolution Protocol (NHRP) Phase 1
NHRP Phase 1 is used by mGRE to notify the hub of dynamically appearing spokes. Initially, you configure each spoke with the hub's IP address as the NHS server. The spoke's tunnel mode, on the other hand, is a GRE (regular point-to-point) tunnel with a fixed destination IP that equals the physical address of the hub.
The spokes can only connect to the hub and other spoke networks across the hub. The advantage of Phase 1 is that it simplifies hub router configuration by eliminating the need for static NHRP mapping for each new spoke.
Because all packets pass through the hub, almost any dynamic routing protocol would aid in achieving reachability. The hub only needs to advertise a default route to the spokes, while the spokes should dynamically advertise their subnets to the hub.
It's probably a good idea to run EIGRP on the hub and summarise all subnets to 0.0.0.0/0, effectively sending a default route to all spokes (if the spokes do not use any other default route, e.g. from their ISPs). Configure spokes as EIGRP stubs and advertise the networks to which they are connected. RIP could be configured in a similar way by simply configuring GRE tunnels on spokes as passive interfaces.
Split-horizon must be disabled on the hub mGRE interface for EIGRP and RIP to exchange subnets from spoke to spoke. The point-to-multipoint network type should be used on all GRE and mGRE interfaces in OSPF. Configure the hub to use IP OSPF database filter-all out, as well as static default routes via spoke tunnel interfaces or static specific routes for corporate networks.
DMVPN Configuration - Phase 1, 2, 3
A DMVPN is powered by VPN routers and firewall concentrators. The spokes do not use a permanent VPN connection; instead, they communicate via a centralized hub-and-spoke model that can implement VPN protection and granular access controls as needed. DMVPN also supports IPsec encryption.
DMVPN is a point-to-multipoint Layer 3 overlay VPN that allows direct spoke-to-spoke communications, depending on the DMVPN design (Phase 1, Phase 2, or Phase 3).
Integrating IPsec with DMVPN
Isn't there something we've forgotten about DMVPN Phase 1/Phase 2? That is IPsec, one of the components that ensure the confidentiality and integrity of mGRE/NHRP. In comparison to the complexity of NHRP operations, IPsec integration is now simple.
First, the hub must understand how to use IKE to authenticate all of the spokes. The most scalable method is to use X.509 certificates and PKI, but for the sake of simplicity, we will simply use the same pre-shared key across all routers.
To accept IKE negotiation requests from any other dynamic peer, we must configure the routers with a wild-card pre-shared key.
Because the hub has no idea what the IP addresses of the connecting peers are, we need dynamic crypto maps in IPsec Phase 2. Fortunately, Cisco IOS includes a cute feature called IPsec profiles, which is intended for use with tunnel interfaces. The profile connects to a tunnel interface and automatically considers all traffic leaving the tunnel to be IPsec Phase 2 traffic.
The IPsec profile's IPsec phase proxy identities are the tunnel's source and destination host IP addresses. Because mGRE already provides tunnel encapsulation, it makes sense to use IPSec transport mode with it. Furthermore, IOS only supports some features, such as NAT traversal with IPSec transport mode.
Configuration -
In this configuration, I have used 7200 series routers. So let's begin configuration. I have made this diagram using GNS3. Before configuring dmvpn, all routers should interact with one another. IP OSPF 1 area o is used in this configuration.
Router 5-
interface FastEthernet0/0
ip address 172.16.1.4 255.255.255.0
ip ospf 1 area 0
interface FastEthernet2/0
ip address 172.16.31.4 255.255.255.0
ip ospf 1 area 0
interface FastEthernet3/0
ip address 172.16.41.4 255.255.255.0
ip ospf 1 area 0
Hub Configuration (R4):-
HUB#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.7.7.7 YES NVRAM up up
FastEthernet2/0 172.16.1.7 YES NVRAM up up
HUB#conf t
HUB(config)#interface f2/0
HUB(config-if)#ip ospf 1 area 0
HUB(config-if)#exit
Tunnel Configuration
HUB#conf t
HUB(config)#interface tunnel 100
HUB(config-if)#ip address 192.168.1.1 255.255.255.0
HUB(config-if)#no ip redirects
HUB(config-if)#no ip split-horizon eigrp 1
HUB(config-if)#ip nhrp authentication cisco
HUB(config-if)#ip nhrp network-id 1
HUB(config-if)#ip nhrp map multicast dynamic
HUB(config-if)#tunnel source f2/0
HUB(config-if)#tunnel mode gre multipoint
HUB(config-if)#router eigrp 1
HUB(config-router)#network 10.7.7.7 0.0.0.0
HUB(config-router)#network 192.168.1.0 0.0.0.255
HUB(config-router)#do show ip nhrp
192.168.1.2/32 via 192.168.1.2
Tunnel100 created 00:00:50, expire 01:59:10
Type: dynamic, Flags: unique registered used
NBMA address: 172.16.31.6
HUB#trace 10.5.5.5
Type escape sequence to abort.
Tracing the route to 10.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.3 368 msec 472 msec 500 msec
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: Tunnel100, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.31.6 192.168.1.2 UP 00:14:25 D
1 172.16.41.5 192.168.1.3 UP 00:03:33 D
SPOKE1-
interface FastEthernet0/0
ip address 10.6.6.6 255.255.255.0
!
interface FastEthernet2/0
ip address 172.16.31.6 255.255.255.0
ip ospf 1 area 0
interface Tunnel100
ip address 192.168.1.2 255.255.255.0
ip nhrp authentication cisco
ip nhrp map multicast 172.16.1.7
ip nhrp map 192.168.1.1 172.16.1.7
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
tunnel source FastEthernet2/0
tunnel destination 172.16.1.7
router eigrp 1
network 10.6.6.6 0.0.0.0
network 192.168.1.0
SPOKE2-
interface FastEthernet2/0
ip address 172.16.41.5 255.255.255.0
ip ospf 1 area 0
!
interface FastEthernet3/0
ip address 10.5.5.5 255.255.255.0
interface Tunnel100
ip address 192.168.1.3 255.255.255.0
ip nhrp authentication cisco
ip nhrp map multicast 172.16.1.7
ip nhrp map 192.168.1.1 172.16.1.7
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
tunnel source FastEthernet2/0
tunnel destination 172.16.1.7
router eigrp 1
network 10.5.5.5 0.0.0.0
network 192.168.1.0
Useful commands;-
show dmvpn
show dmvpn detail
show ip nhrp
show ip nhrp brief
---------------------------------------------Phase 3-----------------------------------------------------------
Tunnel Configuration
HUB#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.7.7.7 YES NVRAM up up
FastEthernet2/0 172.16.1.7 YES NVRAM up up
HUB#conf t
HUB(config)#interface f2/0
HUB(config-if)#ip ospf 1 area 0
HUB(config-if)#exit
HUB#conf t
HUB(config)#interface tunnel 100
HUB(config-if)#ip address 192.168.1.1 255.255.255.0
HUB(config-if)#ip nhrp redirect
HUB(config-if)#no ip split-horizon eigrp 1
HUB(config-if)#ip nhrp authentication cisco
HUB(config-if)#ip nhrp network-id 1
HUB(config-if)#ip nhrp map multicast dynamic
HUB(config-if)#tunnel source f2/0
HUB(config-if)#tunnel mode gre multipoint
HUB(config-if)#router eigrp 1
HUB(config-router)#network 10.7.7.7 0.0.0.0
HUB(config-router)#network 192.168.1.0 0.0.0.255
SPOKE1-
interface FastEthernet0/0
ip address 10.6.6.6 255.255.255.0
!
interface FastEthernet2/0
ip address 172.16.31.6 255.255.255.0
ip ospf 1 area 0
interface Tunnel100
ip address 192.168.1.2 255.255.255.0
ip nhrp authentication cisco
ip nhrp map multicast 172.16.1.7
ip nhrp map 192.168.1.1 172.16.1.7
ip nhrp network-id 1
ip nhrp shortcut
ip nhrp nhs 192.168.1.1
tunnel source FastEthernet2/0
tunnel destination 172.16.1.7
router eigrp 1
network 10.6.6.6 0.0.0.0
network 192.168.1.0
SPOKE2-
interface FastEthernet2/0
ip address 172.16.41.5 255.255.255.0
ip ospf 1 area 0
!
interface FastEthernet3/0
ip address 10.5.5.5 255.255.255.0
interface Tunnel100
ip address 192.168.1.3 255.255.255.0
ip nhrp authentication cisco
ip nhrp map multicast 172.16.1.7
ip nhrp map 192.168.1.1 172.16.1.7
ip nhrp network-id 1
ip nhrp shortcut
ip nhrp nhs 192.168.1.1
tunnel source FastEthernet2/0
tunnel destination 172.16.1.7
router eigrp 1
network 10.5.5.5 0.0.0.0
network 192.168.1.0
FAQs: Dynamic Multipoint-VPN
Q: What is the distinction between SSL VPN and remote access VPN?
Ans: An IPsec VPN allows connections between an authorized remote host and any system inside the enterprise perimeter, whereas an SSL VPN allows connections only between approved remote hosts and particular services available within the enterprise perimeter.
Q: SSL or VPN, which is more secure?
Ans: When a user logs into the network, SSL takes the lead in terms of security. SSL VPNs operate by gaining access to certain apps, but IPsec users are treated as full network members. As a result, SSL makes it easy to restrict user access.
Q: Is DMVPN only available from Cisco?
Ans: This is a Cisco-only protocol. You may simply scale your company network using the Dynamic Multipoint Virtual Point Network functionality. DMVPN with IPSec is used by even tiny businesses.
In this post "Dynamic Multipoint-VPN - Definition and Practical Guide", if you have any queries or suggestions please feel free to write. Thank You.
![The Best Antivirus Apps For Android - [2023]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3Yjm36h1U18dmYifXs9XZCUy6ch_XK0XOXf8hVW4zcVUDW0OiVXQZT0Sr77Yjep1CUOHP3OqlrMIzRJLYasizRmQUilnXjozbQ8D0iroUBbeFEUD2MwaJdGuE4RJaqrfVHFX-_OoIhOyPr_K10ky6goZUJtdqUWIOkCibIoNylnXXzR-AksQYPTQ0/s72-w640-c-h388/antivirus-android-2023.png "The Best Antivirus Apps For Android - [2023]")
![How to Recover Corrupted Word File? - [2022]](https://1.bp.blogspot.com/-XfGhwLbUEiM/X3o72BSHTQI/AAAAAAAACWU/m10JE0WcVO4qrss6DD6-Mfq5_aE4QVS4wCLcBGAsYHQ/s72-w640-c-h430/Data%2BRecovery%2BSoftware.PNG "How to Recover Corrupted Word File? - [2022]")
0 Comments: