FlexVPN vs DMVPN: Architecture, Working IOS-XE Configs, and When to Use Each

FlexVPN and DMVPN are the two VPN frameworks that define how Cisco routers build site-to-site and remote access tunnels — and if you work with IOS-XE in production, you'll encounter both. FlexVPN, built on IKEv2 (RFC 7296), unifies site-to-site, hub-and-spoke, and remote access VPN under a single CLI framework with smart defaults that cut configuration by 60-70%. DMVPN, the mGRE + NHRP + IPsec overlay that's powered enterprise branch networking since IOS 12.4, still runs on over 70% of production branch VPN deployments.

This article breaks down both frameworks side-by-side — architecture, working configs, verification commands, scalability trade-offs, and common pitfalls that waste hours of troubleshooting time.

The Core Architectural Difference

FlexVPN uses IKEv2 as both the signaling protocol and the keying mechanism for all tunnel types. DMVPN relies on a three-protocol stack: mGRE for tunnel encapsulation, NHRP for dynamic address resolution, and IPsec (IKEv1 or IKEv2) for optional encryption.

FlexVPN treats every VPN scenario — site-to-site, spoke-to-spoke, remote access — as an IKEv2 session with different authorization policies. DMVPN treats the overlay as a separate network layer where NHRP handles tunnel-to-NBMA address mapping independently from the encryption layer.

DMVPN: The Three-Protocol Stack

1. mGRE (Multipoint GRE) — A single tunnel interface handles multiple remote endpoints. Unlike point-to-point GRE where each peer requires a dedicated tunnel interface and subnet, mGRE eliminates the N-squared configuration problem. This is what makes DMVPN scale from 10 to 10,000 spokes on a single hub.

2. NHRP (Next Hop Resolution Protocol) — RFC 2332. Maps tunnel overlay addresses to NBMA underlay addresses. Spokes dynamically register with the hub (NHS), and in Phase 3, the hub issues NHRP redirect messages that trigger spoke-to-spoke shortcut routes.

3. IPsec — Optional but standard in production. Applied via tunnel protection ipsec profile on the mGRE interface. Can use IKEv1 or IKEv2 for key exchange.

FlexVPN: The Unified IKEv2 Framework

FlexVPN collapses the three-protocol stack into IKEv2-driven sessions. The key components:

• IKEv2 Proposal — encryption (AES-CBC-256), integrity (SHA-512), PRF, and DH group
• IKEv2 Policy — matches proposals to sessions
• IKEv2 Profile — central config element: peer matching, auth method, authorization policies
• IKEv2 Keyring — stores pre-shared keys or references certificate trustpoints
• IPsec Profile — links the IKEv2 profile to tunnel interfaces (SVTI or DVTI)

Feature	DMVPN	FlexVPN
Tunnel protocol	mGRE (GRE multipoint)	IKEv2 (RFC 7296)
Address resolution	NHRP (RFC 2332)	IKEv2 Configuration Payload / NHRP
Key exchange	IKEv1 or IKEv2 (separate)	IKEv2 (integrated)
Smart defaults	None	Yes — auto proposal, policy, transform-set
Remote access	Requires AnyConnect/ASA	Native IKEv2 RA with DVTI
AAA integration	Limited (NHRP-level)	Full per-tunnel AAA via IKEv2 authorization
Spoke-to-spoke	NHRP shortcut + redirect	NHRP over IKEv2 or direct IKEv2 sessions
Multicast support	Native (mGRE)	Requires mGRE overlay
Typical config lines (hub)	25-35 lines	10-15 lines with smart defaults

DMVPN Phase 3 Spoke-to-Spoke: How It Actually Works

DMVPN Phase 3 enables direct spoke-to-spoke tunnels without routing traffic through the hub using two NHRP commands: ip nhrp redirect on the hub and ip nhrp shortcut on spokes.

When Spoke A sends traffic for Spoke B, the packet initially traverses the hub. The hub sends an NHRP Traffic Indication (redirect) back to Spoke A with Spoke B's NBMA address. Spoke A installs a /32 NHRP shortcut route in CEF, overriding the routing table's next-hop, and subsequent packets flow directly spoke-to-spoke.

Phase 3 gives you two key improvements over Phase 2: hierarchical hub designs (daisy-chaining) and summarized routing on the hub.

Hub Configuration (IOS-XE 17.x)

interface Tunnel0
 ip address 172.16.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN-KEY
 ip nhrp network-id 100
 ip nhrp redirect
 ip nhrp map multicast dynamic
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-IPSEC

The critical command: ip nhrp redirect — this instructs the hub to send NHRP Traffic Indication messages when it detects spoke-to-spoke traffic traversing it.

Spoke Configuration (IOS-XE 17.x)

interface Tunnel0
 ip address 172.16.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN-KEY
 ip nhrp network-id 100
 ip nhrp nhs 172.16.0.1 nbma 203.0.113.1 multicast
 ip nhrp shortcut
 ip nhrp registration timeout 60
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-IPSEC

The ip nhrp shortcut command is the Phase 3 enabler. On modern IOS-XE (17.x), it's enabled by default — run show run all | include nhrp shortcut to verify.

Verification

! DMVPN tunnel status and peer types
show dmvpn

! NHRP mappings (static vs dynamic)
show ip nhrp

! Confirm shortcut routes in CEF
show ip cef 10.100.0.3
  nexthop 203.0.113.3 Tunnel0    ← direct spoke-to-spoke

! Monitor NHRP redirect/shortcut activity
debug nhrp

FlexVPN Smart Defaults: 10 Lines Instead of 30

IKEv2 smart defaults auto-generate the proposal, policy, and transform-set: AES-256-CBC, SHA-512, DH Group 19 (256-bit ECP). A basic site-to-site VPN needs only a keyring and a profile.

Minimal FlexVPN Site-to-Site

! Step 1: Keyring with PSK
crypto ikev2 keyring FLEX-KEYS
 peer BRANCH1
  address 198.51.100.2
  pre-shared-key local HubKey123
  pre-shared-key remote Branch1Key456

! Step 2: IKEv2 profile
crypto ikev2 profile FLEX-PROFILE
 match identity remote address 198.51.100.2 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local FLEX-KEYS
 lifetime 86400

! Step 3: Tunnel interface (SVTI)
interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel destination 198.51.100.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile default

That's it. No explicit proposal, no policy, no transform-set. Compare this with DMVPN requiring explicit crypto isakmp policy, crypto ipsec transform-set, crypto ipsec profile, plus all the mGRE and NHRP commands.

Custom FlexVPN (When Smart Defaults Aren't Enough)

When you need specific crypto parameters or Next Generation Encryption:

crypto ikev2 proposal NGE-PROPOSAL
 encryption aes-gcm-256
 prf sha512
 group 20

crypto ikev2 policy NGE-POLICY
 proposal NGE-PROPOSAL

crypto ipsec transform-set NGE-TS esp-gcm 256
 mode transport

crypto ipsec profile NGE-IPSEC
 set transform-set NGE-TS
 set ikev2-profile FLEX-PROFILE

The Hybrid Approach: IKEv2 Over DMVPN

The most practical production pattern — IKEv2 encryption over DMVPN tunnels. You get DMVPN's dynamic spoke-to-spoke overlay with FlexVPN's stronger IKEv2 key exchange:

crypto ikev2 proposal DMVPN-IKEV2
 encryption aes-cbc-256
 integrity sha256
 group 14

crypto ikev2 policy DMVPN-POLICY
 proposal DMVPN-IKEV2

crypto ikev2 profile DMVPN-PROFILE
 match identity remote address 0.0.0.0
 authentication local pre-share
 authentication remote pre-share
 keyring local DMVPN-KEYS

crypto ipsec transform-set DMVPN-TS esp-aes 256 esp-sha256-hmac
 mode transport

crypto ipsec profile DMVPN-IPSEC
 set transform-set DMVPN-TS
 set ikev2-profile DMVPN-PROFILE

interface Tunnel0
 ! ... existing DMVPN config ...
 tunnel protection ipsec profile DMVPN-IPSEC

Critical: Use mode transport on the transform-set. The GRE header already provides encapsulation — mode tunnel adds a redundant IP header (20 bytes overhead per packet) and can cause silent drops at MTU boundaries.

When to Use Which Framework

Choose FlexVPN When

• Greenfield deployments with no existing DMVPN overlay
• Consolidating remote access — FlexVPN replaces separate AnyConnect/ASA RA with router-based IKEv2 RA using DVTI
• Per-tunnel policy enforcement (compliance, multi-tenancy) — IKEv2 authorization pushes unique QoS, firewall rules, IP assignments per spoke
• Certificate-based auth is mandated — FlexVPN's native PKI integration is cleaner
• ISE integration for posture assessment and EAP-based VPN authentication

Choose DMVPN When

• Brownfield — migration cost rarely justifies switching
• Multicast routing is required — mGRE natively supports ip nhrp map multicast dynamic
• Large-scale hub-and-spoke with 500+ spokes — DMVPN Phase 3 with dual-hub is battle-tested
• SD-WAN migration is planned — Cisco's migration tools convert DMVPN overlays to SD-WAN, not FlexVPN
• Team expertise — most teams have deeper DMVPN troubleshooting skills

Scalability Comparison

Dimension	DMVPN	FlexVPN
Adding spokes	Zero-touch on hub (NHRP auto-registration)	RADIUS policy entry or keyring addition
Hub redundancy	Dual NHS with ip nhrp nhs failover	IKEv2 profile + DPD failover
Spoke-to-spoke efficiency	NHRP shortcut (direct after first packet)	Direct IKEv2 or NHRP-over-IKEv2
Max spokes per hub	2,000-4,000 (hardware dependent)	1,000-2,000 (IKEv2 SA memory intensive)
Config management	Distributed (spoke-level)	Centralized (AAA/RADIUS)
Routing protocol overhead	EIGRP/BGP over mGRE	EIGRP/BGP over SVTI/DVTI

Common Pitfalls That Waste Hours

DMVPN Pitfalls

• Forgetting ip nhrp redirect on the hub — Phase 3 shortcut switching never activates. All traffic hairpins through the hub.
• mode tunnel instead of mode transport in IPsec transform-set — adds 20 bytes of unnecessary overhead, causes silent packet drops at MTU boundaries
• EIGRP next-hop-self on hub — default behavior rewrites next-hop to hub. For Phase 3 spoke-to-spoke routing: no ip next-hop-self eigrp <AS> on the hub tunnel interface
• Mismatched NHRP authentication strings — must match exactly between hub and all spokes. A single character mismatch causes silent registration failure
• Missing ip mtu 1400 and ip tcp adjust-mss 1360 — GRE + IPsec overhead requires MTU adjustment. Without it: pings work but SSH/HTTPS breaks on large packets

FlexVPN Pitfalls

• Leaving smart defaults when custom crypto is needed — explicitly no crypto ikev2 proposal default before custom proposals, otherwise smart defaults may still match
• Forgetting keyring local in the profile — omitting this causes %CRYPTO-4-IKEV2_AUTH_FAIL
• Using SVTI when DVTI is required — remote access needs Dynamic VTI (virtual-template) for per-user tunnels
• DPD timer mismatch — different Dead Peer Detection intervals between hub and spoke means one side tears down while the other thinks it's alive
• Certificate DN matching errors — match identity remote must match the cert Subject or SAN exactly

Key Verification Commands Reference

Command	What It Shows	Framework
show crypto ikev2 sa	IKEv2 SA state, encryption, lifetime	Both
show crypto ikev2 sa detailed	Full SA details including DPD, fragmentation	Both
show crypto ipsec sa	IPsec SA counters, encaps/decaps, errors	Both
show dmvpn	Peer table, type (static/dynamic), state	DMVPN
show ip nhrp	NHRP cache — address mappings, type, expiry	DMVPN
show ip nhrp nhs	NHS registration status and timers	DMVPN
show crypto ikev2 profile	Profile config and match criteria	FlexVPN
show crypto ikev2 stats	Negotiation counters and errors	FlexVPN
debug crypto ikev2	Real-time IKEv2 negotiation messages	Both

TL;DR

• FlexVPN (IKEv2) = Cisco's modern unified VPN framework. Fewer CLI lines, stronger crypto defaults, native EAP/certificate support
• DMVPN (mGRE + NHRP + IPsec) = dominant overlay in production. 70%+ of enterprise branch deployments still run Phase 3
• Best of both worlds: Run IKEv2 encryption over DMVPN — dynamic spoke-to-spoke overlay + modern key exchange
• Greenfield → FlexVPN. Brownfield → keep DMVPN. Migration path → IKEv2 over DMVPN first, then SD-WAN

---

Originally published at FirstPassLab. For more deep dives on networking protocols and infrastructure, visit firstpasslab.com.

---

AI Disclosure: This article was adapted from original research with AI assistance for formatting and editorial refinement. All technical content, configurations, and architectural analysis are based on official Cisco documentation and cited industry sources.