Dynamic Multipoint Virtual Private Networks






Dynamic Multipoint Virtual Private Networks

At this point, we've covered basic IP routing continuity options over IPsec VPN tunnels in the context of Geographic HA, each of which presents its own unique design challenges. In large-scale IPsec+GRE designs, two such unique design challenges include management and configuration on IPsec+GRE hub/aggregation routers and peer scalability in the hub/aggregation router SADB. DMVPN addresses these concerns, among others, by greatly decreasing the configuration and management effort on the IPsec+GRE hub/aggregation routers using mGRE with Next Hop Resolution Protocol (NHRP) and enabling spoke routers to dynamically build SAs directly to their desired spoke routers. In this section, we will review all of the required components of DMVPN and reinforce these components with an enterprise DMVPN deployment case study.

DMVPN Solution Design Drivers

DMVPN designs enable administrators to address several key design considerations with large-scale IPsec+GRE deployments. Our discussions in this section focus on two of these critical design considerations in large-scale IPsec+GRE designs found in many of today's enterprise-class networks:

  • Configuration Complexity and Size: Recall from our discussion of traditional IPsec+GRE designs earlier in this chapter that, each time a branch is added to the network, a GRE tunnel interface is added on the branch IPsec VPN gateway with its own unique point-to-point GRE tunnel interface on the central hub IPsec VPN gateway in order to complete the IPsec+GRE configuration. The creation of unique GRE tunnel interfaces on the hub IPsec VPN gateway for each branch causes configuration complexity and management as the number of branches increases. For example, a large enterprise-class network with 1000 IPsec+GRE enabled branches requires 1000 GRE tunnel interfaces to be configured on the hub IPsec VPN gateway. As we'll discuss later in this section, a DMVPN design can decrease the 1000 IPsec+GRE interfaces described above to a single mGRE interface. DMVPN does this not by altering the standards-based IPsec protocol itself, but instead by changing the configuration requirements of traditional point-to-point IPsec+GRE networks, yielding a more streamlined and manageable configuration and management requirements of the overall design.

  • GRE and IPsec Scalability and Management: In a standard, traditional IPsec+GRE design, each spoke creates a Phase 1 and 2 SA to the hub. Additionally, the required point-to-point GRE tunnel from the hub to the branch consumes an IDB entry on the hub and branch. For example, in an enterprise network with 1000 branches, 2000 SAs would exist in the hub IPsec VPN gateway's SADB, and 1000 IDB entries would exist to support the GRE tunnel termination. While DMVPN does not alter this SA requirement on the hub (a permanent hub-spoke SA is also created in DMVPN), DMVPN alters this behavior such that interface description block (IDB) entries are not statically created and consumed. Instead, they are created only when they are needed and only on the appropriate peers. Considering the 1000-branch example with DMVPN enabled, the GRE IDB requirement decreases from 1000 to potentially as little as 1 IDB required on the hub.

Note

Even in DMVPN networks, having 1 GRE IDB entries is rare to the point of being infeasible. This implies 100 percent spoke-to-spoke traffic. Any time a spoke requires IPsec-secured connectivity to the hub, regardless of whether or not DMVPN is configured, 2 IPsec SAs and 1 IDB entry will be created on the hub. The example described previously is used to reinforce that, with DMVPN, IPsec SAs and GRE IDBs are created only as needed.


In addition to improved SA and IDB management, DMVPN decreases unnecessary decrypt/reencrypt behavior on the hub IPsec VPN gateway for spoke-to-spoke communications. In traditional IPsec+GRE hub and spoke deployments, a branch must encrypt traffic to the hub, where it is decrypted and then reencrypted before sending to the destination branch in a spoke-to-spoke scenario. We will explore in our step-by-step discussions how DMVPN can be used to eliminate this by enabling the spokes in the previous example to directly negotiate Phase 1 and 2 SAs with each other, as opposed to both spokes negotiating Phase 1 and 2 SAs with the hub. In doing this, DMVPN changes the behavior of the spoke-to-spoke communication example described above to a direct spoke-to-spoke IPsec VPN tunneling model, including one encrypt action on the source IPsec spoke and one decrypt action on the destination IPsec spoke with no encryption or decryption occurring on the hub at all. DMVPN therefore presents an opportunity to dramatically decrease the processing load on the hub router in networks with heavy spoke-to-spoke IPsec VPN traffic.

DMVPN Component-Level Overview and System Operation

At this point, we've covered several key design drivers for DMVPN in IPsec+GRE environments, including DMVPN's ability to ease configuration and management burden on administrators, increase IPsec scalability through better management of the IPsec SADB and GRE IDB entries, and increase IPsec scalability by eliminating processing load on the hub IPsec VPN gateway attributable to spoke-to-spoke communications. In this section, we will discuss the step-by-step process involved in hub-to-spoke and spoke-to-spoke communication examples in a DMVPN network. However, before we dive in to the step-by-step operation of DMVPN in these scenarios, it is important to understand the required components of the overall DMVPN architecture:

  • Multipoint GRE (mGRE): DMVPN requires a multipoint GRE tunnel configured on the hub IPsec VPN gateway and on its spokes. The mGRE tunnel is used to exchange routing protocols between the private IP networks at the mGRE tunnel endpoints. NHRP messages are also exchanged over the mGRE tunnel between the hub and its spokes when spoke IPsec VPN gateways attempt to create direct dynamic spoke-to-spoke IPsec VPN tunnels.

  • Next Hop Resolution Protocol (NHRP): When two private IP networks behind two spoke IPsec VPN gateways want to communicate with one another, the initiating IPsec VPN gateway uses NHRP to determine which peer it should negotiate Phase 1 and 2 IPsec SAs with. The initiating IPsec VPN gateway accomplishes this by leveraging NHRP to query the Next Hop Server (NHS) configured at the hub for the destination spoke's physical IP address. This IP address is subsequently used when building the IPsec VPN tunnel that secures the traffic exchange between private networks across the mGRE tunnel.

  • IPsec and ISAKMP: As with standard IPsec+GRE deployments, DMVPN uses IPsec and ISAKMP for data authentication, integrity, confidentiality, and nonrepudiation. Although DMVPN does not change IPsec or ISAKMP protocols themselves, DMVPN does greatly simplify the configuration of IPsec and ISAKMP respective to traditional IPsec+GRE configuration requirements.

The components described above work in concert to deliver the overall DMVPN solution. Figure illustrates an enterprise hub-and-spoke DMVPN design in which several spokes communicate in both a spoke-to-spoke and spoke-to-hub fashion.

Enterprise DMVPN Topology


In the DMVPN topology, C3845ISR-A and B communicate to the hub securely using IPsec+GRE, without any dynamic next-hop discovery behavior with NHRP. In other words, in this topology, or any DMVPN topology, IPsec+GRE tunnels are created from hub-to-spoke once tunnel protection is enabled on the hub and spoke tunnel interfaces. The dynamic behavior of the DMVPN implementation of Figure is introduced only when C3845ISR-A and B communicate with one another directly. In this case, NHRP is used to dynamically determine the peering information necessary to build a direct IPsec tunnel between the two spokes, effectively bypassing any crypto requirements on the hub for that specific spoke-to-spoke tunnel. The following list illustrates the sequence of events corresponding to dynamic spoke-to-spoke SA establishment between two endpoints illustrated in Figure:

1.
Host-A on Network A initiates a TCP session to Server-B on Network-B. C3845ISR-A looks up the route to Server-B and determines that the next hop is 192.168.2.1 and that the GRE interface (tunnel 0) is the egress interface, which is in the crypto switching path.

Note

In a DMVPN environment, all traffic learned over mGRE tunnel is expected to be included in the crypto switching path. As such, there is no concept of crypto ACLs in a DMVPN design.

2.
C3845ISR-A does not have an entry in its NHRP mapping table for the next hop of 192.168.2.1, so it queries the NHRP next-hop server (192.168.0.1). All of the spokes using the NHS 192.168.0.1 have a manually defined NHS definition mapped to the C7304's loopback interface, (200.1.0.1).

3.
The NHS on C7304 returns C3845ISR-B's physical interface IP (200.1.2.1) as the next-hop IP mapping to the next-hop IP of 192.168.2.1 in the forwarding decision by C3845ISR-A in #1.

4.
C3845ISR-A uses the C3845ISR-B's physical interface IP returned in #3 as the IPsec peer for Phase 2 SA negotiation. C3845ISR-A uses this information to build IPsec SAs with C3845ISR-B.

5.
Server-B forwards return traffic to Host-A. Similar to C3845ISR-A in #1, C3845ISR-B does not have the appropriate next-hop entry.

6.
C3845ISR-B queries the NHRP next-hop server (192.168.0.1) on C7304 for the next-hop IP.

7.
The NHRP entry is returned by the NHS on C7304 (192.168.1.1 -> 200.1.1.1). The NHRP mapping entry is used by C3845ISR-B to forward traffic C3845ISR-A over the IPsec+GRE tunnel established in #4.

8.
Networks A and B run a separate instantiation of EIGRP (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 = EIGRP 10) from the physical networks used to build the IPsec tunnel in #4 (200.1.0.0/24, 200.1.1.0/24, 200.1.2.0/24 = EIGRP 1). Multicast RP updates for EIGRP 10 can now be exchanged between C3845ISR-A and B across the IPsec+GRE tunnel built in #4. Traffic can now flow bidirectionally over the IPsec+GRE tunnel between Networks A and B behind C3845ISR-A and B, respectively.

9.
Host-A forwards traffic to Server-B over the IPsec+GRE tunnels established between C3845ISR-A and B using DMVPN. The VPN Gateway, C3845ISR-A, performs GRE encapsulation on the data before encrypting it. C3845ISR-B performs decryption on the traffic before GRE decapsulating it and eventually forwarding on to Server_B.

10.
Server-B forwards return traffic to Host-A over the IPsec+GRE tunnels established between C3845ISR-A and B using DMVPN. The VPN Gateway, C3845ISR-B, performs GRE encapsulation on the returned data before encrypting it. C3845ISR-A performs decryption on the return traffic before GRE decapsulating it and eventually forwarding on to Host-A.

Note

When the NHRP entry timeout intervals expire, the NHRP entries learned in #3 and #7 will be removed from the NHRP mapping tables on C3845ISR-A and B, respectively. This causes IPsec to tear down the VPN tunnel built between C3845ISR-A and B in #4.


The process described above illustrates several benefits of DMVPN from administrative, management, and scalability perspectives. The configurations for C7304, C3845ISR-A, C3845-ISR-B can be referenced in Examples 7-12 and 7-13 to further reinforce the illustration of these benefits. Before reviewing the required configurations for the DMVPN implementation topology of Figure, let's quickly review the DMVPN benefits against the step-by-step DMVPN operation on C3845ISR-A and B described above:

  • Zero-Touch Spoke Provisioning on the Hub (C7304): DMVPN configuration requires no maintenance on the hub (C7304) when adding spokes to the topology. In a traditional IPsec+GRE environment, a GRE tunnel interface must be added on the hub corresponding to that branch. DMVPN eliminates this requirement by using a single mGRE tunnel interface on the hub instead of a 1:1 branch-to-hub GRE interface configuration. The required hub configuration for C7304 in Figure is provided in Figure.

  • Elimination of Decrypt/Reencrypt Behavior on Hub (C7304): DMVPN eliminates unnecessary decrypt/re-encrypt action on the hub. Note that, in step 4 previously, the IPsec VPN tunnel is terminated on C3845ISR-A and B. In a traditional IPsec+GRE environment, C3845ISR-A and B would terminate their IPsec+GRE tunnels on the hub, therefore requiring C7304 to decrypt/GRE decapsulate the inbound traffic from C3845ISR-A and GRE-re-encapsulate/encrypt it before forwarding it to C3845ISR-B.

  • Uniform IPsec Spoke (C3845ISR-A and B) Provisioning: DMVPN eliminates node-specific configuration elements on C3845ISR-A and B. DMVPN accomplishes this by enabling the peer to dynamically learn peering information via NHRP from the NHS configured on the hub (C7304), as illustrated in steps 2, 3, and 5 previously. This enables administrators to push a generic, uniform, IPsec configuration to each spoke (C3845ISR-A and B). The common IPsec configuration for spoke IPsec VPN gateways C3845ISR-A and B is illustrated in Figure.

As with traditional IPsec+GRE, the ISAKMP must be configured to establish the Phase 1 SAs that DMVPN will use to build Phase 2 SAs. Unlike the configurations used earlier in this chapter, this design uses RSA-sigs (the IOS default) to authenticate the IKE SA. The crypto transform used in this example is 3DES with MD5 HMAC authentication on the ciphered blocks. A crypto profile is used to bind the transform set described above to the tunnel interface used for DMVPN (Figure, lines 11-12). Unlike traditional IPsec and IPsec+GRE designs, there is no need for a crypto map or crypto ACL in a DMVPN design. The IPsec transform set is applied to the interface by referencing the IPsec profile configured earlier. This effectively turns on ISAKMP on physical interface protecting the tunnel and also includes all GRE traffic sent out of this interface to be included in the crypto switching path. As such, there is no concept of a crypto ACL for defining crypto-protected traffic flows in a DMVPN. Instead, all traffic forwarded out of the GRE interface with tunnel protection enabled will be encrypted using the appropriate crypto transform.

NHRP is used to dynamically learn next-hop addresses for spoke-to-spoke GRE tunnel terminations. NHRP Authentication is performed in cleartext, as shown in Figure, line 18. Additional authentication is provided at the GRE layer using a tunnel key, as shown in Figure, line 25. The NHRP network ID shown in Figure, line 20, must be consistent between all of the spokes and the hub in the same DMVPN deployment that uses the same mGRE tunnel interface on the hub. All of the spokes with this network ID will use this hub router as the NHRP NHS.

Tip

The GRE tunnel maximum transmission unit (MTU) can be adjusted to avoid fragmentation issues that could lead to performance issues if reassembly is required prior to decryption at the opposite end of the tunnel. Figure, line 14, illustrates how this can be done on a DMVPN hub router. For more information on proper handling of IP fragmentation in IPsec VPNs, please refer to Chapter 4.


The IP address of the tunnel interface is injected in to EIGRP 10. The routing protocol configuration in this design is configured in the same fashion as traditional IPsec+GRE: EIGRP 10 is used as the routing protocol for the tunnel interfaces and the private networks communicating over the IPsec+GRE DMVPN tunnels, while OSPF is used as the routing protocol for DMVPN IPsec and GRE tunnel establishment. Disabling split horizon for EIGRP AS 10 allows RP updates to be exchanged from spoke to spoke. Updates flow in to the mGRE tunnel interface on the hub and are then transmitted out of the hub to the destination spoke. EIGRP split horizon prevents this behavior, and is on by default, so it must be explicitly disabled when using EIGRP to route between private networks over the DMVPN IPsec+GRE infrastructure.

Figure. DMVPN Hub Configuration for C7304 (Figure)

1  crypto ca trustpoint IOS_CA1
2   enrollment url http://200.1.2.100
3  !
4  crypto isakmp policy 10
5   hash md5
6   group 2
7  crypto isakmp keepalive 10
8  !
9  crypto IPsec transform-set dmvpn7 esp-3des esp-md5-hmac
10 !
11 crypto IPsec profile chap7-dmvpn-profile
12  set transform-set dmvpn7
13 !
14 interface Tunnel0
15  ip address 192.168.0.1 255.255.255.0
16  no ip redirects
17  ip mtu 1416
18  ip nhrp authentication dmvpn7
19  ip nhrp map multicast dynamic
20  ip nhrp network-id 7
21  ip nhrp holdtime 360
22  no ip split-horizon eigrp 10
23  tunnel source FastEthernet0/0
24  tunnel mode gre multipoint
25  tunnel key 0
26  tunnel protection IPsec profile chap7-dmvpn-profile

In terms of encryption and routing processes, the configuration of the DMVPN spoke in Figure is similar to that of the DMVPN hub provided in Figure. Unlike the hub (which is actually the NHS and is aware of all spoke addresses), the spoke dynamically learns next hop addresses for spoke-to-spoke GRE tunnel terminations via NHRP by querying the NHS. Like the hub, the spoke performs NHRP Authentication in cleartext, and additional authentication is provided at the GRE layer using a tunnel key. The NHRP network ID shown must match the hub in order for the spoke to effectively use the hub as the NHS for resolving next-hop queries. A static NHRP map (Figure, line 18) is required on the spoke to allow queries to the NHS (192.168.0.1) to be mapped to the physical interface of the NHS itself (200.1.1.1). The spoke is then configured to use this static map to query for the unknown next-hop IP addresses using NHRP. Although the NHS is defined as a tunnel interface, it is manually mapped to a physical interface, as shown previously in this example. The NHS responds to NHRP next-hop queries that are subsequently used by DMVPN for dynamic spoke-to-spoke IPsec VPN tunnel establishment.

Figure. DMVPN Spoke Configuration for C3845ISR-A and B (Figure)

1  crypto ca trustpoint IOS_CA1
2   enrollment url http://200.1.2.100
3  !
4  crypto isakmp policy 10
5   hash md5
6   group 2
7  crypto isakmp keepalive 10
8  !
9  crypto IPsec transform-set dmvpn7 esp-3des esp-md5-hmac
10 !
11 crypto IPsec profile chap7-dmvpn-profile
12  set transform-set dmvpn7
13 !
14 interface Tunnel0
15  ip address 192.168.0.3 255.255.255.0
16  ip mtu 1416
17  ip nhrp authentication dmvpn7
18  ip nhrp map 192.168.0.1 200.1.1.1
19  ip nhrp network-id 7
20  ip nhrp holdtime 600
21  ip nhrp nhs 192.168.0.1
22  tunnel source Ethernet0/0
23  tunnel destination 200.1.1.1
24  tunnel key 0
25  tunnel protection IPsec profile chap7-dmvpn-profile



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows