Securing DMVPN with IPsec Profiles (IKEv2)

Everything DMVPN sends is cleartext. GRE is an envelope with the contents printed on the outside, and a DMVPN cloud over the internet without encryption is a packet capture away from a very bad week. The fix is IPsec applied as a tunnel protection profile: IKEv2 negotiates keys, ESP encrypts every GRE packet, and the DMVPN machinery (NHRP, routing, shortcuts) runs through it untouched and unaware. This article builds the whole stack on two Catalyst 8000v routers running IOS XE 17.18, with every show command captured live. It assumes the working Phase 3 configuration from the config walkthrough and is part of the DMVPN complete guide; for the general theory of stacking GRE and IPsec, see GRE over IPsec.

The Design: Transport Mode ESP Around GRE

DMVPN encryption is GRE over IPsec in transport mode. The GRE packet (which already carries the tunnel semantics, the multipoint behavior, and the NHRP messages) gets its payload encrypted by ESP between the same two underlay addresses. Transport mode is preferred over tunnel mode because the crypto endpoints and the GRE endpoints are identical, so tunnel mode's extra IP header would carry redundant information at the cost of 20 bytes per packet. The proxy identity becomes protocol 47 (GRE) host-to-host, which you will see verbatim in the SA output below.

Because encryption binds to the interface, not to peers, one profile on the hub's mGRE interface covers every current and future spoke, and (in a full Phase 3 mesh) spoke-to-spoke shortcut tunnels negotiate their own SAs on demand using the same profile. Zero per-peer crypto configuration, same as the rest of DMVPN.

Step 1: IKEv2 Proposal and Policy

IKEv2 replaces the old crypto isakmp world (if your reference config says isakmp anywhere, it is an IKEv1 design and a decade stale). The proposal picks the SA cryptography; the policy activates the proposal:

crypto ikev2 proposal PL-IKEV2-PROP
 encryption aes-cbc-256
 integrity sha256
 group 19
!
crypto ikev2 policy PL-IKEV2-POLICY
 proposal PL-IKEV2-PROP

AES-256, SHA-256, and elliptic-curve group 19 are a solid 2026 baseline. One IOS XE gotcha worth knowing: if you pick an AEAD cipher like aes-gcm-256 for the proposal, you must configure a prf instead of integrity (GCM authenticates itself), and the parser reminds you mid-configuration.

Step 2: Keyring and Profile

The keyring stores the pre-shared keys; the profile matches peers and ties authentication together. The hub cannot know spoke addresses in advance, so its keyring matches any peer:

! HUB
crypto ikev2 keyring PL-KEYRING
 peer SPOKES
  address 0.0.0.0 0.0.0.0
  pre-shared-key PingLabz-DMVPN-Key
!
crypto ikev2 profile PL-IKEV2-PROFILE
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local PL-KEYRING

Spokes can be tighter, keying specifically for the hub (address 203.0.113.1 in the peer block). A wildcard PSK is the lab-friendly choice and the production compromise everyone makes at small scale; at real scale the answer is certificates (swap pre-share for rsa-sig and a PKI trustpoint) so a stolen branch router does not compromise the whole cloud's key.

Step 3: Transform Set and IPsec Profile

crypto ipsec transform-set PL-TSET esp-gcm 256
 mode transport
!
crypto ipsec profile PL-DMVPN-IPSEC
 set transform-set PL-TSET
 set ikev2-profile PL-IKEV2-PROFILE

ESP-GCM-256 is authenticated encryption in one pass, the modern default for data plane crypto. The IPsec profile is just a binding object: this transform set, keyed by this IKEv2 profile.

Step 4: One Line on the Tunnel

interface Tunnel0
 tunnel protection ipsec profile PL-DMVPN-IPSEC

Same line on hub and spokes. Nothing else in the DMVPN configuration changes, which you can prove to yourself by diffing the tunnel interface before and after: NHRP maps, network-id, redirect and shortcut, tunnel key, all identical.

Verification: The Three-Command Ladder

First rung: is there an IKEv2 SA? On the hub, seconds after the spoke's first registration attempt:

HUB# show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         203.0.113.1/500       203.0.113.2/500       none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/7 sec
      Local spi: DE52FFEAD3BDC29C       Remote spi: 5C69D52BF021BA11

READY means IKE_SA_INIT and IKE_AUTH both completed: negotiation, key exchange, and PSK authentication all succeeded. Second rung: are child SAs actually encrypting? The counters answer, and the proxy identity shows the transport-mode GRE design in the flesh:

SPOKE1# show crypto ipsec sa
interface: Tunnel0
   local  ident (addr/mask/prot/port): (203.0.113.2/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (203.0.113.1/255.255.255.255/47/0)
    #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
    #pkts decaps: 26, #pkts decrypt: 26, #pkts verify: 26
     current outbound spi: 0xAC32FE02(2889022978)

     inbound esp sas:
      spi: 0x58377064(1480028260)
        transform: esp-gcm 256 ,
        in use settings ={Transport, }
        Status: ACTIVE(ACTIVE)
     outbound esp sas:
      spi: 0xAC32FE02(2889022978)
        transform: esp-gcm 256 ,
        in use settings ={Transport, }
        Status: ACTIVE(ACTIVE)

Protocol 47 host-to-host, transport mode, GCM, and matching encrypt/decrypt counters climbing together. If encaps grows while the far side's decaps does not, something between the routers is eating ESP (usually a firewall). Third rung: the one-screen summary that ties the crypto session to the tunnel:

SPOKE1# show crypto session
Interface: Tunnel0
Profile: PL-IKEV2-PROFILE
Session status: UP-ACTIVE
Peer: 203.0.113.1 port 500
  IKEv2 SA: local 203.0.113.2/500 remote 203.0.113.1/500 Active
  IPSEC FLOW: permit 47   host 203.0.113.2 host 203.0.113.1
        Active SAs: 2, origin: crypto map

And the DMVPN-native view folds crypto into the peer table, confirming the overlay itself is protected (Protect "PL-DMVPN-IPSEC") with live enc/dec counters per session:

HUB# show dmvpn detail
Interface Tunnel0 is up/up, Addr. is 10.0.0.1, VRF "global"
   Tunnel Src./Dest. addr: 203.0.113.1/Multipoint, Tunnel VRF "global"
   Protocol/Transport: "multi-GRE/IP", Protect "PL-DMVPN-IPSEC"
Type:Hub, Total NBMA Peers (v4/v6): 1

  Crypto Session Status: UP-ACTIVE
  IPSEC FLOW: permit 47   host 203.0.113.1 host 203.0.113.2
        Inbound:  #pkts dec'ed 30 drop 0 life (KB/Sec) 4607996/3549
        Outbound: #pkts enc'ed 30 drop 0 life (KB/Sec) 4607997/3549

Meanwhile EIGRP formed its adjacency straight through the encryption, and a 20-packet ping across the overlay ran 100 percent, which is the operational point: the overlay does not know it is encrypted.

If Your Reference Config Says "isakmp", Translate It

A huge fraction of DMVPN material online still shows IKEv1, so it is worth mapping the old objects to the new ones. crypto isakmp policy becomes the IKEv2 proposal plus policy pair. crypto isakmp key ... address becomes a keyring peer block. The implicit IKEv1 peer matching becomes an explicit IKEv2 profile with match identity. The transform set survives with the same name and syntax, and the IPsec profile gains a set ikev2-profile line. Beyond syntax, IKEv2 buys real things: built-in NAT traversal and DPD, fewer round trips to establish, EAP support, anti-DoS cookies for hubs facing the open internet, and cleaner rekeying. There is no defensible reason to deploy new DMVPN on IKEv1 in 2026, and mixed clouds during migration work fine because IKE version is negotiated per peer pair.

MTU: The Crypto Tax on Every Packet

Encryption raises the encapsulation overhead you already budgeted for GRE. Transport-mode ESP with GCM adds roughly 30 to 40 bytes on top of GRE's 24 (SPI, sequence number, IV, ICV, padding), and the arithmetic explains the numbers this cluster standardizes on: 1500 minus GRE minus ESP lands comfortably above 1400, so ip mtu 1400 guarantees the encrypted result fits any sane transport, and ip tcp adjust-mss 1360 keeps TCP flows from ever producing a packet that needs fragmenting (1400 minus 40 bytes of IP+TCP headers). The failure mode when you skip this is ugly precisely because it is partial: pings work, small requests work, and bulk transfers hang when a DF-marked full-size segment meets the tunnel and the ICMP unreachable gets filtered somewhere. The full diagnosis walkthrough, including how to prove it with size-swept pings, is in GRE MTU and fragmentation.

Also note what the SA output already told us: plaintext mtu 1466, path mtu 1500. IOS XE computes the usable plaintext size per SA, and comparing that number against your ip mtu is a quick sanity check that your budget holds on the actual negotiated cipher.

Lab Platform Notes (Learned the Hard Way)

Two things will save you an afternoon. First, IOL/IOL-XE images have no IPsec data plane, so DMVPN crypto labs need a real IOS XE image like Catalyst 8000v; the pure mGRE/NHRP work stays on the lightweight nodes. Second, a fresh Catalyst 8000v boots with no license level, and in that state the entire crypto subsystem is absent: crypto ikev2 config lines are rejected at boot and even show crypto ikev2 sa returns invalid input, which looks bafflingly like a corrupted image. The fix is license boot level network-advantage addon dna-advantage, write, reload, then apply the crypto configuration. Neither of these is a DMVPN problem, but both wear a DMVPN costume when you hit them.

Hardening Beyond the Profile

The profile encrypts; a deployable edge needs a little more. Reasonable additions: IKEv2 DPD (crypto ikev2 dpd 30 5 on-demand) so dead peers tear down instead of blackholing until SA expiry, an underlay ACL permitting only UDP/500, UDP/4500, and ESP from expected sources, NAT-T awareness for spokes behind NAT (IKEv2 detects it and floats to 4500 automatically; verify with show crypto ikev2 sa detail), certificates instead of wildcard PSKs at scale, and call admission control on hubs that terminate hundreds of SAs. NHRP authentication and tunnel keys remain useful misconfiguration fences underneath all of this, as covered in the NHRP deep dive.

Key Takeaways

DMVPN encryption is five small objects chained together: IKEv2 proposal, policy, keyring, profile, then an IPsec transform set and profile, applied with a single tunnel protection line per tunnel interface. Transport-mode ESP-GCM around GRE is the standard design, visible in the SA as permit 47 host A host B with {Transport} settings. Verify up the ladder (IKEv2 SA READY, IPsec counters climbing on both sides, crypto session UP-ACTIVE) before blaming DMVPN, and remember the overlay is deliberately ignorant of the crypto: registration, shortcuts, and routing behave identically encrypted or not. When the tunnel misbehaves for non-crypto reasons, continue to troubleshooting DMVPN, and find the whole cluster in the DMVPN complete guide.