top of page
Search

Magic of ACLs on Cisco WLC


ACLs on the WLC are meant to restrict or permit wireless clients to services on its WLAN.

Before WLC firmware version 4.0, ACLs are bypassed on the Management Interface, so you cannot affect traffic destined to the WLC other than preventing wireless clients from managing the controller with the Management Via Wireless option. Therefore, ACLs can only be applied to dynamic interfaces. In WLC firmware version 4.0, there are CPU ACLs which can filter traffic destined for the Management Interface. An example of how to configure CPU ACLs is provided later in this document.

You can define up to 64 ACLs, each with up to 64 rules (or filters). Each rule has parameters that affect its action. When a packet matches all of the parameters for a rule, the action set for that rule is applied to the packet. You can configure ACLs through either the GUI or the CLI.

These are some of the rules you need to understand before you configure an ACL on the WLC:

  • If the source and destination are any, the direction in which this ACL is applied can be any.

  • If either the source or destination are not any, then the direction of the filter must be specified, and an inverse statement in the opposite direction must be created.

  • The WLC's notion of inbound versus outbound is nonintuitive. It is from the perspective of the WLC facing towards the wireless client, rather than from the perspective of the client. So, inbound direction means a packet that comes into the WLC from the wireless client and outbound direction means a packet that exits from the WLC towards the wireless client.

  • There is an implicit deny at the end of the ACL.

Considerations When Configuring ACLs in WLCs

ALCs in WLCs work differently than in routers. These are a few things to remember when you configure ACLs in WLCs:

  • The most common mistake is to select IP when you intend to deny or allow IP packets. Because you select what is inside the IP packet, you end up denying or allowing IP-in-IP packets.

  • Controller ACLs cannot block 1.1.1.1 (virtual IP address), and hence DHCP packets for wireless clients.

  • Controller ACLs cannot block multicast traffic received from wired networks that is destined to wireless clients. Controller ACLs are processed for multicast traffic initiated from wireless clients, destined to wired networks or other wireless clients on the same controller.

  • Unlike a router, the ACL controls traffic in both directions when applied to an interface, but it does not perform stateful firewalling. If you forget to open a hole in the ACL for returning traffic, this causes a problem.

  • Controller ACLs only block IP packets. You cannot block Layer 2 ACLs or Layer 3 packets that are not IP.

  • Controller ACLs do not use inverse masks like the routers. Here, 255 means match that octet of the IP address exactly.

  • ACLs on the controller are done in software and impact forwarding performance.

Note: If you apply an ACL to an interface or a WLAN, wireless throughput is degraded and can lead to potential loss of packets. In order to improve throughput, remove the ACL from the interface or WLAN and move the ACL to a neighboring wired device.

Here is a trick how to use create ACLs on WLC as quick as possible>

Creating ACLs in the WLC Graphical User Interface (GUI) is a indeed a pain in the neck . Now I will show you how to create many ACLs on CLI more efficient and faster than ever.

Issue the following commands on CLI:

  • show run-config

  • Copy all commands from “acl create” to “acl apply”

  • copy them in an editor like Notepad etc.

  • Find & replace “—More—or (q)uit”

  • Log into the new controller

  • WLC2(configuration mode)#Paste in the commands

  • save config

TRADEMARK LEGAL NOTICE All product names, logos, and brands are property of their respective owners in the Austria or other countries.All company, product and service names used on this website are for identification purposes only. Pheniix is notaffiliated with or an official partner of Cisco, CompTIA,Dimension Data, VMware, Amazon, Microsoft, Certified Ethical Hacker, (ISC)², Juniper, Wireshark, Offensive Security,Google, GNS3, F5, Python, Linux, Java, Openstack, Vagrant, Ansible, Docker, GIT, , Blockchain or other companies.Use of these names, logos, and brands does not imply endorsement.The opinions expressed on pheniix are personal perspectives and not those of Cisco , Dimension Data or any other company. Pheniix runs as an independent blog.

#Wireless #CiscoSecurity #Cybersecurity #MikeGhahremani #Pheniix #ACL #AccessControl #WLC #CLI

bottom of page