NetPilot
Back to Blog
Tutorial••8 min

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

Build a DMVPN Phase 3 hub-and-spoke with IPsec protection, NHRP, and spoke-to-spoke shortcuts — then verify the tunnels end to end.

S
Sarah Chen
Network Engineer

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.

                       [HUB]  Tunnel0 10.0.0.1/24
                      /      \      (mGRE + IPsec, NHS)
       underlay      /        \      underlay
                    /          \
        [SPOKE1] 10.0.0.2/24   [SPOKE2] 10.0.0.3/24
        LAN 192.168.1.0/24     LAN 192.168.2.0/24
              \__ Phase 3 spoke-to-spoke 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.

Try NetPilot Free

Build enterprise-grade network labs in seconds with AI assistance

Get Started Free