Virtual Private Networks (VPN) gained popularity over the years thanks to secure interconnection between branches while reducing costs. Back in the day, Lease lines were the main interbranch connection option. Those provided reliable transfers with low delay, unfortunately costing a fortune. As the Internet and broadband evolved, they provided faster, more reliable connections suitable for site-to-site VPNs. One of the first VPNs was not equipped with security features, forwarding traffic across as plain text. Those quickly evolved when IPsec came across. It provided point to point secure tunnel for branch internetworking. This solution introduced issues with routing protocols due to a lack of multicast support. Another downside of that solution was that, while an organization grows and expands, so does the number of sites making IPsec hard to manage.
Nowadays, Software Defined Wide Area Networks (SD-WAN) allow us to overcome most of the issues with Site–to–Site VPNs. One of the most deployed solutions till now is an SD-WAN’s predecessor Dynamic Multipoint VPN (DMVPN) that it’s still widely deployed due to its simplicity and scalability.
This document with concentrate on DMVPN and how this can simplify the deployment of site-to-site VPNs across an organization.
DMVPN Design
DMVPN was designed as Hub and Spoke architecture that centralizes data exchanges by allowing many-to-one connections that simplify implementation while reducing administrative overhead. Unfortunately, this cost-effective solution introduced drawbacks due to a single central point of failure, as shown in Figure 1.
Figure 1
The first implementation of DMVPN, called phase 1, allows for attaching spokes to a central point. This approach caused issues at the hub due to backhauling of the traffic, which quickly exhausted bandwidth. Further implementations resolved this issue by allowing spokes to override the next hop while sending traffic directly between each other.
For this lab, the idea is to create a VPN between headquarters and branches (2). Headquarters will utilize two types of links. MPLS L3 VPN connection as the primary connection and broadband as failover. Spoke 1, on the other hand, has only a broadband connection, whereas Spoke 2 and 3 operate on MPLS L3 VPN circuits.
DMVPN Dual Hub
The Single Hub approach, even though it was a cost-effective solution has he drawback of a single point of failure. Dual Hub implementations resolved the issue by introducing a second hub to reduce the risk of negligence. Effectively creating a Dual Hub Single Cloud solution.
This solution is perfect for single link implementations or when the customer can advertise an IP address to all ISP connected. With broadband connections, this option is not always available. Therefore, there might not be a route from the provider to the tunnel source if it’s not directly connected. A similar issue can be observed with BGP. The resolution usually is to peer devices to Loopbacks as the underlying paths may change, and loopback can be reachable through a different interface. The situation is similar with DMVPN, if the tunnel’s source is from 110.0.0.2 all the spokes must be able to reach it. Otherwise, the DMVPN will not be able to create tunnels.
Dual Hub Dual Cloud
A perfect resolution addressing Single cloud networks is dual and multi-cloud implementation. Allowing for two tunnels sourced from different interfaces ensures connectivity to either one. In addition, if both tunnels of DMVPN clouds in dual hub implementation are up and available, routers may use Equal-Cost Multi-Pathing to share the load across all available paths. For the lab purpose since there is MPLS L3VPN with Internet services available, there will be a Dual Hub Dual Cloud architecture implemented.
Security
In order to provide secure transport between the enterprise networks, IPsec could be put in place.
Internet Protocol Security (IPsec) is a security suite of protocols, used to protect connections, that involves two security services Authentication Header (AH) and Encapsulating Service Payload (ESP). AH was designed to authenticate the sender and supply authenticity of data. ESP, on the other hand, additionally provides encryption services making it more secure.
Basic implementation of a Site-to-Site VPN with IPsec provides P2P encrypted tunnel through increasing administrative overhead due to the added configuration of each site. DMVPN contrastingly was designed to provide dynamic tunnelling in base form without traffic security. The enhanced version can use tunnel protection with an IPsec profile to encrypt the traffic sent through the tunnels, whether static or dynamic.
DMVPN Configuration
DMVPN implementation requires two sets of configurations, one for hub devices and the other for spokes which can be used across all with minor changes such as source interface. In addition to reducing human error, there will be DHCP used to assign IP addresses to spokes.
Hubs
Since each hub will use both circuits provided, two tunnelling interfaces are necessary, each sourced from a different interface. Tunnel one, in this case, will use an MPLS circuit, whereas Tunnel two will use broadband services. The next step is to define DMVPN on its own. For that tunnel 1 and 2 was created. Next Hop Resolution Protocol (NHRP) is responsible for allowing Next Hop Clients (NHC), also known as (Spoke), to register with Next Hop Server (NHS) (HUB). Once NHCs are registered with NHS, they can discover other NHC and define the best path. The NHRP should have authentication set to protect against the rogue router. For the lab, there has been a CiscoPWD set which should be set to a somewhat more secure password.
The tunnel then must be set as GRE multipoint(mGRE). As IPsec doesn’t forward multicast traffic, that’s why it is necessary to run IGP Generic Routing Encapsulation (GRE) which has to be used to encapsulate them. It also allows dynamically set tunnel endpoints without static mapping. To fully map a spoke it has to have an IP address. It can be statically by assigning an IP address to each Tunnel interface or dynamically with the help of DHCP server.
Spoke
On the Spoke side configuration looks a little bit different. NHRP mapping has to be created, in order to statically bind neighbor Tunnelling IP address with NBMA address. In addition, NHS needs to be defined with specifying priorities to force devices to use one over the other. Tunnel security seems similar with addition shared keyword as interface GigabitEthernet1 is the source of both tunnels.
IPsec
The IPsec configuration involves specifying a pre-shared-key which in this case is done using a keyring. Followed by the isakmp policy to define key exchange, usually called phase 1. For demonstration, we have used AES encryption. In a real implementation, AES 512 should be used. Similarly, to Diffie Hellman group 5, it is outdated and should be changed to at least group 15. Last but not least, SHA256 was chosen for data authenticity checking. All parameters have been bound using the isakmp profile with specifying to apply it to all devices.
Phase 2 of IPsec was to define the transform set for which ESP-SHA256-HMAC for authentication and ESP-AES256 for encryption has been used. Finally, the IPsec profile bounded transform set and isakmp profile together which then was applied under the Tunnel interface.
DHCP
DHCP, by default, does not run across tunnels. This feature must be enabled, which can be done using the command ip dhcp support tunnel unicast.
This command turns on unicast DHCP messaging that spokes are unaware of, so all messages sent as broadcast from their perspective. the command ip dhcp client broadcast-flag clear configured at spoke sites allows devices to send unicast DHCP messages instead.
IGP
EIGRP was chosen as the preferred IGP. This was due to its ability to calculate paths based on bandwidth, delay, reliability, and load using a wide metric with command metric version 64bit. In addition, for wide metric to use all aspects for calculation, metric weights have been changed to
K1 (bandwidth) = 2 | K3 (delay)= 2 | K5 (MTU)= 1 |
K2 (load) = 1 | K4 (Reliability)= 1 |
To provide additional protection against rogue network injection, EIGRP will use a key to authenticate neighbors.
