DMVPN vs FlexVPN: Cisco Overlay VPNs Compared

By Taylor Thomas · 2026-09-02

Cisco IOS-based routers offer two mature ways to build an encrypted overlay across networks you do not control: DMVPN and FlexVPN. Both appear by name in SCOR objective 1.6’s list of site-to-site deployment types, both serve large hub-and-spoke deployments — within the tunnel, SA, and throughput limits of the chosen platform — and both can let spokes reach each other directly. They differ in what they are underneath — one is a specific topology model polished over two decades, the other a construction kit standardized on IKEv2.

DMVPN: mGRE Plus NHRP

DMVPN builds its overlay from multipoint GRE — a tunnel interface that speaks to many peers, typically one per DMVPN cloud — and NHRP, the Next Hop Resolution Protocol, to map overlay addresses to the underlay transport addresses that actually reach them. Spokes register with the hub, which acts as the NHRP server; the hub learns each spoke’s mapping dynamically, which is why spokes can sit behind dynamic addresses. IPsec encrypts the GRE tunnels, and a routing protocol typically runs over the overlay to distribute reachability. Phase 1 spokes classically used point-to-point GRE; the spoke-to-spoke phases put mGRE on the spokes as well.

The design’s evolution is described in phases, and the phases are exam vocabulary. Phase 1 is pure hub-and-spoke: every spoke-to-spoke packet transits the hub. Phase 2 introduced direct spoke-to-spoke tunnels — a spoke resolves the remote spoke’s transport address through NHRP and builds a dynamic tunnel — but requires spokes to hold specific routes for each other’s networks, with the remote spoke as the next hop. Phase 3 fixed that with NHRP redirect and shortcut: the hub, forwarding a packet it knows could go direct, signals the spoke to resolve a shortcut, so direct tunnels form even when the hub advertises only summaries. Phase 3’s combination of summarized routing and direct data paths is why it is the usual choice for designs that need to scale.

FlexVPN: An IKEv2 Framework

FlexVPN is not a topology; it is Cisco’s unified VPN framework built on IKEv2 — and IKEv2 only. The same building blocks assemble site-to-site tunnels, hub-and-spoke overlays, and remote access: point-to-point tunnel interfaces where the peer is known, and, on hubs, a virtual template that clones a per-peer virtual access interface for each connecting spoke or client. Because every peer terminates on its own interface, per-peer treatment falls out naturally — QoS, ACLs, and policy defined on the virtual template or delivered through authorization apply to each peer’s virtual access interface, with IKEv2 authorization drawing per-peer policy from a local database or RADIUS.

The framework also ships with smart defaults: preconfigured IKEv2 proposals and policies that apply when you define none, plus default IPsec transform and profile objects ready to be referenced, so a FlexVPN configuration defines custom crypto objects only where your standard demands it — identity, authentication, and the tunnel’s profile reference are still yours to configure.

IKEv2 itself does real work in the design. Its configuration exchange can push addresses and routes during negotiation, so FlexVPN can distribute routing through IKEv2 itself — attractive for spoke populations that should not each run a routing protocol adjacency. A dynamic routing protocol over the tunnels remains an option, and spoke-to-spoke direct tunnels are supported here too, with NHRP resolving the remote spoke, while IKEv2’s other advantages — broader authentication options including EAP, and cleaner rekeying — come along by default.

Choosing Between Them

The honest comparison is scope. DMVPN does one thing — a dynamic multipoint overlay — with enormous field maturity, a lean interface model, and an installed base your peers have operated for years. FlexVPN trades that focus for range: if the same routers must terminate site-to-site tunnels and remote access clients, or you want per-peer interfaces and policy, or you are standardizing on IKEv2 and want its features exposed rather than wrapped, the framework fits the shape of the problem. Those are reasons a new design might start from FlexVPN; an established DMVPN estate weighs them against the cost of change.

The neighboring design worth placing precisely is GET VPN, which encrypts without tunnels by preserving the original IP header — an option when the WAN already routes your addressing end to end and native any-to-any forwarding should be kept. DMVPN and FlexVPN instead build routed tunnel overlays — the natural fit where the transport cannot route your internal addressing, as on the internet, and chosen even on private WANs for the topology and routing independence an overlay brings.

For SCOR, be able to state what each is made of — mGRE plus NHRP plus IPsec versus IKEv2 plus tunnel and virtual template interfaces — and how spoke-to-spoke traffic comes to flow directly in each. The SCOR course walks both designs at the command line, and the wider VPN track in the catalog covers the transport and crypto decisions that come first.

Frequently Asked Questions

Is FlexVPN replacing DMVPN?

No. Both remain supported and both appear on the current SCOR blueprint. DMVPN remains a common choice for large existing hub-and-spoke overlays, while FlexVPN is the natural framework when you are building new IKEv2-based designs or combining site-to-site and remote access on the same routers. The choice is architectural, not a migration mandate.

Do spokes talk directly to each other in both designs?

They can. DMVPN phase 2 and phase 3 build dynamic spoke-to-spoke tunnels, with phase 3's NHRP redirect and shortcut mechanism allowing summarized routing at the hub. FlexVPN also supports dynamic spoke-to-spoke tunnels, using NHRP to resolve the remote spoke and virtual access interfaces to terminate the direct tunnel.

Why is IKEv2 central to FlexVPN?

FlexVPN was designed as a unified configuration framework on top of IKEv2 and does not support IKEv1. IKEv2 supplies the machinery FlexVPN leans on — built-in authentication options including EAP, a configuration exchange that can push addresses and routes, and per-peer policy through IKEv2 authorization — which is what lets one framework cover site-to-site, hub-and-spoke, and remote access.