NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

Understand and configure FlexVPN with IKEv2 on a spoke device using the exact commands and IPs from the reference. This lesson demonstrates IKEv2 smart defaults, the simple crypto-policy model, VTI-style (virtual tunnel) interfaces for route exchange, and the loopback/ipunnumbered alternative for predictable IKE identities. In production, this matters because FlexVPN/IKEv2 reduces configuration complexity and improves hub-and-spoke resilience compared with DMVPN — especially when spokes have DHCP or NAT on their WAN interfaces. A common real-world scenario: a remote spoke with dynamic WAN addressing needs two tunnels to two hubs for routing redundancy and BGP session peering.

Topology

ASCII diagram showing the devices and the exact IPs used in this lesson. All interface IPs are taken from the reference material.

Hub1 (Hub A) Internet Spoke (Remote)

Outside: 10.0.0.253 <---------> (public path) <---------> Outside: 1.1.1.1 Tunnel/Loopback: 172.16.1.253/32 Loopback1: 172.16.1.5/32 Loopback2: 172.16.1.7/32

Hub2 (Hub B)

Outside: 10.0.0.254 Tunnel/Loopback: 172.16.1.254/32

Notes:

Tunnels on the spoke terminate toward hub outside IPs 10.0.0.253 and 10.0.0.254.
Spoke uses either VTI IPs (172.16.1.5, .7 with mask 255.255.255.254) or loopbacks with ipunnumbered — both approaches are shown below.

Device Table

Device	Role	Key Interfaces / IDs
Hub1	VPN Hub	Outside: 10.0.0.253 ; Tunnel IP: 172.16.1.253
Hub2	VPN Hub	Outside: 10.0.0.254 ; Tunnel IP: 172.16.1.254
Spoke	VPN Spoke (this lesson)	Outside: 1.1.1.1 ; Tunnel1: 172.16.1.5 ; Tunnel2: 172.16.1.7

Quick Recap

This lesson continues the Hub-and-Spoke topology introduced in Lesson 1. We reuse the same hub addresses (10.0.0.253 and 10.0.0.254) and VTI/loopback IPs (172.16.1.253/.254 on the hubs; 172.16.1.5 and .7 on the spoke). No additional devices or new IPs are required beyond those shown above.

Key Concepts (theory before CLI)

IKEv2 policy and smart defaults: IKEv2 groups authentication and SA negotiation into concise policies. When enabled on the outside interface, the device listens for IKEv2 exchanges and applies the configured policy. In production, this reduces mismatch trouble compared to many legacy IKEv1 parameter permutations.
IPsec proposal and ipsec-profile (VTI): The IPsec proposal names the ESP algorithms; the ipsec-profile ties IKEv2 and IPsec settings together for tunnel interfaces. Tunnel protection references the ipsecprofile to bind the SA to the virtual tunnel.
Tunnel interfaces and route learning: Using VTI or ipunnumbered loopback enables routing protocols (BGP in this lab) to peer over the IPsec tunnel. In production, this allows dynamic routing to converge quickly after failover.
IKEv2 Local Identity and NAT/DHCP resilience: IKEv2 local identity (and per-tunnel identities) let spokes establish multiple distinct tunnels to the same hub and allows NAT or DHCP on the spoke WAN without breaking tunnel identification.
ipunnumbered on tunnels: Using a loopback per tunnel with ipunnumbered on the VTI provides fixed /32 identities that are stable across ISP changes — valuable for NAT and DHCP spoke deployments.

Step-by-step configuration

Step 1: Configure IKEv2 policy and enable IKEv2 on outside

What we are doing: Define a strong IKEv2 policy (encryption, integrity, DH group and PRF) and enable IKEv2 on the outside interface so the device will accept IKEv2 negotiations on that interface.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
crypto ikev2 enable outside

What just happened: The policy named (sequence) 10 is created; it instructs IKEv2 to use AES-256 for encryption, SHA-384 for integrity, DH group 19 for key exchange, and SHA-384 as the PRF. Enabling IKEv2 on the outside interface tells the device to listen for and accept IKEv2 negotiation packets on that physical interface (UDP/500 and UDP/4500 when NAT-T is present).

Real-world note: Using strong, modern algorithms (AES-256 and SHA-384) is recommended for long-lived site-to-site tunnels to meet compliance and security guidelines.

Verify:

show crypto ikev2 policy
Policy 10
 Encryption algorithm: AES-256
 Hash algorithm: SHA384
 Diffie-Hellman group: 19
 PRF algorithm: SHA384
 Lifetime: 86400 seconds

Step 2: Configure IPsec proposal and ipsec-profile (VTI profile)

What we are doing: Create an IPsec ESP proposal for the SA parameters and bind it into an ipsecprofile named VTI. This profile will be applied to the tunnel interfaces to protect traffic.

crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1
crypto ipsecprofile VTI
 set ikev2 ipsec-proposal IPSEC_PROP

What just happened: The IPSEC_PROP proposal sets ESP to use AES encryption and SHA-1 for ESP integrity (as in the reference). The ipsecprofile VTI references that proposal so tunnel interfaces can use it for IPsec protection. When a tunnel interface has "tunnel protection ipsecprofile VTI", the device will negotiate IPsec SAs according to this proposal after IKEv2 completes the IKE phase.

Real-world note: The ipsec-profile approach simplifies interface configuration: change the profile, and all tunnels referencing it inherit the new IPsec parameters.

Verify:

show crypto ipsec ikev2 ipsec-proposal
IPSEC_PROP
 Protocol: ESP
 Encryption: AES
 Integrity: SHA-1

show crypto ipsec profile
Profile: VTI
  IKEv2 Proposal: IPSEC_PROP

Step 3: Define tunnel-groups (peer identities and PSK)

What we are doing: Create static IPsec tunnel-groups for the two hub outside IPs and set the pre-shared-key authentication for both remote and local sides. Also include "route set interface" so the tunnel-group is prepared to support routes to the tunnel interface (used for VTI designs).

tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface

tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface

What just happened: Each tunnel-group maps an outside IP (the hub) to the pre-shared-key and specifies IKEv2 authentication for both directions (remote and local). The "ikev2 route set interface" prepares the ASA/FTD to accept route-based tunnels from those peers. These tunnel-groups are used by the IKEv2 negotiation to match an incoming connection to the correct per-peer policy.

Real-world note: Using per-peer tunnel-groups with PSKs is the simplest model for hub-and-spoke. For larger deployments, certificates or dynamic identity options are recommended.

Verify:

show running-config tunnel-group 10.0.0.253
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface

show running-config tunnel-group 10.0.0.254
tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface

Step 4: Create Tunnel interfaces (VTI) and bind ipsecprofile

What we are doing: Configure two tunnel interfaces (Tunnel1 and Tunnel2) with IP addresses and bind each to the ipsecprofile VTI so traffic traversing these interfaces is encrypted to the specified hub outside addresses.

interface Tunnel1
 nameif VTI
 ip address 172.16.1.5 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

interface Tunnel2
 nameif VTI2
 ip address 172.16.1.7 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.254
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

What just happened: Tunnel1 and Tunnel2 are created with the exact IPs from the reference. Each tunnel is associated with the outside interface as the source and points to the appropriate hub outside IP as tunnel destination. The "tunnel protection ipsec profile VTI" ties the previously configured ipsecprofile into the interface so that traffic sent into the tunnel is encrypted per the policy.

At the protocol level: when traffic egresses the Tunnel1 interface, the device will attempt IKEv2 negotiation with 10.0.0.253, establish IKE SA, then negotiate IPsec SAs as defined by IPSEC_PROP. Once SAs are up, traffic inside the tunnel will be encapsulated and forwarded to the hub outside IP.

Real-world note: Using VTIs makes integration with routing protocols straightforward; you can run BGP/OSPF over Tunnel interfaces rather than using crypto ACLs.

Verify:

show interface Tunnel1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.1.5/31
  Tunnel source: outside
  Tunnel destination: 10.0.0.253
  Tunnel mode: ipsec ipv4
  Tunnel protection profile: VTI

show interface Tunnel2
Tunnel2 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.1.7/31
  Tunnel source: outside
  Tunnel destination: 10.0.0.254
  Tunnel mode: ipsec ipv4
  Tunnel protection profile: VTI

Step 5: Optional — Use Loopbacks + ipunnumbered for stable IKE identity

What we are doing: Configure loopbacks for each tunnel and set tunnel interfaces to be ipunnumbered from those loopbacks. This provides a stable /32 identity for each tunnel endpoint even if the outside WAN address is DHCP or behind NAT.

interface Loopback1
 nameif loop1
 ip address 172.16.1.5 255.255.255.255

interface Loopback2
 nameif loop2
 ip address 172.16.1.7 255.255.255.255

interface Tunnel1
 ip unnumbered loop1
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

interface Tunnel2
 ip unnumbered loop2
 tunnel source interface outside
 tunnel destination 10.0.0.254
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

What just happened: Loopback1 and Loopback2 provide /32 addresses used as the logical identity of the tunnel endpoint. The Tunnel interfaces are configured to be ipunnumbered to those loopbacks, so the tunnel endpoint IP (and thus the IKEv2 local identity when using address identity) is stable. This avoids issues when the spoke outside interface is dynamic or NATed.

Real-world note: ipunnumbered is especially useful in cloud or mobile scenarios where the public IP can change; using a fixed loopback IP for IKE identity avoids tunnel matching failures at the hub.

Verify:

show running-config interface Loopback1
interface Loopback1
 nameif loop1
 ip address 172.16.1.5 255.255.255.255

show running-config interface Tunnel1
interface Tunnel1
 ip unnumbered loop1
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

Verification Checklist

Check 1: IKEv2 policy present — verify with show crypto ikev2 policy and confirm policy 10 uses AES-256/SHA384/group19.
Check 2: IPsec profile bound to tunnels — verify show crypto ipsec profile and show interface Tunnel1 to confirm "Tunnel protection profile: VTI".
Check 3: Tunnel interfaces up and addresses assigned — verify show interface Tunnel1 and show interface Tunnel2 show the configured IPs and tunnel destinations.
Check 4: Tunnel-groups configured for peers — verify show running-config tunnel-group 10.0.0.253 and ...10.0.0.254 contain the IKEv2 PSK attributes.

Common Mistakes

Symptom	Cause	Fix
IKEv2 negotiations fail / no SA established	Did not enable IKEv2 on the outside interface (`crypto ikev2 enable outside`)	Add `crypto ikev2 enable outside` and reattempt.
Tunnel shows no protection profile	Tunnel lacks `tunnel protection ipsec profile VTI` or profile typed incorrectly	Apply the correct profile: `tunnel protection ipsec profile VTI`. Verify spelling.
Hub rejects connection — no matching tunnel-group	Peer sent an identity that doesn't match hub tunnel-group (common with DHCP/NAT spoke)	Use loopback + ipunnumbered or configure the hub to accept the spoke identity; ensure PSKs match.
Routing over tunnel doesn't work	No routes to the tunnel peer IPs (VTIs require reachability) or BGP neighbors not configured	Add static/route entries or run routing protocol (e.g., BGP) with neighbors 172.16.1.253/.254. Ensure tunnel interfaces are up.
Mismatched crypto algorithms	IKEv2 policy or IPsec proposal differs between peers	Confirm both ends use the same `crypto ikev2 policy` and `crypto ipsec ikev2 ipsec-proposal` settings.

Key Takeaways

FlexVPN with IKEv2 simplifies hub-and-spoke VPNs: one IKEv2 policy + one ipsecprofile applied to VTIs handles negotiation and protection cleanly.
Using loopbacks + ipunnumbered stabilizes the IKE local identity for spokes that use DHCP or sit behind NAT — a common production requirement.
The ipsecprofile/VTI pattern decouples crypto parameters from interfaces; change the profile and all bound tunnels inherit the new settings.
Always verify both the IKEv2 policy and the ipsecprofile are configured and bound to tunnel interfaces; missing either will prevent an IPsec SA from being installed.

Tip: When moving from DMVPN to FlexVPN/IKEv2, expect fewer mistermed crypto mismatches and easier multi-hub spoke configurations because IKEv2 handles per-tunnel identities and route-based designs more naturally. Use the loopback/ipunnumbered method when spokes have non-static public addresses.

Lab complete — you now have a spoke configured for FlexVPN/IKEv2 with two hub peers using the exact commands and IPs from the reference. In the next lesson we'll focus on BGP peering over these VTIs and BGP route preference for failover.