cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2610
Views
5
Helpful
7
Replies

Understanding Firewall ACL Rules

Scott Pickles
Level 4
Level 4

I have four connections into an ASA 5520 (outside, user-side [inside], wireless, and stage-dmz).  My understanding is that the interface security levels that are assigned are no longer used once ACLs are applied to the interfaces.  This information comes from a YouTube video on CCNA Security and I have not validated that.  Nevertheless, I have a question regarding how an ASA processes rules.  I want to grant access to my WLAN controller on the 'wireless' interface to access our DC on the 'user-side' for time synchronization via NTP.  The packet tracer indicates that the traffic is blocked by the ACL governing inbound access to the wireless interface.  Why would this be so?  If it is the inbound direction that indicates to me that it is the return traffic from the server on the user-side.  If that is the case, then why would I not have to make any modifications to the inbound ACL on the segment protecting the user-side from the wireless side?  I would expect that if anything I would have to explicitly permit the inbound access to the ntp service on the user-side where the server is located, thus protecting it from inbound access from the wireless side in the same way we would protect the outside interface from the internet at large.  I have read some books on the ASA platform, and most of them are just targeted reads on how to configure scenarios.  Are there any books out there that really dig into the theory of operation of the ASA platform and how the firewall goes about making decisions for allowing traffic or not?  As an example, I know I don't have to explicitly permit return traffic on an interface if I am inspecting the traffic.  But I'm not inspecting anything other than the defaults and a couple of added rules.  Packet tracer is a good tool as it shows how the ASA processes the packet in a linear fashion from the starting interface to the ending interface.  But in my case, it stops before reaching the icon of the route processor on the ASA to route from the source interface to the destination interface, dropping it at the 'wireless_access_in' ACL, applied on the wireless interface in the inbound direction.  How can packet tracer show me that the packet is dropped by the 'wireless_access_in' ACL when the traffic hasn't even made it OUT of the interface yet?

1 Accepted Solution

Accepted Solutions

Scott

Is the 'wireless_access_in' traffic processing OUTBOUND traffic?

Try not to think of it like this because I think this is where your confusion is coming from.

The wireless_access_in acl is processing traffic inbound to the wireless interface.

So it is not traffic inbound to devices on the wireless subnet it is traffic coming from devices in the wireless subnet to the ASA.

The inbound and outbound are in all relation to the ASA.

And so when the controller initiates a connection to the inside the ASA sees the destination IP is on the inside and then compares the wireless interface security level with the inside security level and sees that the wireless interface has a lower security level ie. it is not as trusted as the inside interface.

So the logical place for the ASA to control that access would be on the wireless interface and that is why you need an acl applied inbound on that interface to allow the traffic.

Hope that makes more sense, if not please come back with your doubts.

Jon

 

View solution in original post

7 Replies 7

Jon Marshall
Hall of Fame
Hall of Fame

I want to grant access to my WLAN controller on the 'wireless' interface to access our DC on the 'user-side' for time synchronization via NTP.  The packet tracer indicates that the traffic is blocked by the ACL governing inbound access to the wireless interface.  Why would this be so?

It depends on where the connection is initiated from and the security level.

Traffic is allowed from a higher to lower security level interface by default ie. no acl.

Traffic from a lower to higher security level needs to be allowed with an acl.

So if a device on the inside sent traffic to the controller it would be allowed without an acl and because the ASA is stateful the return traffic bypasses any acl checks and so is allowed back.

But if the controller initiates the connection to the inside that traffic will only be allowed if you have permitted it with an inbound acl on the wireless interface because it is traffic from a lower to higher security level.

The return traffic is again allowed because it is stateful and the ASA has an entry in the state table.

Jon

Jon - 

Thanks for the reply.  So it must be that I am thinking of the security levels wrong.  Let me craft a diagram that I can use for illustration and post that.

Regards,

Scott

Attached is a diagram that I think captures what you're saying.

Jon - 

So I uploaded a quick diagram that details how I look at things and clearly the ASA views it differently than I do.  I look at things like doors that allow things in and out with a bouncer at the door.  If it's traffic from a higher security zone to a lower one, there is no ACL requirement and the state handles the return traffic from what would be a low to high on the return path.  My understanding is that the risk is only on the low to high and that the bouncer on the higher level security zone is the one that cares about whether or not to let the traffic in.  Since the NTP reply will be a return traffic, the state should permit the return traffic.  So are the ACL names, created by default on the ASA according to the direction, misleading?  Is the 'wireless_access_in' traffic processing OUTBOUND traffic?  This is where I get so confused.  When going from a low to high either the egress (low) should expressly permit the OUTBOUND connection, the ingress (high) should expressly permit the INBOUND connection, or both.  I don't understand why this example has ANYTHING to do with inbound access on the wireless interface, as identified by the packet tracer as 'wireless_access_in'.

Scott

Is the 'wireless_access_in' traffic processing OUTBOUND traffic?

Try not to think of it like this because I think this is where your confusion is coming from.

The wireless_access_in acl is processing traffic inbound to the wireless interface.

So it is not traffic inbound to devices on the wireless subnet it is traffic coming from devices in the wireless subnet to the ASA.

The inbound and outbound are in all relation to the ASA.

And so when the controller initiates a connection to the inside the ASA sees the destination IP is on the inside and then compares the wireless interface security level with the inside security level and sees that the wireless interface has a lower security level ie. it is not as trusted as the inside interface.

So the logical place for the ASA to control that access would be on the wireless interface and that is why you need an acl applied inbound on that interface to allow the traffic.

Hope that makes more sense, if not please come back with your doubts.

Jon

 

Jon - 

Your post, in conjunction with the following video at 9:15, I think is what just blew the doors open on this one for me.  I'm going to do another diagram in the next day or so to try and put this into better perspective and you can take a look:

https://www.youtube.com/watch?v=PYxA4CyqwAY

Thanks,
Scott

Jon - 

So I uploaded a quick diagram that details how I look at things and clearly the ASA views it differently than I do.  I look at things like doors that allow things in and out with a bouncer at the door.  If it's traffic from a higher security zone to a lower one, there is no ACL requirement and the state handles the return traffic from what would be a low to high on the return path.  My understanding is that the risk is only on the low to high and that the bouncer on the higher level security zone is the one that cares about whether or not to let the traffic in.  Since the NTP reply will be a return traffic, the state should permit the return traffic.  So are the ACL names, created by default on the ASA according to the direction, misleading?  Is the 'wireless_access_in' traffic processing OUTBOUND traffic?  This is where I get so confused.  When going from a low to high either the egress (low) should expressly permit the OUTBOUND connection, the ingress (high) should expressly permit the INBOUND connection, or both.  I don't understand why this example has ANYTHING to do with inbound access on the wireless interface, as identified by the packet tracer as 'wireless_access_in'.

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: