Implement Site-to-Site FlexVPN with Local AAA Authorization

Overview

FlexVPN is Cisco’s IKEv2-based framework for site-to-site and remote-access VPNs on IOS. In the design built here, the hub hands each branch an address and a set of routes inside the IKEv2 exchange itself, so the tunnel needs no routing protocol. The part that trips people up is authorization: get the policy lookup wrong and the branch fails with an authentication error while its key is correct. This lesson migrates the DMVPN branches from the previous lesson onto FlexVPN, with the policies held in the hub’s local AAA.

Terminology: The Four Pieces on the Hub

A FlexVPN hub rests on four key components, each with one job (the IKEv2 proposal, keyring, AAA method list and pools sit underneath them):

• Virtual template — a tunnel interface that is never used directly. Each branch that connects gets a virtual-access interface cloned from it, with that branch’s outside (NBMA) address as the tunnel destination.

• IKEv2 profile — the rules for accepting a peer: which identities match, how they authenticate, and which virtual template to clone.

• Name mangler — Cisco’s FlexVPN guide says it is “used to derive the username for IKEv2 authorization … from the peer IKE identity.” It trims an identity such as branch-1.example.com down to a username such as branch-1. It reads whatever identity type the peer sends: fqdn {all | domain | hostname}, email {all | domain | username}, a field of a certificate’s distinguished name (dn common-name, dn organization-unit and so on), or an EAP identity.

• IKEv2 authorization policy — what a peer gets once it is authorized: an address pool, and the routes to push. With local AAA, these policies live on the hub, named by the username the mangler produces. The profile can run two lookups.

  • aaa authorization group is meant for the generic part of an identity, such as a domain shared by many peers.
  • aaa authorization user is meant for the peer-specific part, such as one hostname.
  • When both run, their attributes merge, and override on the group line lets the group win.

  This lesson uses a group lookup keyed by the hostname, which gives one policy per branch with a single line. A policy can also pull per-session interface settings from an aaa attribute list.

Engine Behavior: How a Branch Gets Its Address and Routes

IKEv2 has a configuration payload (RFC 7296, section 3.15) that carries attributes such as an internal address and internal subnets in IKE_AUTH. FlexVPN uses it for site-to-site routing, and adds a Cisco-specific step in which the branch advertises its own routes back. Here is one branch coming up, in the order an IKEv2 debug logs it:

Enlarge figure: A packet walk with three lanes: the Branch's spoke tunnel, the Hub's IKEv2 profile, and Local AAA, the method list on the hub. Step 1, IKE_SA_INIT from the branch using DH group 19. Step 2, IKE_AUTH with an empty configuration request. Step 3, the hub asks local AAA for the username taken from the mangled identity. Step 4, local AAA returns the policy with that name. Step 5, the hub sends a configuration reply with an address and routes. Step 6, the branch sends a configuration set with its own LAN. Step 7, the hub acknowledges. A footer states that there is no routing protocol on the tunnel, and IKEv2 carries the address and routes

1. The branch sends an empty request (figure steps 1–2). Its IKE_AUTH carries its FQDN identity and a config request with blank ipv4-addr and ipv4-subnet attributes: “give me an address, tell me your networks.”
2. The hub authorizes it locally (steps 3–4). The mangler turns the identity into a username, and the local AAA list returns the authorization policy with that name.
3. The hub replies with the policy’s contents (step 5). The IKE_AUTH response carries a config reply: an address from the branch’s pool, plus the subnets in the policy’s route set.
4. The branch answers with its own networks (steps 6–7). Right after IKE_AUTH, the branch sends a config set in an INFORMATIONAL exchange listing its LAN, and the hub acknowledges it. The CFG_SET and CFG_ACK message types are standard IKEv2 (RFC 7296, section 3.15); using them to advertise routes back to the hub is FlexVPN’s.

IOS on both sides installs what it received as static routes on the tunnel. No routing protocol runs over it.

Design Choice: FlexVPN or DMVPN

Both designs can run on IKEv2 and IPsec (DMVPN also works with IKEv1). What differs is who does the signalling, and it shows in the configuration:

Enlarge figure: DMVPN and FlexVPN compared side by side. DMVPN is mGRE plus NHRP with IPsec added, and its IPsec flow is permit 47, GRE; its configuration shows tunnel mode gre multipoint, ip nhrp nhs or redirect, and a routing protocol over the tunnel; spokes register with an NHS, routes come from a routing protocol, and per-peer policy comes from profiles and routing. FlexVPN has IKEv2 do the signalling, and its IPsec flow is any to any; its configuration shows tunnel mode ipsec ipv4, a virtual template on the hub, and an IKEv2 route set; the hub pushes the address, routes travel in the config exchange, and per-peer policy comes from an AAA lookup. A footer states that the same IKEv2 proposal and policy serve both, and the profile decides which peer is which

Choose FlexVPN when branches need to be treated differently: their own addresses, their own routes, their own access. In this design every branch session passes through an authorization lookup, from local AAA or, at scale, from RADIUS, and that lookup is the natural place to hang per-peer policy. (FlexVPN does not require one: a statically addressed VTI with an IKEv2 profile and ordinary routing runs without AAA at all.) DMVPN can differentiate peers too, but through profiles, credentials and routing policy spread across the config. Choose DMVPN when you need direct spoke-to-spoke paths across a large cloud today and the branches are alike: Phase 3 builds those shortcuts as part of its design (ip nhrp redirect and ip nhrp shortcut), where FlexVPN needs NHRP added to do the same.

Lab Reference

This lesson uses the SVPN lab topology. All examples reference these specific devices and IP addresses.

Topology

Enlarge figure: The lesson's lab slice. R-ISP-01 in the centre is the internet. R-HUB-01 above it at 198.51.100.10, with Loopback11 at 10.255.11.254 as the source of its virtual template. R-BRANCH-01 at 192.0.2.2, Tunnel11 10.255.11.1, with WS-BRANCH-01 at 10.20.1.10 behind it; R-BRANCH-02 at 192.0.2.6, Tunnel11 10.255.11.2, with WS-BRANCH-02 at 10.20.2.10 behind it. Solid lines are the underlay through R-ISP-01; dashed lines are the two FlexVPN tunnels, one per branch, each landing on its own Virtual-Access interface on the hub.

The physical lab is unchanged from the DMVPN lesson. What changes is the overlay: two separate IPsec tunnels, each branch to the hub, instead of one multipoint cloud. Branch-to-branch traffic now crosses the hub.

Configuration

Scenario 1: Move Both Branches to FlexVPN With Per-Branch Policies

The network team wants each branch to get a fixed tunnel address and its routes from the hub, with the policy for every branch held in one place. DMVPN stays configured but shut, for rollback.

Step 1 — retire DMVPN and turn on local AAA. On all three routers:

! Step 1a: keep the DMVPN config, stop using it
interface Tunnel0
 shutdown
! Step 1b: authorization comes from the local database
aaa new-model
aaa authorization network FLEX-LOCAL local

Step 2 — the hub’s per-branch policies. On R-HUB-01:

! Step 2a: one single-address pool per branch, and what HQ offers
ip local pool POOL-BR1 10.255.11.1 10.255.11.1
ip local pool POOL-BR2 10.255.11.2 10.255.11.2
ip access-list standard ACL-HQ-ROUTES
 permit 10.10.10.0 0.0.0.255

! Step 2b: the mangler keeps the hostname part of the FQDN
crypto ikev2 name-mangler NM-HOST
 fqdn hostname
! Step 2c: one policy per branch, named for the mangled username
crypto ikev2 authorization policy r-branch-01
 pool POOL-BR1
 route set interface
 route set access-list ACL-HQ-ROUTES
crypto ikev2 authorization policy r-branch-02
 pool POOL-BR2
 route set interface
 route set access-list ACL-HQ-ROUTES

route set interface pushes the hub’s own tunnel address, 10.255.11.254, so the branch has a route to the far end of its tunnel. route set access-list pushes every prefix the ACL permits.

Step 3 — the hub’s profile and template. On R-HUB-01:

! Step 3a: one key for the whole domain, and who matches
crypto ikev2 keyring KR-FLEX
 peer BRANCHES
  identity fqdn domain securitylessons.lab
  pre-shared-key SVPN-lab-FLEX-psk
crypto ikev2 profile IKEV2-FLEX-HUB
 match identity remote fqdn domain securitylessons.lab
 identity local fqdn r-hub-01.securitylessons.lab
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-FLEX
 aaa authorization group psk list FLEX-LOCAL name-mangler NM-HOST
 virtual-template 11

! Step 3b: IPsec in tunnel mode, and the template every branch clones
crypto ipsec transform-set TS-FLEX esp-aes 256 esp-sha256-hmac
 mode tunnel
crypto ipsec profile IPSEC-FLEX
 set transform-set TS-FLEX
 set ikev2-profile IKEV2-FLEX-HUB
interface Loopback11
 ip address 10.255.11.254 255.255.255.255
interface Virtual-Template11 type tunnel
 description FlexVPN hub - one virtual-access per branch
 ip unnumbered Loopback11
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-FLEX

This time the transform set uses tunnel mode, and it has to: Cisco’s VTI guide, in its IOS XE 17.x edition, states that “the IPsec transform set must be configured in tunnel mode only.” A virtual tunnel interface has no GRE underneath, so ESP tunnel mode is what encapsulates the original packet, and a new outer IP header carries the ESP packet.

Step 4 — a spoke. On R-BRANCH-01 (on R-BRANCH-02, use r-branch-02, ACL-BR2-LAN and 10.20.2.0):

! Step 4a: what this branch offers back, in the default local policy
ip access-list standard ACL-BR1-LAN
 permit 10.20.1.0 0.0.0.255
crypto ikev2 authorization policy default
 route set interface
 route set access-list ACL-BR1-LAN

! Step 4b: identify by FQDN, and ask local AAA for the default policy
crypto ikev2 keyring KR-FLEX
 peer R-HUB-01
  address 198.51.100.10
  pre-shared-key SVPN-lab-FLEX-psk
crypto ikev2 profile IKEV2-FLEX-SPOKE
 match identity remote fqdn r-hub-01.securitylessons.lab
 identity local fqdn r-branch-01.securitylessons.lab
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-FLEX
 aaa authorization group psk list FLEX-LOCAL default

! Step 4c: the tunnel asks for its address instead of having one
crypto ipsec transform-set TS-FLEX esp-aes 256 esp-sha256-hmac
 mode tunnel
crypto ipsec profile IPSEC-FLEX
 set transform-set TS-FLEX
 set ikev2-profile IKEV2-FLEX-SPOKE
interface Tunnel11
 ip address negotiated
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 198.51.100.10
 tunnel protection ipsec profile IPSEC-FLEX

Verify: Each Branch Got Its Own Address and the HQ Routes

R-BRANCH-01# show ip interface brief | include Tunnel11|Gigabit
GigabitEthernet0/0         192.0.2.2       YES TFTP   up                    up      
GigabitEthernet0/1         10.20.1.1       YES TFTP   up                    up      
Tunnel11                   10.255.11.1     YES manual up                    up
R-BRANCH-01# show ip route | begin Gateway
Gateway of last resort is 192.0.2.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.0.2.1
      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
S        10.10.10.0/24 is directly connected, Tunnel11
C        10.20.1.0/24 is directly connected, GigabitEthernet0/1
L        10.20.1.1/32 is directly connected, GigabitEthernet0/1
C        10.255.11.1/32 is directly connected, Tunnel11
S        10.255.11.254/32 is directly connected, Tunnel11

R-BRANCH-01 holds 10.255.11.1, the one address in POOL-BR1, so the mangler matched it to policy r-branch-01. The two S routes on Tunnel11 are the hub’s route set. Nobody typed them, and no EIGRP neighbour exists any more.

Verify: The Hub Built One Virtual-Access per Branch

R-HUB-01# show ip interface brief | include Virtual|Loopback11|Tunnel0
Loopback11                 10.255.11.254   YES manual up                    up      
Tunnel0                    10.255.10.254   YES manual administratively down down    
Virtual-Access1            10.255.11.254   YES unset  up                    up      
Virtual-Access2            10.255.11.254   YES unset  up                    up      
Virtual-Template11         10.255.11.254   YES unset  up                    down
R-HUB-01# show ip route static | begin Gateway
Gateway of last resort is 198.51.100.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 198.51.100.254
      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
S        10.20.1.0/24 is directly connected, Virtual-Access1
S        10.20.2.0/24 is directly connected, Virtual-Access2
S        10.255.11.1/32 is directly connected, Virtual-Access1
S        10.255.11.2/32 is directly connected, Virtual-Access2

Each branch landed on its own virtual-access interface, and each branch’s config set became a static route through it. The template itself stays up/down: it is a pattern, not a tunnel. Cloning is visible directly:

R-HUB-01# show interfaces virtual-access 1 configuration
Virtual-Access1 is in use, but purpose is unknown

Derived configuration : 322 bytes
!
interface Virtual-Access1
 description FlexVPN hub - one virtual-access per branch
 ip unnumbered Loopback11
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 192.0.2.2
 tunnel protection ipsec profile IPSEC-FLEX
 no tunnel protection ipsec initiate
end

The template’s lines, plus two the hub added itself. tunnel destination is filled in with R-BRANCH-01’s outside (NBMA) address, not its tunnel address. no tunnel protection ipsec initiate tells the virtual-access never to start IKEv2 itself: the hub only answers, and branches always dial in.

Verify: The Policies Are the Ones You Wrote

R-HUB-01# show crypto ikev2 authorization policy
 IKEv2 Authorization Policy : default
  route set interface
  route accept any tag : 1 distance : 1 
 IKEv2 Authorization Policy : r-branch-01
  IPV4 Address Pool : POOL-BR1
  route set interface
  route set acl: ACL-HQ-ROUTES
  route accept any tag : 1 distance : 1 
 IKEv2 Authorization Policy : r-branch-02
  IPV4 Address Pool : POOL-BR2
  route set interface
  route set acl: ACL-HQ-ROUTES
  route accept any tag : 1 distance : 1

Two things here were never typed. The first is the policy named default: nothing in Step 2 creates it. It is one of IKEv2’s smart defaults, built-in objects IOS supplies so a minimal FlexVPN works without them (the same mechanism supplied the default proposal the DMVPN lesson replaced in its Step 3a). The hub never uses it here, because its group lookup always names a branch’s own policy.

The second is route accept any tag : 1 distance : 1 on every policy. It is why the hub installed each branch’s config set without being told to. The full form is route accept any [tag value] [distance value]: the tag marks the installed routes so you can match them in a route map, and the distance is their administrative distance, so a higher value lets another path, such as a primary circuit, win when both exist. This image shows distance 1; Cisco’s 15M&T guide shows the smart default with distance 2, so read your own output.

Scenario 2: Let the Branches Reach Each Other Through the Hub

Branch 1 now needs to reach branch 2. Each branch only knows HQ’s prefix, so traffic between them has nowhere to go:

R-BRANCH-01# ping 10.20.2.10 repeat 3
Sending 3, 100-byte ICMP Echos to 10.20.2.10, timeout is 2 seconds:
U.U
Success rate is 0 percent (0/3)

U is an ICMP unreachable. With no route to 10.20.2.0/24, the branch followed its default route to R-ISP-01, which has no route to it either.

Step 5 — add the branch summary to the hub’s route set. One line on R-HUB-01, then renegotiate:

! Step 5: every branch LAN, pushed to every branch
ip access-list standard ACL-HQ-ROUTES
 permit 10.20.0.0 0.0.255.255
end
clear crypto session

Route sets are sent only when a session forms, so existing branches see the change after the session is rebuilt. A bare clear crypto session clears every session on the router, and the spokes must then re-establish them; in production, clear only the affected peer (clear crypto session remote 192.0.2.2). On this lab the spokes took 53 seconds to dial back in, and a ping in that window fails.

Verify: The Summary Arrived, and Branch to Branch Works

R-BRANCH-01# show ip route static | begin Gateway
Gateway of last resort is 192.0.2.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.0.2.1
      10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
S        10.10.10.0/24 is directly connected, Tunnel11
S        10.20.0.0/16 is directly connected, Tunnel11
S        10.255.11.254/32 is directly connected, Tunnel11

WS-BRANCH-01:~$ traceroute -n -w 2 10.20.2.10
traceroute to 10.20.2.10 (10.20.2.10), 30 hops max, 46 byte packets
 1  10.20.1.1  3.063 ms  4.011 ms  1.705 ms
 2  10.255.11.254  9.400 ms  9.297 ms  10.292 ms
 3  10.255.11.2  16.805 ms  18.617 ms  22.301 ms
 4  10.20.2.10  21.539 ms  17.210 ms  14.614 ms

Branch 1 to branch 2 crosses the hub (10.255.11.254), then enters R-BRANCH-02’s tunnel (10.255.11.2). This is hub-and-spoke on purpose. FlexVPN can build spoke-to-spoke shortcuts with NHRP, but objective 1.3 asks for local AAA, and one variable at a time keeps it readable.

Verify: FlexVPN, Not DMVPN, From the Session Alone

R-BRANCH-01# show crypto session
Crypto session current status

Interface: Tunnel11
Profile: IKEV2-FLEX-SPOKE
Session status: UP-ACTIVE     
Peer: 198.51.100.10 port 500 
  Session ID: 5  
  IKEv2 SA: local 192.0.2.2/500 remote 198.51.100.10/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map

permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 says this is a route-based virtual tunnel interface, which encrypts everything routed into it. The DMVPN lesson’s session read permit 47: GRE only. A plain static VTI shows the same any-to-any flow, so for objective 4.3 the FlexVPN tell is the pair: this flow, plus ip address negotiated on the spoke or a virtual template and an IKEv2 authorization policy on the hub.

Troubleshooting

Symptom: A spoke’s Tunnel11 stays up/down with no address, and the spoke logs NOTIFY(AUTHENTICATION_FAILED) although the key is right.

This was reproduced on the lab by changing R-BRANCH-02’s identity to r-branch-03.securitylessons.lab, a name with no policy on the hub.

1. show ip interface brief | include Tunnel11 on the spoke. (Should show an address.) unassigned means the config reply never arrived.

2. debug crypto ikev2 on the hub for one retry, then undebug all. (Should show the username you expect.) On a hub with many branches, send debug to the log buffer rather than the console. The lab’s hub printed:

   · textCopy

   *Sep 26 03:15:17.943: IKEv2:Using mlist FLEX-LOCAL and username r-branch-03 for group author request
   *Sep 26 03:15:17.944: IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authorisation request sent
   *Sep 26 03:15:18.090: IKEv2:(SA ID = 1):[AAA -> IKEv2] Received AAA authorisation response
   *Sep 26 03:15:18.091: IKEv2-ERROR:AAA authorization request failed
   *Sep 26 03:15:18.091: IKEv2-ERROR:(SESSION ID = 0,SA ID = 1):AAA group authorization failed
   *Sep 26 03:15:18.093: IKEv2:(SESSION ID = 34,SA ID = 1):Verification of peer's authentication data FAILED
   *Sep 26 03:15:18.093: IKEv2:(SESSION ID = 34,SA ID = 1):Sending authentication failure notify

   If the username has no policy of that name: that is the cause. Fix: create the policy, or correct the spoke’s identity.

3. show crypto ikev2 authorization policy on the hub. (Should list a policy named exactly as the mangled username.)

Symptom: Branches reach HQ but not each other.

1. show ip route static on a branch. (Should show a route covering the other branch’s LAN via Tunnel11.) If not: the hub’s route set does not include it. Add it to the ACL and clear crypto session.
2. show ip route static on the hub. (Should show every branch LAN via a virtual-access interface.) If one is missing, that branch’s authorization policy default is not sending its route set.

Symptom: A change to a route set or pool has no effect.

1. Route sets and addresses travel only in the config exchange. (Existing sessions keep what they got.) Run clear crypto session for the affected peer, and expect the branch to be unreachable until it dials back in.

🎥 [Video: two routing tables from the same branch; FlexVPN as IKEv2 doing the signalling; the hub’s template, profile, mangler and local policies; building the hub and a spoke and reading the pushed routes; the debug walked line by line; the branch summary pushed and traced; the broken identity and its AUTHENTICATION_FAILED. Matches video.script_outline. Runtime: ~10 minutes]

Up next: Remote Access VPN & Cisco Secure Client Architecture — the next module moves from site-to-site to remote access, where the same IKEv2 profile and authorization ideas serve individual users instead of branches.