ASA ACL - inbound and outbound on the same interface - possible disadvantage

[Martin Jelinek]

Hi all,

I'd like to ask you if you have experinced in your setup usage of inbound and outbound ACL applied to the same interface of course in rights direction? I'm asking because usage of outbound ACL (direction out) is quite rare I would say.

Let's say to have two ACLs applied in the same interface in specific direction.

access-group inside_ACL_INBOUND in interface inside

access-group inside_ACL_OUTBOUND out interface inside

In logical topology you will have entering interface outside, where an ACL will simply allow any/any and you will do filtering on inside interface where you have applied noted two ACLs, therefore you control what is entering interface inside and what is leaving such interface.

Is this doable? I'm not sure in case of traffic flow and connection table, because if traffic entering outside interface (permit any/any) place traffic flow into connection table, will it be even checked by ACL configured on inside interface in OUT direction?

Just trying to understand possible drawbacks as this is not really common setup. Also in case of Service Policy (inspections) are they applied twice or only during first entering to the firewall?

It is general question and I don't have real technical setup in place. Just trying to find best suitable option.

Thanks for hint.

Martin

[balaji.bandi]

In the Real world, ASA have 2 Interface, one for outside and one for inside. ( again where the traffic originating from called in and  where leaving called out - this where most confused here)

Coming back to your question, this is possible (some time required where internal networks required in and out ACL.

Some reference guide for understanding :

https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/access_nw.html

[Sergey Lisitsin]

This is absolutely doable and there is nothing wrong with it. However, in real world, people prefer to simplify things by only applying inbound access lists. Which makes sense, because if you have 2 interfaces for example, having inbound access lists on both of them will cover all traffic without the need for any outbound access list. Instead of denying things going out of specific interfaces, deny it on the inbound interface instead. This is more efficient, conserving the firewall CPU resources.

[Martin Jelinek]

Isn't there any issue caused by inpsection (Service Policy) then?

Just the fact that single interface will have two ACLs (IN/OUT), where entry point OUTSIDE interface will have permit any/any which would I believe run into inspections, so what in case such traffic is then denied by ACL on out-direction of an inside interface, will this eat resources of the firewall already because traffic was permitted by outside interface ACL, but then denied by following ACL?

We have this in our mind for specific purpose, but will run quite big traffic through it, so I'm trying to find out possible drawback whether it is based on packet handling, inspections etc.

At the moment I can't realise a real issue with such setup even though it is not the common one, but looks to be fully doable. ;-)

Thanks

Martin 

[bern81]

Hi Martin,

As the colleugues previously mentioned , nothing wrong with that but the common scenarion in production to apply inbound ACLs especially on the outside interface if you have DMZ.

Inspection is not affected by this , especially that by default on the outisde interface there is a deny any ACL.

and yet when you inspect your traffic the return packets make it through from outside to inside

Please rate if this is helpfull

[balaji.bandi]

Theory point of view, not have any disadvantage, But if you have any issue after deploying please raise again with more information, so we can investigate with you what is wrong.

[Martin Jelinek]

Hi all,

Thanks for your inputs and thoughts.

I do believe we are going to be fine with this setup (we will have to test it anyway in future).

There is a specific reason for such considered scenario (an idea amongs others) and that is fact to optimize traffic flow of legacy network separated in traditional way with context firewalls (each context with two interfaces one outside and one inside, each with ACL applied in inbound direction) to "migrate" into ACI for decreasing needed amount of L3OUT sessions and configurations.

So though is to compile all context firewalls into single context with multiplied sub-interfaces, which would then represent inside/outside interfaces of each context firewalls and of course connection to outside world will be with dedicated new outside interface. But trick is that with many contexts you have many ACLs and to compile/merge such ACLs is a killer job, so to keep benefit of specific ACLs to represent legacy network security rules and use of new application centric deployment.

Thanks for your advices, if we are fine we will test it to see if it is sustainable and manageable, but still some way if this would be even the way we might be going to.

/Martin