Security Associations limit of Cisco ASA devices?

[hellloooo29283181]

Hi,

I am using AWS VPC/VPN with my Cisco ASA, and after having issues with tunnel instability, I enlisted AWS developer support for assistance. The portion of my config that they commented on was the following:

access-list acl-amzn extended permit ip 192.168.0.0 255.255.255.0 10.0.1.0 255.255.255.0

access-list acl-amzn extended permit ip 192.168.7.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list acl-amzn extended permit ip 172.16.0.0 255.255.255.0 10.0.5.0 255.255.255.0

!

crypto map amzn-vpn-map 1 match address acl-amzn

crypto map amzn-vpn-map 1 set pfs group2

crypto map amzn-vpn-map 1 set peer 54.240.204.92

crypto map amzn-vpn-map 1 set transform-set transform-amzn

crypto map amzn-vpn-map interface outside_interface

They said that: "Due to a limitation with the Cisco ASA and AWS VPN, there is a limit of 2 SAs, so you will have to consolidate your access-list to 2 rules and then filter the traffic to prevent permitting unwanted traffic:

access-list acl-amzn extended permit ip any 10.0.0.0 255.255.0.0

This has me asking:

1 .) Does using more than 2 lines or not having the source as "any" in access-lists actually create additional SAs? I wouldn't have thought so

2.) Is there a limit of 2 SAs for Cisco ASAs? Once I again I wouldn't have thought so, I could have sworn people had setup many such rules linked with a crypto map

3.) Perhaps this is a limitation on AWS end as they perform route based VPN whereas the ASA does policy based vpn?

4.) If adding extra access-list lines does not create additional SAs, why does it cause tunnel instability issues and why did reducing it to 1 fix my problems?

Thank you for any help you can provide! Whilst it may be working and some would say "why ask?", I am curious by nature and like to know why this was recommended and why it worked (they would not elaborate on their end).

[Marcin Latosiewicz]

Thomas,

ASA does not have a limit on SAs per peer.

Edit: There are some global limits, obviously per platform, but 3 is not the limit ;-)

http://www.cisco.com/en/US/products/ps6120/prod_models_comparison.html

The more entries in ACL the more possibility for ASA to create multiple SA for this peer. (we create SAs for ACL entry only if there is traffic which needs to be encrypted or decrypted) 

Simplification of your ACLs, to be as short as possible, is in general a best practice, however be careful not to create overlap with other crypto map entries. in your case, for example:

-----

permit ip 192.168.0.0 255.255.0.0 10.0.0.0 255.255.0.0

permit ip 172.16.0.0 255.255.255.0 10.0.5.0 255.255.255.0

------

This is sure to the fact that each SA has to be re-keyed separately at the end of it's lifetime. The fewer SAs the less effort on part of IKE peer and the more scalability and stability we can gurantee (if that makes sense).

Does that answer your question?

M.

[malshbou]

Hi,

There are really reported problems when multiple SAs exist between ASA and Amazon firewall. I have had a case where:

-  ASA  negotiateed and established phase2 SAs in a  normal way with Amazon (as seen from the ASA side).

- then it seemed that the Amazon Firewall started sending "non-negotiated" proxy identites traffic with the same SPI(s) it had with the ASA. This was like Amazon is "violating" the established  SPI(s).

The ASA rejected this behaviour, and was logging the following message:

" Error Message    %ASA-4-402116: IPSEC: Received an protocol packet (SPI=spi, sequence  number=seq_num) from remote_IP (username) to local_IP. The decapsulated inner  packet doesn't match the negotiated policy in the SA. The packet specifies its  destination as pkt_daddr, its source as pkt_saddr, and its protocol as pkt_prot.  The SA specifies its local proxy as id_daddr/id_dmask/id_dprot/id_dport and its  remote proxy as id_saddr/id_smask/id_sprot/id_sport."

This is an  "incompatible behaviour" in the Amazon firewall, but not the ASA.  The workaround was really consolidating the negotiated SAs to be fewer.

Hope this helps.
Mashal Alshboul

[hellloooo29283181]

Hi M and Mashal,

Thank you for the replies.

I suppose I was having a hard time understanding why there was a hard limit of 2 SAs (as AWS phrased it) and why when surpassing 2, if a  new SA is created, one is dropped, creating the situation of random  failures/instability.

They specified that the way around this problem is making sure that there is a  maximum of two ACLs that allow traffic to the tunnel and setting  additional rules as group policies as they don't generate SAs.

Some digging shows that the ASA will only maintain 2  SA at any time when working with AWS, and I am not sure if this is because they do Route based VPN whereas the ASA does policy based.

I know AWS send the proxy-id of  0.0.0.0/0.0.0.0.0/0 (due to route based VPN) which the ASA rejects, tearing down the session and thus requiring the use of the SLA monitor which forces the ASA to create an SA.

So yes, your answers do sort of answer my question though to be honest, it is still not 100% clear if the "2 rule" limitation is due to Policy based VPN ASA end setting up a VPN with the Route Based AWS end or some other issue also why more access-list rules linked to a crypto map does create additional SAs as when I look up the definition of an SA, it does not jibe.

Thanks again!

[hellloooo29283181]

Interestingly, I found a site that supports the view that additional ACL entries cause SAs to be created:

http://packetlife.net/blog/2011/aug/17/policy-based-vs-route-based-vpns-part-2/

Policy-based VPNs result in excessive IPsec SA creation

On the heels of the first observation, we realize that every ACL  entry in a VPN policy results in a distinct pair of IPsec SAs (which we  can examine in detail with the command show crypto ipsec sa).  This isn't a problem if you can efficiently summarize routes, but  results in substantial overhead if you have to define a number of  distinct routes at either end of the VPN.

I suppose what was confusing me was the definition of an SA:

http://www.ciscopress.com/articles/article.asp?p=24833&seqNum=7

To me, this seemed to say that an SA was established between the peers doing the encryption (i.e. the 2 VPN endpoint routers). As the SA would include the source/dest of the 2 routers, not the devices in the networks behind them, I could not see why more ACLs could cause more SAs (it seemed like an SA always had source/dest of the 2 endpoint routers and not much else besides some unique identifiers). Obviously the SA is not negotiated between the devices behind these peers as they have no idea that encryption is taking place or that their traffic is going via a VPN.

[Marcin Latosiewicz]

Thomas,

Since policy based VPN relies on traffic to bring the SA up (i.e. it is not "always on"), yes in some scenarios you will have as many SAs as ACL entries. It obviously depends on traffic pattern.

From my original post:

The more entries in ACL the more possibility for ASA to create multiple SA for this peer. (we create SAs for ACL entry only if there is traffic which needs to be encrypted or decrypted) 

M.