Common ACL types used in ISE deployments and their precedence

This post builds on my previous post about redirect ACLs. It’s important to know what their function is because they are not all the same. It doesn’t matter if you are using IBNS 1.0 or IBNS 2.0 for your switch configuration. There are four main types of ACLs you will deal with when working with Cisco ISE.

• IOS/IOS XE redirect ACL: Instructs the switch what traffic is to be redirected. Specifically, what traffic to send to the redirect URL that was applied by your ISE authorization result. This ACL is configured on the switch, or IOS XE based wireless controller, and is applied by the authorization result policy.
• Switch Port ACL: Controls what traffic is allowed to pass through the switch port (endpoint to the network). Permit statements define what traffic to allow through the port. Deny statements define what traffic to block. This ACL is configured on the switch, assigned to a port (ip access-group <ACL_Name> in), and applies to all endpoints connected to the port.
• Downloadable ACL: Functions the same as a Port ACL except it is pushed from ISE and applied to the endpoint session. Since it is applied to the session, it only affects the endpoint it was assigned to. A dACL can be used with switches and wireless controllers (IOS XE).
• AireOS Wireless ACL: Functions the same as a Port ACL except when used for redirection (see below). It is configured on the wireless LAN controller (WLC) and called/assigned by an authorization result policy.

Out of the 4 main ACLs, the IOS/IOS XE redirect ACL is the one that operates differently compared to the others. Redirect ACL permit and deny statements do not allow or block traffic. Instead, permit statements dictate what traffic should be sent to the redirect URL (ie portal on the ISE PSN). Deny statements dictate what traffic to ignore and not send to the redirect URL. Redirect ACLs are always processed first in order to determine what traffic needs to be redirected. That’s why it’s a good idea to also utilize a dACL or port ACL to control what services the endpoint is allowed to utilize from the network (ie DHCP and ISE portal) and what traffic is to be blocked.

A standard AireOS ACL functions similarly to a dACL or switch port ACL. Permit statements allow traffic and deny statements drop traffic. A redirect ACL on an AireOS WLC, though, is different than a redirect ACL on a switch or IOS XE based WLC. Permit statements in a wireless ACL dictates what traffic is allowed onto the network. Deny statements dictate what traffic to redirected to the ISE portal (guest, BYOD, etc.). Typically, a wireless redirect ACL has permit statements allowing traffic for DHCP, DNS, ISE PSN access, and then a deny all at the bottom.

IOS/IOS XE ACLs and AireOS wireless ACLs also operate differently in another way. dACLs, and port ACLs assigned using “ip access-group [ACL Name] in”, on a switch are only controlling inbound (endpoint to network) traffic. That means if you allow a connection out the reply traffic will be allowed back. That also means all network traffic going toward the endpoint is allowed by default so you can write rules to permit the endpoint the ability to respond (ie allowing RDP) while still limiting access to the endpoint for the rest of the network.

ACLs in AireOS are also stateless. If you allow traffic out, you must allow the traffic back. You can configure the enforcement direction when configuring an ACL rule in AireOS by designating it as inbound, outbound, or both. Keep in mind that direction is in relation to the WLC. Pretend that you are standing in the place of the WLC facing the client endpoint. Inbound traffic is coming from the client into the WLC. Outbound traffic is going from the WLC to the client. Both is, well, both.

AireOS ACLs cannot be stacked or concatenated. When you assign an ACL to a wireless client, that’s the only one assigned. This isn’t always true with wired clients. A wired switch port in low impact mode will have a port ACL configured and a dACL assigned by ISE when a client is authorized for network access. When that happens, the ACLs are concatenated. The dACL takes precedence over the port ACL. That means if you put a “deny ip any any” or “permit ip any any” in the dACL, the port ACL will not be hit. Having the dACL allow or deny all traffic is perfectly fine. To see how the access lists are concatenated, run show ip access-list interface <interface name>.