Cisco FlexVPN Site-to-Site with IKEv2 Virtual-Templates

FlexVPN is Cisco's IKEv2-based framework for IPsec on IOS and IOS XE, and it replaces four older designs — crypto maps, static VTI, DMVPN and EzVPN — with one configuration model. The feature that makes it worth learning is that IKEv2 itself carries the tunnel address and the routes: there is no IGP running over the overlay, no NHRP glue required for basic connectivity, and no crypto ACL to maintain. This guide builds a hub-and-spoke FlexVPN head end with a Virtual-Template, then covers the failure that wastes the most engineering time.

The five building blocks

• IKEv2 keyring — who is allowed to authenticate.
• IKEv2 profile — identity matching, authentication method, and the binding to a virtual-template and an authorization list.
• IKEv2 authorization policy — the payload: address pool, and crucially the routes pushed to the peer.
• AAA — the lookup that connects profile to authorization policy, local or RADIUS.
• Virtual-Template / Virtual-Access — the template is never used for traffic; IOS clones it into one Virtual-Access interface per authenticated peer.

Enable AAA and define what peers receive

aaa new-model
aaa authorization network FLEX-LIST local

ip local pool FLEX-POOL 10.0.9.10 10.0.9.100

ip access-list standard FLEX-ROUTES
 permit 10.20.10.0 0.0.0.255
 permit 10.30.0.0 0.0.255.255

crypto ikev2 authorization policy FLEX-AUTHOR-POL
 pool FLEX-POOL
 route set interface
 route set access-list FLEX-ROUTES

These three lines inside the authorization policy are the entire routing design. route set interface advertises the address of the (unnumbered) tunnel interface; route set access-list advertises every prefix the ACL permits. Both are delivered inside the IKEv2 exchange, so the spoke installs them as static routes at session setup.

Keyring, profile and IPsec profile

crypto ikev2 keyring FLEX-KEYRING
 peer SPOKES
  address 0.0.0.0 0.0.0.0
  pre-shared-key F1exVPN-Lab-Key

crypto ikev2 profile FLEX-PROF
 match identity remote fqdn domain lab.example
 identity local fqdn hub.lab.example
 authentication local pre-share
 authentication remote pre-share
 keyring local FLEX-KEYRING
 aaa authorization group psk list FLEX-LIST FLEX-AUTHOR-POL
 virtual-template 1

crypto ipsec profile FLEX-IPSEC
 set transform-set GCM256
 set ikev2-profile FLEX-PROF

Matching by FQDN domain rather than IP is what makes the hub spoke-agnostic: every new spoke announces an identity inside the domain and matches the same single line.

The Virtual-Template and the trap

interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel source GigabitEthernet2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile FLEX-IPSEC

If the Virtual-Template is missing tunnel source or tunnel mode ipsec ipv4, IKEv2 authenticates perfectly, the Virtual-Access interface is cloned, comes up, and then dies in a loop. The giveaway is a log line like this:

%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
%DMVPN-5-NHRP_NETID_UNCONFIGURED: Virtual-Access1: NETID : 1 Unconfigured (Tunnel: 0.0.0.0 NBMA: UNKNOWN)

Tunnel: 0.0.0.0 is the clue: the cloned interface never learned its own source address. Fix the template, not the crypto.

The spoke side

interface Tunnel0
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel source GigabitEthernet2
 tunnel mode ipsec ipv4
 tunnel destination 203.0.113.1
 tunnel protection ipsec profile FLEX-IPSEC

ip address negotiated is the spoke asking IKEv2 for a tunnel address from the hub's local pool; tunnel destination is static because the hub address is known even though spoke addresses are not.

Verification

show crypto session
show crypto ikev2 sa
show ip interface brief | include Virtual-Access
show ip local pool FLEX-POOL
show ip route | include Virtual-Access

The hub should show one Virtual-Access per spoke sharing the loopback address, plus S static routes for each spoke LAN pointing at the correct Virtual-Access. show ip local pool confirming Inuse addresses labelled IKEv2 Addr IDB is proof that the configuration payload exchange worked.

For a non-Cisco peer, the same IKEv2 parameters are configured in StrongSwan IKEv2 site-to-site configuration; if you need spoke-to-spoke shortcuts with NHRP path manipulation, read DMVPN Phase 3 NHRP shortcut guide next, because FlexVPN inherits the DMVPN behaviour for that scenario.

原文链接：https://pinglabz.com/flexvpn-site-to-site-configuration