CCDE – DMVPN Crypto Design Considerations – Daniels Networking Blog (2024)

This post will describe some of the crypto design considerations for DMVPN.

DMVPN Overview and Crypto Overhead

First let’s have a quick recap of what Dynamic Multipoint VPN (DMVPN) is. DMVPN is an overlay technology where multi point GRE tunnels are used to form an overlay where a routing protocol will run across the overlay. DMVPN is a hub and spoke technology where the DMVPN hub acts as a centralized control plane. DMVPN uses Next Hop Resolution Protocol (NHRP) to register the IP addresses of the spokes with the hub. When a router looks in its routing table, the next-hop will be the IP address of the tunnel, not the real outside IP which must be used for the GRE encapsulation. To find the outside IP of the spoke, NHRP is used to resolve the next-hop to the real outside IP.

DMVPN runs over public transport. This means that it’s possible to snoop the traffic while in transit. To prevent this from happening, DMVPN is often combined with IPSec to encrypt the packets. IPSec can run in two modes, transport mode and tunnel mode. In transport mode, the original IP header is not encrypted and there is no additional IP header added. In tunnel mode, which is the default for tunnels, a new IP header is added and the original IP header is encrypted. Tunnel mode is a must for classic LAN to LAN setups because normally the inside subnets are private addresses and the tunnel is formed between publically routable IP addresses.

The difference between transport mode and tunnel mode is show in the picture below.

IPSec in transport mode adds around 36 bytes and in tunnel mode it adds around 52 bytes. The exact number depends on the encryption algorithm and padding of the packet. When using DMVPN with IPSec, it is unneccessary to use tunnel mode. Why? DMVPN uses GRE which means that a new IP header is already added by GRE. The GRE encapsulation happens on the tunnel interface before the encryption process takes place. The picture below shows a GRE encapsulated packet.

GRE has added an IP header for transport. The source IP is the outside IP of the spoke and the destination IP is the hub or spoke outside IP for the other end of the tunnel. When using DMVPN and IPSec together, IPSec transport mode should be used to save on the overhead. The default is to use tunnel mode, so transport mode needs to be configured under the transform set. This will then save at least 16 bytes of overhead. It is common though to set the MTU to 1400 on the tunnel interface and to adjust the MSS of the LAN to 1360 bytes.

DMVPN Dual Tier Design

In very large DMVPN topologies, the DMVPN hub may become a choke point. Remember that the DMVPN hub is essentially a centralized control plane for the DMVPN topology. This is especially true in phase 1 networks where all traffic must pass through the hub and where no spoke to spoke tunnels are available. When using DMVPN and IPSec together, the hub must both handle NHRP, routing protocols and the encryption of packets even if the packets are going between two spokes. When traffic passes between two spokes in phase 1, the encrypted traffic will travel from spoke x to the hub to perform decryption, only to hairpin the packet and send it back out the same interface after encrypting it towards spoke z. This can put a very high load on the hub router.

To lessen the load of the hub router, it is possible to split the NHRP and routing protocols to one router and the crypto process to another router. This is demonstrated in the picture below.

The encryption and decryption of packets is now handled by the crypto headend router. It will then forward the GRE packets to the DMVPN hub which will terminate NHRP and routing protocols. How does this impact our design?

The IPSec tunnel endpoint is now different from the GRE tunnel endpoint. This means that we can’t use IPSec transport mode since it reuses the IP header. We need to use IPSec tunnel mode which adds a new IP header. The destination IP of the IPSec packet will then be the crypto headend router. This will add more overhead to our packets. This also means that we can’t use an IPSec protection profile because the crypto endpoint is now different from the GRE tunnel endpoint. This means that we need to use a static crypto map on the spokes. The crypto headend will use a dynamic crypto map.

It also means that spoke to spoke tunnels are not supported since all IPSec tunnels are now terminating on the crypto headend instead of forming tunnels directly between the spokes. This means that this design is mostly valid if we already run a large hub and spoke network without spoke to spoke tunnels and we need to scale the hub.

In my previous post I made a case for using DMVPN and GET VPN together. GET VPN uses a group SA which means that we don’t establish tunnels. We can combine the two technologies here to have a DMPVN hub and then have crypto headends acting as GMs. This design let’s us split the DMVPN hub and crypto headend responsibilities while still allowing for spoke to spoke tunnels. This link to another blog demonstrates how the two can be combined.

1. Dynamic Multipoint VPN (DMVPN) Overview:

a. Architecture:

DMVPN is an overlay technology employing multipoint GRE tunnels to establish a network overlay.
It operates in a hub-and-spoke model, with the hub acting as the centralized control plane.
Next Hop Resolution Protocol (NHRP) registers spoke IP addresses with the hub.

b. Traffic Encryption:

DMVPN operates over public transport, making traffic susceptible to snooping.
To address this, IPSec is often combined with DMVPN to encrypt packets.
IPSec can operate in transport mode or tunnel mode.

2. IPSec Modes and Overhead:

a. Transport Mode vs. Tunnel Mode:

Transport mode encrypts the payload, leaving the original IP header intact.
Tunnel mode, the default for DMVPN, adds a new IP header and encrypts the original IP header.
When DMVPN is used with IPSec, tunnel mode is unnecessary due to the added GRE encapsulation.

b. Overhead Considerations:

IPSec in transport mode adds approximately 36 bytes, while in tunnel mode, it adds around 52 bytes.
DMVPN with IPSec typically defaults to tunnel mode, but transport mode can be configured to save overhead.

3. DMVPN Dual Tier Design:

a. Hub Choke Point:

In large DMVPN topologies, the hub may become a bottleneck, especially in phase 1 networks.
All traffic, even between spokes, passes through the hub for decryption and encryption.

b. Dual Tier Design:

To alleviate hub load, NHRP and routing protocols can be split from crypto processes.
Encryption and decryption are handled by a crypto headend router, reducing the hub's load.

c. Impact on Design:

Different IPSec tunnel endpoints necessitate the use of IPSec tunnel mode, adding more overhead.
Spoke-to-spoke tunnels are not supported in this design, and static crypto maps on spokes are required.

4. DMVPN and GET VPN Integration:

a. Combined Technologies:

DMVPN and Group Encrypted Transport (GET) VPN can be combined for a dual-purpose design.
This allows for a DMVPN hub and crypto headends acting as Group Members (GMs).
The combination supports spoke-to-spoke tunnels while maintaining separation of DMVPN and crypto responsibilities.

Conclusion:

In conclusion, understanding DMVPN design considerations, IPSec modes, and the impact of a dual-tier design is crucial for optimizing network performance and security. The integration of DMVPN and GET VPN offers a versatile solution for organizations requiring both hub-and-spoke and spoke-to-spoke communication within a secure framework.

For further insights, the CCDE (Cisco Certified Design Expert) tag indicates a deep understanding of these concepts, highlighting a proficiency in designing complex network infrastructures.