cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
736
Views
14
Helpful
9
Replies

Basic ACL question = brain freeze

John Blakley
VIP Alumni
VIP Alumni

All,

I've NEVER used an acl in the outbound direction. Can someone explain what the benefits are to doing this?

Suppose I have a web server in a DMZ addressed as 192.168.1.50. I could have an acl like:

permit tcp any host 192.168.1.50

deny ip any any

I could apply this inbound. Why would I want to apply this outbound? Or, would it even make sense to apply an acl like this outbound?

Thanks!

John

HTH, John *** Please rate all useful posts ***
9 Replies 9

Richard Burts
Hall of Fame
Hall of Fame

John

Lets take your example where you have a server in a subnet connected to some interface. And lets assume that you only want certain addresses to initiate connection to the server. It would be logical (and efficient) to configure the access list outbound (which catches traffic being sent to the server) and permit the addresses you want and deny other addresses going to the server. You could do that with an inbound access list which prevents the server response to the unwanted addresses. But at that point you have already allowed that traffic onto the subnet and have required the server to process cycles on traffic which you are now going to deny - less efficient.

HTH

Rick

HTH

Rick

Jon Marshall
Hall of Fame
Hall of Fame

John

Outbound acl's are useful for a number of things

1) To keep acl's manageable. On a firewall the outside interface acl is usually the largest one. If you have a DMZ that you only want to allow a few ports to then you could just as easily use an outbound acl for it rather than add extra clutter in your in outside interface acl.

2) More usefully on an ASA/PIX if you terminate VPN's on the outside interface and use "sysopt connection permit-ipsec" or "sysopt connection permit-vpn" this bypasses the acl on the outside interface. But you may then want to filter the traffic on another interface lets say the inside interface. The only direction you can now filter that traffic is in the outbound direction on the inside interface.

Routers/L3 switches -

if you want to only allow one server on a vlan to be accessed on port 80 from all other vlans you could either

1) Apply an inbound acl restricting access on EVERY other vlan interface

OR

2) Apply an outbound acl on the server vlan interface.

2 is obviously the better option :)

Jon

So if I had a guest wireless vlan (which I do), instead of blocking 20 subnets that this vlan can get to, my acl could look like

ip access-list ext GUEST

permit tcp any any eq 80

deny ip any any

int vlan50

ip access-group GUEST out

Of course, I would need to allow DNS, but that's the basics. That would make it a LOT more efficient if I understand it right.

Thanks!

John

HTH, John *** Please rate all useful posts ***

John

If you wanted to allow any machine on the guest vlan to access any other vlan on port 80 and not anything else you would apply this acl INBOUND on guest vlan L3 interface.

Applying it outbound would only limit http traffic TO machines on the guest vlan which is not what i think you are trying to do.

Please let me know if i have misunderstood.

Jon

Well, currently I have an inbound acl that blocks the guest vlan from being able to get into my other subnets, and it works well. I was trying to use an example that would cut back on the amount of entries that I would need in my acl.

John

HTH, John *** Please rate all useful posts ***

I think in the example you gave an inbound acl is the best approach.

As i say the main use of an outbound acl on a vlan interface is if you want to restrict traffic TO a certain vlan rather than restrict traffic FROM a certain vlan which is the case with your guest vlan.

Jon

Edison Ortiz
Hall of Fame
Hall of Fame

Can someone explain what the benefits are to doing this?

Say, you have multiple outgoing interfaces and just want to block access via one of the outgoing interfaces..

Say, you want the device to make a routing decision or policy on the source subnet before blocking - you need to let it in...

Other than that, the ACL must be placed closest to the source, thus inbound ACL is the most common used.

__

Edison.

John

As several of us have tried to explain, whether it is better to use an inbound ACL or an outbound ACL depends on what your objectives are. Perhaps it helps to think that an ACL is to help control access regarding some hosts in the subnet connected to the interface. If your objective is to control what those hosts have access TO, then it is usually better to do this with an inbound ACL. And if your objective is to control what has access to those hosts, then it is usually better to use an outbound ACL.

So start with a clear statement of your objective and it will lead you to which direction the ACL should be applied.

HTH

Rick

HTH

Rick

Joseph W. Doherty
Hall of Fame
Hall of Fame

For network efficiency, if blocking traffic, you usually want to do it as soon as possible. Often this is done via an inbound ACL as close to the source of the traffic as possible. However, you may want to trade-off network efficiency for engineer efficiency. If we had many interfaces that could communicate with just one interface, instead of supporting many inbound ACLs blocking some traffic, we might configure just one outbound ACL blocking some traffic.

PS:

BTW: In theory, an outbound ACL might also be more network efficient. Consider the traffic we need to block transits an egress interface that has very low volume of traffic. The ingress interface, however, has very high volume of traffic. (This assume much of the high volume inbound traffic is going to another egress interface[s].) If we apply the ACL inbound, all the high volume ingress traffic is inspected by the inbound access rule vs. just the low volume egress traffic that would need to be inspected.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco