07-30-2013 07:00 AM - edited 03-11-2019 07:19 PM
Hello to you all
I have a very big ACL I want to implement (over 1000 lines), and I´m trying to minimize the impact and latency an ACL this size would bring to the network, so I wanted to group my networks and services into different object and service groups.
My question now is, how does an FWSM behaves when reading ACL lines with object groups?
For instance, imagine the following scenario. I have an ACL such as:
object-group network NETS
network-object 10.1.1.0 255.255.255.0
network-object 10.1.1.1 255.255.255.0
network-object 10.1.1.2 255.255.255.0
network-object 10.1.1.3 255.255.255.0
network-object 10.1.1.4 255.255.255.0
network-object 10.1.1.5 255.255.255.0
access-list test extended permit tcp 192.168.1.0 255.255.255.0 object-group NETS eq 80
access-list test extended permit tcp 192.168.2.0 255.255.255.0 host 10.2.2.1 eq 443
and I receive a request from source 192.168.2.5 to host 10.2.2.1 to its TCP port 443...what will happen? Will the FWSM expand the object group defined in the 1st line and go through all the object-group NETS before reaching the 2nd line, or will the FWSM see the source it´s not from the 192.168.1.0/24, won´t expand the object group, and goes directly to the 2nd line?
Does Cisco FWSM perform this kind of ACL resource management?
Best wishes
07-31-2013 03:19 AM
Anyone?
08-01-2013 05:46 AM
Bump
08-02-2013 08:02 AM
ACLs are processed in sequential order. When a packet arrives, the appliance look for a match from top to bottom beginning with the 1st ACE, 2nd ACE,....etc. If no match found, an implicit deny would be a match and the packet is dropped.
So, to answer your question, Yes ASA will check the first object group ACE first then 2nd ACE, ...etc, until it find a match. That is why ACE order is important. If you want to preserve firewall resources, always place the more specific ACEs at the top and place the more wide general ACEs at the bottom of the ACL. For example, i would place the 2nd line before the object group ACE because it is more specific. Use the "Line" keyword in the ACL command.
Regards,
AM
08-19-2013 05:41 AM
turbo_engine26
Thank you for your feedback.
My question was not so much how the appliance will work in terms of checking for matches, but more in how it will work when a source does not correspond to the packet.
An ACL is composed by 3 parameters, a Source IP, a destination IP and a PORT, and I believe the appliance will try and match there 3 parameters with the packet in a specific order (1st source IP, then destination IP, then Port).
Regarding the example I placed before:
object-group network NETS
network-object 10.1.1.0 255.255.255.0
network-object 10.1.1.1 255.255.255.0
network-object 10.1.1.2 255.255.255.0
network-object 10.1.1.3 255.255.255.0
network-object 10.1.1.4 255.255.255.0
network-object 10.1.1.5 255.255.255.0
access-list test extended permit tcp 192.168.1.0 255.255.255.0 object-group NETS eq 80
access-list test extended permit tcp 192.168.2.0 255.255.255.0 host 10.2.2.1 eq 443
If I receive a packet with IP source source 192.168.2.5 to host 10.2.2.1 to its TCP port 443, it makes sense to me that the appliance would first check if the source IP matches the first line of the ACL, and if it doesn´t match it wouldn´t try to match the destination IP and the TCP Port. It makes sense to me that the match process of an ACL should work in that matter in order to preserve the equipment resources.
So my question is, when a packet arrives with a source IP that doesn´t correspond to this line:
access-list test extended permit tcp 192.168.1.0 255.255.255.0 object-group NETS eq 80
will the appliance "ignore" the rest of the line (destination IP and destination port) and goes directly to the 2nd line of the ACL, or will it expand the object group and check line by line (even when the source IP does not match)?
08-19-2013 07:51 AM
Yes, the appliance will NOT check for the destination if the source does not exist during the matching process. What i meant is, the appliance will just check in sequential order (as part of its ACL Lookup operation) for a matching for the source 192.168.2.5 in the ACE entry that includes the object grouping and if the source doesn't exist in this entry, it of course will skip it and there will be no need to continue expanding and checking the destinations inside the object group.
Regards,
AM
08-19-2013 08:43 AM
turbo_engine26
Thank you very much. That´s what I wanted to know.
Do you know of any cisco document where that information is described? The part you mentioned
"if the source doesn't exist in this entry, it of course will skip it and there will be no need to continue expanding and checking the destinations inside the object group"
it´s very important to me. Do you know where I can find a paper describing this? I´ve looked on the Cisco site, but I wasn´t able to find it anywhere.
Oh, and btw, I don't know if this makes any difference, but I´m talking about a FWSM and not an ACE load-balancer.
08-19-2013 09:02 AM
Hi,
Here are some information about past Cisco Live presentations related to ASA/FWSM performance
Access Control Lists (ACLs)
Fully expanded and compiled into a binary tree structure
‒ Stored in main memory (ASA) and NP3 memory (FWSM)
‒ Compilation process temporarily elevates Control Plane load
‒ No performance advantage with a particular order
‒ Element reuse improves space utilization
‒ Several smaller ACLs are better than a large one
Checked by Session Manager before conn creation
‒ ACL size mostly impacts conn setup rate
‒ More impact from conns denied by outbound ACLs
‒ Existing connections are impacted at peak memory usage
Recommended maximum to limit conn setup rate impact (<10%)
‒ Up to 25% throughput impact beyond maximum recommended size
‒ Throughput impact depends on conn lifetime
Source:
https://www.ciscolive365.com/connect/publicDashboard.ww
When you register there is a lot of past Cisco Live presentation material available. Sometimes even the video of the actual presentation from Cisco Live.
- Jouni
08-19-2013 09:24 AM
JouniForss
Thank your for your feedback, and I've read before Cisco's best practices regarding ACLs. My particular doubt is more specific about the engine/process of FWSM when processing an ACL entry regarding its source IP, destination IP and port when combined with an object-group.
I´ve registered on the site, but I still can´t find any document or presentation regarding turbo_engine26's remark:
"if the source doesn't exist in this entry, it of course will skip it and there will be no need to continue expanding and checking the destinations inside the object group"
I have a very large ACL that I want to implement (and I've compressed it as much as I can), and in order to minimize it´s impact on the network I´m trying to set up object-groups. But the only way it will do any difference it's if the FWSM after checking the source IP of the ACL goes directly to the next entry without expanding the object-group.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide