- “Do I Know This Already?” Quiz
- Foundation Topics
- DMVPN Overview
- DVMPN Network Components
- DMVPN Design Considerations
- DMVPN Phase 1 Hub-and-Spoke Implementation
- DMVPN Phase 2 Spoke-to-Spoke Implementation
- DMVPN Phase 3 Spoke-to-Spoke Implementation
- DMVPN Troubleshooting
- Summary
- References
- Exam Preparation Tasks
- Review All Key Topics
- Complete Tables and Lists from Memory
- Define Key Terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
DMVPN Overview
Many companies use DMVPN for their wide area network connectivity for one primary reason: It enables remote sites to have dynamic Internet addressing and yet still access corporate data in a cryptographically secure manner. With legacy VPN solutions, companies had to order static IP addresses at each remote site, thereby incurring an extra charge from the ISP and adding to the overall cost of the solution. Furthermore, as you added remote sites to such a solution, the hub router configuration grew exponentially. The days of configuring crypto maps, access control lists (ACLs), policies, and generic routing encapsulation (GRE) tunnels for each remote site have been replaced by the use of more mature and flexible VPN solutions. DMVPN specifically resolved the issues of static routing and cumbersome configuration with the use of an IPsec profile. In the legacy VPN configurations shown in Chapter 3, “Site-to-Site VPNs,” you had to configure one crypto map with multiple policies, each with its own ACL, to indicate which traffic was permitted to go to which destination through the tunnel and what transform set would be used for the traffic. Each time you added another site-to-site VPN, you added to the policy and, potentially, to the non-NAT ACL.
Legacy Crypto Map VPN Solutions
Figure 5-1 shows an example of a legacy crypto map VPN tunnel solution. This solution requires specific configuration for each site; DMVPN does not require this much configuration. In addition, the legacy solution does not support spoke-to-spoke communication, whereas DMVPN does.
)
Figure 5-1 Legacy VPN Tunnels
Modern VPN Needs
As shown in Figure 5-2, companies today are using VPNs for a variety of services. In this diagram you can see a mobile user who may be using a video conferencing software package on a laptop in order to communicate. In addition, you can see a remote office that might have multiple users who all have VoIP phones behind the main router; they might need to be able to use the DMVPN solution for not only data but voice and video conferencing. We could expand this diagram by adding another remote office on the DMVPN network, and users from one office would be able to call users in another office by using VoIP rather than traditional dedicated phone circuits from the local provider.
){kind=link}
Figure 5-2 A Telecommuter and a Remote Office with VoIP
DMVPN Risks
Although DMVPN provides secure connectivity, it does not make you immune to attacks. Simply adding remote sites to a corporate network increases your organization’s security risk. For example, if a teleworker’s remote machine is infected with ransomware, it might be possible for that ransomware to find other clients to infect through the network. In a fully meshed DMVPN solution, such an attack could cripple an organization’s capability to run its business (see Figure 5-3). So, as you are building out a VPN security solution, you should consider best practices for restricting, monitoring, and policing VPN traffic. Some examples of best practices would be to establish east–west access control and to monitor communications using traffic capture or NetFlow. In terms of packet monitoring security, implementing breach detection capabilities such as IPS/IDS technology should be considered essential.
){kind=link}
Figure 5-3 Ransomware Infection
DMVPN Core Concepts
The features available in a DMVPN solution are similar to those available with both GETVPN and FlexVPN. However, like those types of VPN architectures, DMVPN has its own components and terminology. For example, you need to know and understand GRE tunnels and Next Hop Resolution Protocol (NHRP), which enable DMVPN to scale up to thousands of remote connections and reduce the need for complex administration.
DMVPN Example
Figure 5-4 shows an example of a DMVPN solution where each spoke can communicate with the hub router. In addition, Spoke1 and Spoke2 establish a VPN tunnel directly between themselves.
A critical piece of this solution is that GRE and NHRP work together to resolve the peer destination IP address. In essence, the NHRP configuration on a spoke router forces a registration process that maps the GRE tunnel IP address to the Internet IP address for the spoke on the hub NHRP database. Another critical piece of this solution is multipoint Generic Routing Encapsulation (mGRE). We will look more closely at these two components in the next section.
DMVPN, as its name implies, also supports IPsec. The configuration combinations for IPsec are quite extensive, and this chapter covers only some of the key ones; in other chapters, you will see many other configurations that include IPsec. Let’s look at the components of a DMVPN deployment.
)
Figure 5-4 A Full-Mesh DMVPN Tunnel