Site-to-Site VPN Lab: IPsec & DMVPN, Step by Step

Site-to-site VPN is one of those topics you can't really learn from slides — you have to watch NHRP register, an IKEv2 SA come up, and a spoke-to-spoke shortcut form. This lab builds a DMVPN Phase 3 hub-and-spoke with IPsec protection on Cisco IOL (BYOI), so you can break it, fix it, and actually understand why the tunnel did or didn't come up.

Bottom line: A working DMVPN + IPsec lab means standing up a hub, two spokes, NHRP, an IKEv2/IPsec profile, and a routing protocol over the tunnel — easy to mistype, slow to debug. As of 2026, NetPilot deploys this topology with real CLIs in ~2 minutes — grab the prompt at the bottom and run it.

Lab topology

A single mGRE hub with two spokes. Routing runs over the tunnel (EIGRP here); DMVPN Phase 3 lets spokes build direct spoke-to-spoke tunnels on demand via NHRP redirect/shortcut.

• Overlay: 10.0.0.0/24 on Tunnel0 (mGRE, tunnel key 100)
• IPsec: IKEv2 + pre-shared key, transport mode protecting the GRE
• NHRP: hub is the next-hop server (NHS); Phase 3 uses redirect on the hub and shortcut on spokes

Hub configuration

crypto ikev2 keyring DMVPN-KR
 peer ANY
  address 0.0.0.0 0.0.0.0
  pre-shared-key NetPilotLab123
!
crypto ikev2 profile DMVPN-IKEV2
 match identity remote address 0.0.0.0
 authentication local pre-share
 authentication remote pre-share
 keyring local DMVPN-KR
!
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode transport
crypto ipsec profile DMVPN-IPSEC
 set transform-set TS
 set ikev2-profile DMVPN-IKEV2
!
interface Ethernet0/0
 description HUB underlay (NBMA / public)
 ip address 203.0.113.1 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip nhrp authentication NHRPKEY
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 no ip split-horizon eigrp 1
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-IPSEC
!
router eigrp 1
 network 10.0.0.0 0.0.0.255
 network 192.168.0.0 0.0.255.255

• Ethernet0/0 carries the hub's underlay (NBMA) address 203.0.113.1 — the tunnel source interface must exist and be reachable before the mGRE tunnel or any IPsec SA can form.
• tunnel mode gre multipoint + ip nhrp map multicast dynamic is what makes one hub interface serve many spokes.
• ip nhrp redirect on the hub is the Phase 3 trigger that tells spokes to build a direct shortcut.
• no ip split-horizon eigrp 1 lets the hub re-advertise one spoke's routes to another.

Underlay reachability. In a real deployment the underlay is the WAN/internet that carries traffic between the hub's 203.0.113.1 and each spoke's public address; in this lab all three nodes share the 203.0.113.0/24 underlay segment, so NHRP registration and IKEv2/IPsec to 203.0.113.1 can come up.

Spoke configuration (SPOKE1)

interface Ethernet0/0
 description SPOKE1 underlay (NBMA)
 ip address 203.0.113.2 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp authentication NHRPKEY
 ip nhrp map 10.0.0.1 203.0.113.1
 ip nhrp map multicast 203.0.113.1
 ip nhrp nhs 10.0.0.1
 ip nhrp network-id 1
 ip nhrp shortcut
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN-IPSEC
!
interface Ethernet0/1
 description SPOKE1 LAN
 ip address 192.168.1.1 255.255.255.0
!
router eigrp 1
 network 10.0.0.0 0.0.0.255
 network 192.168.1.0 0.0.0.255

• Ethernet0/0 is the spoke's underlay (NBMA) interface — 203.0.113.2 here, on the same 203.0.113.0/24 segment as the hub — and it's what tunnel source Ethernet0/0 rides on. Without an underlay address reachable to the hub, the NHRP map to 203.0.113.1 has nowhere to go.
• The Ethernet0/1 LAN (192.168.1.0/24) is what the EIGRP network statement advertises and what the verification ping sources from — without a real interface in that subnet, neither works.
• ip nhrp nhs 10.0.0.1 plus the static map to the hub's underlay address (203.0.113.1) registers the spoke with the hub.
• ip nhrp shortcut is the spoke side of Phase 3 — it installs the redirect and builds the direct spoke-to-spoke tunnel.

SPOKE2 is identical with Ethernet0/0 underlay 203.0.113.3, Tunnel0 ip address 10.0.0.3, and its own LAN 192.168.2.0/24. (The crypto IKEv2/IPsec stanzas are the same on every node.)

One config, many vendors. DMVPN itself is Cisco-specific, but the underlying IKEv2/IPsec is standards-based. Ask the agent for a Juniper or FRR/strongSwan peer and it generates the equivalent site-to-site IPsec config — no hand-translating between vendors.

Verification

Lead with the agent — one prompt checks the whole VPN and translates per-device output:

"Show DMVPN and IPsec status on the hub and both spokes, then trigger and confirm a direct spoke1-to-spoke2 tunnel."

NetPilot runs the checks across all three routers in parallel and flags any tunnel that's IKE instead of UP. To verify by hand, SSH in and run:

! Hub
show dmvpn detail
show crypto ikev2 sa
show ip nhrp
 
! Spoke1 — generate spoke-to-spoke traffic, then re-check
ping 192.168.2.1 source 192.168.1.1
show dmvpn detail

Expected: each spoke shows the hub as NHS and UP, the IKEv2 SAs are established, and after sourcing traffic between the spoke LANs a direct D (dynamic) entry appears between SPOKE1 and SPOKE2 — that's Phase 3 working.

Common DMVPN/IPsec gotchas

1. NHRP won't register. Wrong NHS address, mismatched ip nhrp authentication, or a tunnel key mismatch — all show as a spoke stuck without a mapping. Check the key and the NHS map first.
2. Tunnel up, IPsec down. GRE forms but show crypto ikev2 sa is empty or stuck — usually a pre-shared-key or IKEv2 profile mismatch. The overlay can look "up" while no traffic is actually encrypted.
3. No spoke-to-spoke shortcut. You have redirect on the hub but forgot shortcut on the spokes (or you're testing Phase 2 logic on a Phase 3 design). Shortcuts only appear after real spoke-to-spoke traffic.
4. MTU / fragmentation. GRE + IPsec overhead drops the effective MTU; large flows blackhole. Set ip mtu 1400 and ip tcp adjust-mss 1360 on the tunnel.
5. Recursive routing. If the tunnel's underlay route is learned through the tunnel, it flaps. Keep the underlay in a separate routing process (or static).

Build this lab with AI

Skip the typo-hunting and describe the intent:

"Build a DMVPN Phase 3 lab with one Cisco IOL hub and two spokes. Protect the mGRE tunnels with IKEv2 + IPsec (pre-shared key), run EIGRP over the overlay, and advertise a LAN behind each spoke. Verify NHRP registration, IPsec SAs, and a direct spoke-to-spoke shortcut."

NetPilot generates the hub and spoke configs, the crypto profiles, and the routing, deploys to cloud containerlab, and confirms the tunnels, then you SSH in to break and rebuild them. Iterate conversationally ("add a third spoke" or "swap PSK for certificate auth") and it updates every node.

Copy-paste ready: Grab the DMVPN hub-and-spoke prompt from our example library, or the site-to-site IPsec VPN prompt for the policy-based variant.

Want to practice VPNs without the setup? Spin one up in an online network lab, or let the AI network emulator build the IPsec/DMVPN configs from a prompt. Related: BGP Multi-Vendor Lab and FRRouting in the Cloud. Try NetPilot — describe any VPN topology and get a working lab in ~2 minutes.