IPSEC - How outbound SA is chosen among established SA?
I am facing a strange issue in one of our customer setup.
I would like to know how the correct SA for outbound traffic is chosen?
ASR is configured as IPSEC VPN concentrator aggregating around 1000+ spokes as "Dynamic Crypto" with RRI enabled and only two spokes are confiugred as "Static Crypto".
One particular dynamic crypto includes LAN supernet of /8 and two Static crypto ACL entry includes a supernet prefix of /16 and remaining spokes are configured with /24. The reason that has supernet LAN entry for this particular spokes is to have a simple configuration of ACL for 2 static crypto peers and to match less specific LAN for 1 dynamic crypto peer.
With RRI, ASR installs LAN routes of spokes as /24 pointing towards the correct spoke. Only for the particular dynamic crypto peer, ASR installs supernet of /8 and two static crypto with /16.
All of a sudden, certain spokes lose reachability with no traffic flowing throgh it and comes back once we clear the SA for the particular spoke.
I would like to know the internal order of operations in processing IPSEC traffic in ASR router. Raised TAC with Cisco and got the below update:
My assumption was the router selects the correct SA based on the routing table lookup. That is to send traffic to spoke, ASR has a routing entry for the LAN and chooses the correct remote peer IP. But came know from TAC that routing table lookup is only to decide on which interface the traffic should forward, and there is something else called "SA table" wherein the order of processing happens from top to bottom with matching remote LAN and not based on the longest routing table lookup. "SA table" is required to select the remote crypto peer IP and the way "SA table" gets populated is based on who intiates IPSEC session with more recent one being on the top.
So in our scenario, if the crypto peers with supernet LAN (/8 or /16) initiate traffic after all the spokes are formed, then obviously the new SA of supernet LAN is on the top of SA table and all return traffic of spokes (/24 LAN's) will get matched wrongly on this SA and gets dropped. The workaround is to have a specific LAN (/24) as interesting traffic for the particular crypto peer IP.
1. Would like to confirm the above operations is normal and any document to corroborate this as I could not find any such.
2. Is there anyway to have SA for particular crypto peers to be on the bottom of SA table so that I can have shortest match LAN prefix (/8 or /16) on the bottom of SA table?
On December 8, FireEye reported that it had been compromised in a sophisticated supply chain attack: more specifically through the SolarWinds Orion IT monitoring and management software. The attackers leveraged business software updates in order to distr...
ISE Node TerminologyISE DeploymentsISE Deployment Scale and LimitsISE Hardware PlatformsISE PSN PerformanceISE TrustSec ScalingISE Storage RequirementsISE ERS ScaleISE WAN Bandwidth CalculatorSources
About this Document
Cisco Secure Endpoint (for...