> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # FlexVPN Spoke Has No Routes? 6 IKEv2 Authorization Faults - URL: https://www.pinglabz.com/flexvpn-no-routes-authorization-lab/ - Published: 2026-10-21T10:17:27.000Z - Updated: 2026-10-21T10:17:27.000Z - Description: Six FlexVPN authorization faults, built in my home lab on Cisco IOL 17.18.2. Missing hub references stopped establishment; other faults kept READY SAs while losing routes. Real outputs separate received prefixes, installed routes and host forwarding. - Author: Jaime - Tags: FlexVPN, IPsec, VPN, Troubleshooting, Cisco, Security, IKEv2 A FlexVPN spoke with no routes can have two very different problems: it never established a session, or it established one and still lacks the prefixes it needs. In this lab, removing the hub's `aaa authorization group psk list` reference caused the first problem. Both spokes lost their negotiated addresses, Tunnel0 stayed up/down, no IKEv2 SA remained established, and every tested ping returned 0/5\. The fastest split is `show ip interface brief` plus `show crypto ikev2 session detailed`: an unassigned, up/down Tunnel0 means the session never formed; READY with an address means compare Remote subnets with the routing table. The quieter failures came from other changes. A missing hub export prefix left both SAs READY. Removing SPOKE1's authorization reference also left its SA READY, with the hub prefixes visible in the session output, but none installed in its routing table. I built this in my home lab in Containerlab on Cisco IOL 17.18.2\. Six individual faults, each followed by a repair and reconnect, separate those symptoms. For the complete configuration walkthrough, use [FlexVPN site-to-site configuration](https://www.pinglabz.com/flexvpn-site-to-site-configuration/). [FlexVPN explained](https://www.pinglabz.com/flexvpn-explained/) covers the policy and interface model. Here the useful question is which reference broke, what survived, and which show command exposes the difference. ## Topology and addressing HUB accepts two spokes through an INET router. A host behind HUB and another behind SPOKE1 test actual LAN forwarding; SPOKE2 provides a second LAN destination on Loopback1\. There is no overlay routing protocol, NHRP, NAT, or manually configured crypto map. ![Lab diagram: FlexVPN hub and two spokes on Cisco IOL 17.18.2. spoke1-host eth1 10.40.11.10/24 sits behind SPOKE1 Ethernet0/2 10.40.11.1. SPOKE1 Ethernet0/1 198.18.40.5/30 and SPOKE2 Ethernet0/1 198.18.40.9/30 connect to INET Ethernet0/2 .6 and Ethernet0/3 .10, and INET Ethernet0/1 .2 connects to HUB Ethernet0/1 198.18.40.1/30. HUB has Loopback0 10.40.0.1/32, Ethernet0/2 10.40.100.1 and hub-host eth1 10.40.100.10/24. SPOKE2 Loopback1 10.40.12.1/24 is the test destination. Each spoke Tunnel0 uses ip address negotiated from pool EDGE40-POOL, 10.40.9.10 to 10.40.9.50, and terminates on a Virtual-Access cloned from Virtual-Template1, ip unnumbered Loopback0. HUB pushes the pool address, 10.40.0.1/32, 10.40.100.0/24 and 10.40.0.0/20. SPOKE1 pushes 10.40.11.0/24 and SPOKE2 pushes 10.40.12.0/24. There is no routing protocol or NHRP, the crypto routers use static defaults toward INET, and no ip cef is applied on HUB, SPOKE1 and SPOKE2 as an IOL workaround.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/flexvpn-no-routes-authorization-lab-topology.png) | Device | WAN toward INET | LAN or overlay role | | ----------- | -------------------------------------------------------------------- | ---------------------------------------------------- | | HUB | Ethernet0/1: 198.18.40.1/30; INET .2 | Ethernet0/2: 10.40.100.1/24; Loopback0: 10.40.0.1/32 | | SPOKE1 | Ethernet0/1: 198.18.40.5/30; INET .6 | Ethernet0/2: 10.40.11.1/24; Tunnel0 negotiated | | SPOKE2 | Ethernet0/1: 198.18.40.9/30; INET .10 | Loopback1: 10.40.12.1/24; Tunnel0 negotiated | | INET | Ethernet0/1: 198.18.40.2/30; Ethernet0/2: .6/30; Ethernet0/3: .10/30 | Connected underlay networks only | | Hub host | — | 10.40.100.10/24; overlay traffic through 10.40.100.1 | | SPOKE1 host | — | 10.40.11.10/24; overlay traffic through 10.40.11.1 | The crypto routers have static defaults toward INET. HUB's [Virtual-Template1](https://www.pinglabz.com/flexvpn-explained/#virtual-access-cloning-a-tunnel-per-peer) borrows Loopback0; its address pool runs from 10.40.9.10 through 10.40.9.50\. Pool allocations and Virtual-Access numbers change after reconnects. Match a clone to its peer in the session output before treating its interface number as a site identifier. SPOKE1-to-SPOKE2 traffic uses the hub. This lab makes no direct-shortcut claim; [FlexVPN spoke-to-spoke](https://www.pinglabz.com/flexvpn-spoke-to-spoke/) treats that separate problem. ## The compact working baseline These are the authorization dependencies from the working configuration, with unrelated sections omitted. The full build is in the [AAA and authorization policy block of the site-to-site walkthrough](https://www.pinglabz.com/flexvpn-site-to-site-configuration/#block-1-aaa-and-the-authorization-policy). The existing IKEv2/IPsec setup uses AES-CBC-256, SHA256 and DH19 for IKEv2, and ESP AES256/SHA256-HMAC in tunnel mode. The same AAA network method list exists on all three crypto routers. On HUB: ```ios aaa new-model ! ! aaa authorization network EDGE40-LIST local ... crypto ikev2 authorization policy EDGE40-AUTHZ pool EDGE40-POOL route set interface route set access-list EDGE40-EXPORT ... crypto ikev2 profile EDGE40-IKE match identity remote fqdn domain edge40.lab identity local fqdn hub.edge40.lab authentication remote pre-share authentication local pre-share keyring local EDGE40-KEY aaa authorization group psk list EDGE40-LIST EDGE40-AUTHZ virtual-template 1 ... ip local pool EDGE40-POOL 10.40.9.10 10.40.9.50 ... ip access-list standard EDGE40-EXPORT 10 permit 10.40.100.0 0.0.0.255 20 permit 10.40.0.0 0.0.15.255 ``` SPOKE1 uses the same method list and profile authorization line. Its policy exports its own LAN, and its tunnel requests an address. The isolated profile line below is inside `crypto ikev2 profile EDGE40-IKE`: ```ios crypto ikev2 authorization policy EDGE40-AUTHZ route set interface route set access-list EDGE40-EXPORT ... aaa authorization group psk list EDGE40-LIST EDGE40-AUTHZ ... interface Tunnel0 ip address negotiated ip mtu 1400 ip tcp adjust-mss 1360 tunnel source Ethernet0/1 tunnel mode ipsec ipv4 tunnel destination 198.18.40.1 tunnel protection ipsec profile EDGE40-IPSEC ... ip access-list standard EDGE40-EXPORT 10 permit 10.40.11.0 0.0.0.255 ``` SPOKE2 exports 10.40.12.0/24 instead. The IPsec profiles, keyrings and underlay are already working; these excerpts are the references being tested, rather than a replacement build recipe. For the simpler fixed-peer interface model, see [static VTI IPsec](https://www.pinglabz.com/static-vti-svti-ipsec/). The policy display reports `route accept any tag : 1 distance : 1` by default; no explicit route-accept command was entered. Cisco's [IKEv2 smart-defaults table](https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn/m%5Fsec-cfg-ikev2-flex.html?ref=pinglabz.com) lists distance 2 for the default policy; this IOL 17.18.2 image displayed and installed distance 1\. On HUB, `route set interface` supplies 10.40.0.1/32\. The export ACL supplies the hub LAN and 10.40.0.0/20, which covers both spoke LANs. Each spoke exports its own LAN through its local policy and ACL. Those identically named ACLs are separate objects on separate routers. ![Lab diagram: How IKEv2 authorization pushes FlexVPN routes in both directions. On HUB, profile EDGE40-IKE line aaa authorization group psk list EDGE40-LIST EDGE40-AUTHZ reaches aaa authorization network EDGE40-LIST local and policy EDGE40-AUTHZ with pool EDGE40-POOL, route set interface and route set access-list EDGE40-EXPORT, which permits 10.40.100.0/24 and 10.40.0.0/20. SPOKE1 receives 10.40.0.1/32, 10.40.100.0/24 and 10.40.0.0/20 and installs S 10.40.100.0/24 directly connected via Tunnel0 only through its own profile reference and the default route accept any. In the reverse direction, SPOKE1's own profile, AAA list and policy export 10.40.11.0/24, and HUB installs S 10.40.11.0/24 via a Virtual-Access. Fault tags mark F1 (HUB reference removed), F2 (EDGE40-AUTHZ-TYPO), F6 (AAA list deleted), F3 (hub LAN permit removed), F4 (SPOKE1 reference removed) and F5 (SPOKE1 route set access-list removed). Broken F4 shows 10.40.100.0 255.255.255.0 received but % Subnet not in table on SPOKE1 and HUB. Fixed F4 shows both static routes back and 5 packets transmitted, 5 received, 0% loss.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/flexvpn-no-routes-authorization-lab-ikev2-route-push-v2.png) Follow both directions in that diagram. HUB's profile must reach its AAA list and authorization policy to supply the pool and exports. The spoke's profile has its own reference; its ACL attachment supplies the LAN that HUB needs for return traffic. Defining a policy on the router does not prove a session uses it. The working SPOKE1 session and route excerpts show the attributes and their installation: ```text SPOKE1#show crypto ikev2 session detailed IPv4 Crypto IKEv2 Session Session-id:1, Status:UP-ACTIVE, IKE count:1, CHILD count:1 ... Pushed IP address: 10.40.9.10 Remote subnets: 10.40.0.1 255.255.255.255 10.40.100.0 255.255.255.0 10.40.0.0 255.255.240.0 ... S 10.40.0.0/20 is directly connected, Tunnel0 S 10.40.0.1/32 is directly connected, Tunnel0 S 10.40.100.0/24 is directly connected, Tunnel0 ... SPOKE1#show ip route 10.40.100.0 255.255.255.0 Routing entry for 10.40.100.0/24 Known via "static", distance 1, metric 0 (connected) Tag 1 Routing Descriptor Blocks: * directly connected, via Tunnel0 Route metric is 0, traffic share count is 1 Route tag 1 ``` The three remote prefixes match the three injected routes. The hub LAN lookup reports static, distance 1, tag 1, through Tunnel0\. No overlay static routes were entered manually. Removing individual authorization inputs below changes these entries while the underlay default stays in place: that is the evidence tying the routes to IKEv2\. [IKEv2 explained](https://www.pinglabz.com/ikev2-explained/) provides the exchange background. HUB learns both pool addresses and both spoke LANs: ```text S 10.40.9.10/32 is directly connected, Virtual-Access1 S 10.40.9.11/32 is directly connected, Virtual-Access2 S 10.40.11.0/24 is directly connected, Virtual-Access1 S 10.40.12.0/24 is directly connected, Virtual-Access2 ``` ## How I tested, including the CEF limitation For each case I changed one variable, cleared the hub crypto sessions, shut and cleared both spoke tunnels, then enabled them again. An eight-second wait preceded the state collection and traffic tests. After restoring the changed line, I repeated that reconnect and verification. These are fresh-session observations, not a rekey propagation or long-duration stability test. There was a forwarding limitation before the fault matrix. With CEF enabled, both spokes had READY SAs, negotiated addresses and correct routes, but host traffic failed in both directions. Even the CEF destination lookup pointed to the tunnel: ```text SPOKE1#show ip cef 10.40.100.10 10.40.100.0/24 attached to Tunnel0 ... --- 10.40.100.10 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss ``` A LAN-sourced SPOKE1 ping to HUB's router LAN address succeeded 5/5 during that same investigation. A router answering an echo therefore did not prove transit forwarding to the host behind it. Applying `no ip cef` on HUB and both spokes restored forwarding without changing the crypto configuration or clearing SAs. Early probes had startup loss; steady baseline repeats passed 5/5 for both host directions, both hosts to SPOKE2, and the LAN-sourced interspoke router ping. All six cases below use that working baseline. Treat this as a limitation observed on this IOL image, not production advice or an established internal bug diagnosis. The same IOL forwarding behavior, also cleared with `no ip cef`, appeared in the [crypto map vs SVTI add-a-subnet lab](https://www.pinglabz.com/add-subnet-ipsec-crypto-map-vs-vti/). ## F1: hub profile has no authorization reference I removed only the group authorization line from HUB's IKEv2 profile. The policy, pool, ACL and AAA network list remained defined: ```text HUB(config)#crypto ikev2 profile EDGE40-IKE HUB(config-ikev2-profile)#no aaa authorization group psk list EDGE40-LIST EDGE40-AUTHZ HUB(config-ikev2-profile)#end ``` After the reconnect, SPOKE1 showed no detailed IKEv2 SA or session, a DOWN crypto session, and an unassigned tunnel: ```text SPOKE1#show crypto ikev2 sa detailed SPOKE1#show crypto ikev2 session detailed SPOKE1#show crypto session detail ... Interface: Tunnel0 Session status: DOWN ... SPOKE1#show ip interface brief | include Virtual-Access|Tunnel Tunnel0 unassigned YES manual up down ... SPOKE1#show ip route 10.40.100.0 255.255.255.0 % Subnet not in table ``` SPOKE2 behaved the same way. Neither spoke retained injected routes, and HUB lost both spoke LAN routes and both pool /32 routes. The host pair, both hosts' tests to SPOKE2, and the LAN-sourced router test all failed 0/5. This did **not** reproduce “tunnel up, no routes.” With `ip address negotiated` in this design, there was no established tunnel to carry traffic. The interface status word `up` in up/down is insufficient evidence of a working tunnel. That matches Cisco's [FlexVPN server guide](https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn/m%5Fsec-cfg-flex-serv-0.html?ref=pinglabz.com): IKEv2 authorization is mandatory only if the peer requests an IP address via configuration mode, and when the server cannot assign a requested address it returns INTERNAL\_ADDRESS\_FAILURE. I ran no IKEv2 debug here, so that message itself was not captured. The quickest distinguishing check on HUB is `show crypto ikev2 profile`. Its relevant excerpt was: ```text AAA group authorization: none AAA user authorization: none ``` The normal log buffer did not name the missing reference. Restoring the profile line and reconnecting restored addresses, routes and all tested traffic: ```text HUB(config)#crypto ikev2 profile EDGE40-IKE HUB(config-ikev2-profile)#aaa authorization group psk list EDGE40-LIST EDGE40-AUTHZ HUB(config-ikev2-profile)#end ``` ## F2: hub profile names a policy that does not exist The CLI accepted a misspelled policy name without rejecting the command: ```text HUB(config)#crypto ikev2 profile EDGE40-IKE HUB(config-ikev2-profile)#aaa authorization group psk list EDGE40-LIST EDGE40-AUTHZ-TYPO HUB(config-ikev2-profile)#end ``` The operational profile exposed that name, while the policy display still contained only the default policy and the correctly named EDGE40-AUTHZ: ```text AAA group authorization: psk: list EDGE40-LIST, username EDGE40-AUTHZ-TYPO AAA user authorization: none ... HUB#show crypto ikev2 authorization policy IKEv2 Authorization Policy : default route set interface route accept any tag : 1 distance : 1 IKEv2 Authorization Policy : EDGE40-AUTHZ IPV4 Address Pool : EDGE40-POOL route set interface route set acl: EDGE40-EXPORT route accept any tag : 1 distance : 1 ... SPOKE1#show ip interface brief | include Virtual-Access|Tunnel Tunnel0 unassigned YES manual up down ``` This looked like F1 from either spoke: up/down, unassigned, no established SAs and no injected routes. HUB again lacked the spoke LAN and pool routes; every tested ping failed 0/5\. A missing prefix alone cannot distinguish these cases because establishment failed before a usable routing baseline existed. Compare `show crypto ikev2 profile` with `show crypto ikev2 authorization policy` on HUB. The first tells you what the session is configured to request; the second tells you which policies actually exist. A valid-looking pool and export ACL under the correct policy cannot repair a reference to another name. The captured ordinary logs did not identify the typo. I restored the correct authorization line shown in F1, then reconnected. Every recovery traffic test passed 5/5. ## F3: hub export ACL omits the hub LAN This time the references stayed intact. I removed only sequence 10, the permit for 10.40.100.0/24, from HUB's export ACL: ```text HUB(config)#ip access-list standard EDGE40-EXPORT HUB(config-std-nacl)#no 10 HUB(config-std-nacl)#end ``` Both tunnels stayed up/up with assigned addresses and READY SAs. SPOKE1's received attributes and installed routes retained the hub endpoint and spoke summary, but lost the hub LAN: ```text Tunnel-id Local Remote fvrf/ivrf Status 1 198.18.40.5/500 198.18.40.1/500 none/none READY ... Pushed IP address: 10.40.9.16 Remote subnets: 10.40.0.1 255.255.255.255 10.40.0.0 255.255.240.0 ... S 10.40.0.0/20 is directly connected, Tunnel0 S 10.40.0.1/32 is directly connected, Tunnel0 ... SPOKE1#show ip route 10.40.100.0 255.255.255.0 % Subnet not in table ``` HUB still had both spoke LAN routes and both pool /32s. The two hosts could not ping each other in either direction. Hub-host-to-SPOKE2 also failed, because the remote spoke lacked a route back to the hub host's network. Meanwhile, the SPOKE1 host reached SPOKE2 5/5, and the LAN-sourced router test agreed: ```text SPOKE1#ping 10.40.12.1 source 10.40.11.1 repeat 5 timeout 1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.40.12.1, timeout is 1 seconds: Packet sent with a source address of 10.40.11.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/10 ms ``` That surviving interspoke test narrows the fault considerably. Both spokes still had the summary needed to send that traffic toward HUB; the missing export affected the hub LAN specifically. Use `show crypto ikev2 session detailed` on a spoke to check whether the missing prefix was received at all, then confirm with its exact route lookup. Here it was absent from both places. HUB's policy still displayed the ACL attachment, so checking only the policy name would miss the removed permit. Restoring that ACL entry and reconnecting returned all traffic tests to 5/5. ## F4: SPOKE1 profile has no authorization reference Removing the same type of reference from the other end produced a different result: ```text SPOKE1(config)#crypto ikev2 profile EDGE40-IKE SPOKE1(config-ikev2-profile)#no aaa authorization group psk list EDGE40-LIST EDGE40-AUTHZ SPOKE1(config-ikev2-profile)#end ``` Both SAs remained READY, both tunnels were up/up, and both spokes received pool addresses. SPOKE2 stayed normal. On SPOKE1, all three hub prefixes still appeared under `Remote subnets`, yet the static route table contained only the underlay default: ```text Tunnel-id Local Remote fvrf/ivrf Status 1 198.18.40.5/500 198.18.40.1/500 none/none READY ... Pushed IP address: 10.40.9.21 Remote subnets: 10.40.0.1 255.255.255.255 10.40.100.0 255.255.255.0 10.40.0.0 255.255.240.0 ... S* 0.0.0.0/0 [1/0] via 198.18.40.6 ... SPOKE1#show ip route 10.40.100.0 255.255.255.0 % Subnet not in table ``` The shown default is the complete remaining static-route list, with the legend omitted. An exact lookup also confirms the missing hub LAN route. These prefixes reached the session's attribute display; that was not proof of routing-table installation. HUB retained SPOKE1's pool /32 but lost its LAN /24: ```text S 10.40.9.21/32 is directly connected, Virtual-Access2 S 10.40.9.22/32 is directly connected, Virtual-Access1 S 10.40.12.0/24 is directly connected, Virtual-Access1 ... HUB#show ip route 10.40.11.0 255.255.255.0 % Subnet not in table ``` The host pair and SPOKE1-to-SPOKE2 tests all failed 0/5\. Hub-host-to-SPOKE2 still passed 5/5\. Additional SPOKE1 pings to HUB's LAN router address failed whether sourced from Tunnel0 or 10.40.11.1. For this case, pair `show crypto ikev2 session detailed` with `show ip route static`, then inspect SPOKE1's profile. The hub was sending the expected attributes. SPOKE1's profile reported no group authorization, and its local route installation was missing too. Restoring that spoke reference and reconnecting recovered both route directions and every traffic test at 5/5\. The normal log buffer contained no targeted explanation of the route failure. ## F5: SPOKE1 policy loses only its export ACL attachment F4 did not isolate a pure return-route failure: SPOKE1 lost its own injected routes as well. To separate those effects, I kept its profile reference and removed only the policy's export attachment: ```text SPOKE1(config)#crypto ikev2 authorization policy EDGE40-AUTHZ SPOKE1(config-ikev2-author-policy)#no route set access-list EDGE40-EXPORT SPOKE1(config-ikev2-author-policy)#end ``` The ACL itself still existed. Both tunnels remained up/up, addressed and READY. This time SPOKE1 installed all normal hub routes, while HUB lacked SPOKE1's LAN: ```text SPOKE1#show crypto ikev2 authorization policy IKEv2 Authorization Policy : default route set interface route accept any tag : 1 distance : 1 IKEv2 Authorization Policy : EDGE40-AUTHZ route set interface route accept any tag : 1 distance : 1 ... S 10.40.0.0/20 is directly connected, Tunnel0 S 10.40.0.1/32 is directly connected, Tunnel0 S 10.40.100.0/24 is directly connected, Tunnel0 ... HUB#show ip route 10.40.11.0 255.255.255.0 % Subnet not in table ``` HUB still had both pool /32s and SPOKE2's LAN route. The host pair and SPOKE1-to-SPOKE2 tests failed 0/5, while hub-host-to-SPOKE2 passed 5/5\. Those ping results resemble F4, but the spoke route table separates them immediately. Read the authorization policy on SPOKE1: its named policy has `route set interface`, but no `route set acl` line. Then check HUB's exact route for the spoke LAN. The surviving pool /32 proves only that HUB has a route to the assigned tunnel address; it does not provide the LAN /24 behind it. Restoring the ACL attachment and reconnecting returned that route and all traffic tests to the working baseline. ## F6: hub AAA network method list is missing The final fault left HUB's profile pointing to the correct policy and list name, but removed the list definition: ```text HUB(config)#no aaa authorization network EDGE40-LIST local HUB(config)#end ``` These excerpts show the AAA configuration gap, the surviving operational profile reference, and the resulting state: ```text logging buffered 32000 informational aaa new-model ! ! ! aaa session-id common ... AAA group authorization: psk: list EDGE40-LIST, username EDGE40-AUTHZ AAA user authorization: none ... SPOKE1#show ip interface brief | include Virtual-Access|Tunnel Tunnel0 unassigned YES manual up down ... HUB#show ip route 10.40.11.0 255.255.255.0 % Subnet not in table ``` Both spokes were unassigned and up/down, with no established SAs or injected routes. HUB lost both spoke LAN routes and pool /32s. Every tested ping failed 0/5, matching F1 and F2. A profile containing the expected names is therefore only half the check. Use `show running-config` on HUB to confirm the named `aaa authorization network` definition actually exists; the operational profile display alone still lists the reference. Restoring that method list and reconnecting recovered the full baseline, with every traffic test passing 5/5. ## Authorization fault matrix “Routes” here means injected overlay routes. The configured underlay default and directly connected networks remain. “Pair” means the hub host and SPOKE1 host, tested both ways; S2 means destination 10.40.12.1\. Every result follows the controlled reconnect described above. | Fault | Tunnel | Spoke address | Spoke routes | Hub routes | Ping | Tell | | ------------------------------------ | -------------------------------- | --------------- | ----------------------------- | ------------------------------------- | ---------------------------------------- | ------------------------------------------------------- | | Working | Both up/up, READY | Both assigned | Hub /32, LAN /24, summary /20 | Both pool /32s and LAN /24s | All tests 5/5 | Session attributes match routes | | F1: HUB profile reference removed | Both up/down; no established SAs | Both unassigned | None injected | No spoke/pool routes | All 0/5 | HUB show crypto ikev2 profile: no group authorization | | F2: HUB policy-name typo | Both up/down; no established SAs | Both unassigned | None injected | No spoke/pool routes | All 0/5 | Profile username differs from defined policy | | F3: HUB LAN export permit removed | Both up/up, READY | Both assigned | Both lose hub LAN only | Both pool /32s and LAN /24s retained | Pair 0/5; SPOKE1→S2 5/5; hub host→S2 0/5 | Hub LAN absent from spoke session attributes | | F4: SPOKE1 profile reference removed | Both up/up, READY | Both assigned | SPOKE1 none; SPOKE2 normal | SPOKE1 LAN missing; pool /32 retained | Pair and SPOKE1→S2 0/5; hub host→S2 5/5 | SPOKE1 remote subnets present, static routes absent | | F5: SPOKE1 export attachment removed | Both up/up, READY | Both assigned | Both normal | SPOKE1 LAN missing; pool /32 retained | Pair and SPOKE1→S2 0/5; hub host→S2 5/5 | SPOKE1 policy lacks ACL attachment; HUB lacks LAN route | | F6: HUB AAA network list removed | Both up/down; no established SAs | Both unassigned | None injected | No spoke/pool routes | All 0/5 | Profile references list absent from running config | F3, F4 and F5 are the quiet routing failures: no targeted authorization error appeared in the captured normal logs. That does not mean the log was empty. Deliberate tunnel and session resets generated ordinary state-change messages in these tests. No crypto debug was needed to distinguish the cases. ## Checks I run on a FlexVPN spoke with no routes 1. Read `show ip interface brief` and `show crypto ikev2 session detailed` together. An unassigned up/down Tunnel0 belongs on the establishment branch; READY with an address needs a route comparison. 2. Compare `Remote subnets` with `show ip route static` and an exact destination lookup. Missing attributes led to F3; received attributes without installed routes led to F4. 3. On each end, compare the profile's group authorization names with the defined policy and AAA network list. F1, F2 and F6 looked identical from the spokes. 4. Check the policy's ACL attachment and the permitted prefixes on the router exporting the missing network. For a missing spoke LAN on HUB, inspect that spoke's export, not just HUB's. 5. Test both host directions and a LAN-sourced interspoke ping. READY and a successful router-address ping did not establish host forwarding in this lab. For faults outside this authorization chain, [troubleshooting IPsec VPNs](https://www.pinglabz.com/troubleshooting-ipsec-vpn/) gives the broader path through negotiation and data-plane checks. 💡 **Received prefixes still need a routing-table check** [PingLabz Pro](https://www.pinglabz.com/membership/?plz%5Fplacement=pricing:flexvpn-no-routes-authorization-lab:mid:v1) unlocks all 68 browser labs, 500 CCNA practice questions and two timed mock exams for $59/year or $7.99/month. ## Verification checklist After each repair and reconnect, I verified: - Both spokes had assigned addresses, up/up tunnels and READY SAs. - Both spokes listed and installed the expected hub prefixes. - HUB had both pool /32s and both spoke LAN /24s through the matching clones. - The host pair passed in both directions, and both hosts reached SPOKE2. - The LAN-sourced SPOKE1-to-SPOKE2 router ping passed. Every restoration passed all five traffic checks at 5/5. Final steady host-pair excerpts: ```text --- 10.40.100.10 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 6.434/6.629/7.017 ms ... --- 10.40.11.10 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 7.134/7.626/8.082 ms ``` The final configurations matched the working baseline. For a repeat of this test, verify the route for the actual source LAN as well as the destination: F5 shows how a healthy-looking spoke route table can coexist with a missing return path. This run did not test [certificates](https://www.pinglabz.com/ipsec-certificate-authentication/), RADIUS, remote-access clients, NHRP shortcuts, scale, or whether an ACL change propagates on rekey alone. Recovery here includes a reconnect. The CEF workaround remains part of the stated IOL test conditions. ## Related VPN labs - [FlexVPN site-to-site configuration](https://www.pinglabz.com/flexvpn-site-to-site-configuration/) — Build the working hub-and-spoke baseline. - [FlexVPN explained](https://www.pinglabz.com/flexvpn-explained/) — Connect AAA, authorization policies and cloned interfaces. - [FlexVPN spoke-to-spoke](https://www.pinglabz.com/flexvpn-spoke-to-spoke/) — Separate hub forwarding from a direct shortcut. - [IKEv2 SVTI configuration](https://www.pinglabz.com/ikev2-svti-configuration/) — Follow a fixed-peer tunnel baseline. - [Troubleshooting IPsec VPNs](https://www.pinglabz.com/troubleshooting-ipsec-vpn/) — Work through negotiation and forwarding checks. - [Phase 1 up, phase 2 down](https://www.pinglabz.com/cisco-ipsec-phase-1-up-phase-2-down/) — Work through five IOL IPsec faults that stop the child SA. - [IPsec VPN guide](https://www.pinglabz.com/ipsec-vpn/) — Review IKE, ESP and VTI fundamentals. ## FAQ ### Why is FlexVPN route set not working when the policy exists? Check the entire reference chain. In F1, HUB's policy still existed but the IKEv2 profile no longer invoked group authorization. In F2 the profile named a nonexistent policy; in F6 it referenced a missing AAA network list. All three prevented establishment with negotiated spoke addressing on this image. ### Does READY mean the pushed routes are installed? No. F4 retained READY and all three hub prefixes under `Remote subnets`, but SPOKE1 installed none of them. Compare session attributes with the routing table. F3 was different: the missing hub LAN prefix was absent from the received attributes too. ### Why can the spoke have routes while HUB cannot reach its LAN? Each end exports its own prefixes. F5 removed SPOKE1's `route set access-list` attachment while preserving its authorization reference. The spoke kept the hub routes, but HUB lost 10.40.11.0/24\. A retained tunnel-address /32 did not replace the missing LAN route. ### Does ip address negotiated require a working authorization chain? In this tested FlexVPN design, the hub policy supplied the address pool. Breaking the hub reference, policy name or AAA list left both spoke addresses unassigned after reconnect. This does not establish the behavior of a different design with fixed tunnel addresses; [IKEv2 SVTI configuration](https://www.pinglabz.com/ikev2-svti-configuration/) covers that separate baseline.