Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
After a certain amount of time, that could vary for every environment depending on the amount of VTI tunnels and how frequent they drop and reestablish due to vpn-idle-timeout setting, ASA starts rejecting new negotiations for some of the original tunnels that used to be up. ASA will keep negotiating tunnels but not all of them will be able to stay up simultaneously. Below symptoms can be observed when in the failed
1. IKEv2 debugs show: Failed to request SPI from CTM as responder, outstanding 0, status 255 <<<<---------- 2. IPSEC debugs show: %ASA-7-711001: IPSEC ERROR: Failed to allocate an inbound hardware context (rc: 0xFFFFFFFF), ctm_nlite_ipsec_alloc_hw_ibsa:91 <<<<---------- %ASA-7-711001: IPSEC ERROR: Failed to generate a new SPI <<<<---------- %ASA-7-711001: IPSEC ERROR: Failed to create an inbound SA, SPI:0xAB16FC90 <<<<---------- %ASA-7-711001: IPSEC ERROR: Failed to complete the GETSPI command from IKE <<<<---------- 3. "debug menu ikev2 13 0" shows " PFKEY GETSPI failures " counter increasing: ---------- IKEv2 Errors ------------------ Child SA rekey initiate failure: 0 PFKEY GETSPI failures: 395 <<<------------- 4. Below "show counters" counters start increasing: IPSEC IB_CONTEXT_ALLOC_FAILED 3 Summary <<<---------- IPSEC OB_CONTEXT_ALLOC_FAILED 10 Summary <<<---------- IPSEC OUT_SA_CLEANUP 10 Summary <<<---------- IPSEC HW_SA_CREATION_FAILURE 10 Summary <<<---------- IPSEC IB_SA_DEL_PRE_DB_ADD 3 Summary <<<---------- IPSEC COULDNT_GET_SPI 3 Summary <<<---------- 5. Syslog ID 602305 gets generated: %ASA-3-602305: IPSEC: SA creation error, source A.A.A.A, destination B.B.B.B, reason hw SPI gen error. Conditions: ASA with IKEv2 VTIs vpn-idle-timeout setting being applied to IKEv2 VTI VPN sessions
When in the failed condition, reload the affected ASA OR To prevent ASA from entering this condition disable vpn-idle-timeout
For instance, if you set up 3 tunnels and you expect all of them to be up at any given point in time, when in the failed state, the ASA will allow less VPNs to connect, let's say only 2 of them and they can swap states with non-working VPNs over time, i.e., Tunnel1 and Tunnel2 could be up but after some time you could see Tunnel1 and Tunnel3 up and running.