DNS-based access control lists
A DNS-based access control list is a wireless network security feature that
-
allows administrators to permit or deny wireless client access to resources based on DNS domain names
-
dynamically learns allowed or denied IP addresses through DNS snooping on access points, and
-
enables pre-authentication and post-authentication URL filtering for enhanced client security.
DNS-based ACLs are used for wireless client devices. You can set pre-authentication ACLs on the Cisco Catalyst 9800 Series Wireless Controller to determine which data requests are allowed or blocked.
To enable DNS-based ACLs on the controller, configure the allowed or denied URLs for the ACLs. The URLs need to be pre-configured on the ACL.
During the registration phase, DNS-based ACLs allow the client to connect to the configured URLs. The controller is configured with the ACL name provided by the AAA server. If the AAA server returns the ACL name, the controller applies the ACL to the client for web redirection.
During client authentication, the AAA server returns the pre-authentication ACL (url-redirect-acl), which is the attribute name assigned to the ACL by the AAA server. The AP performs DNS snooping for each client until registration is complete and the client reaches the SUPPLICANT PROVISIONING state. When the controller receives the ACL configured with URLs, it sends a CAPWAP payload to the access point to enable DNS snooping for those URLs.
After URL snooping is enabled, the access point learns the IP address of the resolved domain name from the DNS response. If the domain name matches the configured URL, the access point parses the DNS response for the IP address and sends the IP address to the controller as a CAPWAP payload. The controller adds the IP address to the allowed list, which enables the client to access the configured URLs.
During pre-authentication or post-authentication, the DNS ACL is applied to the client in the AP. If the client roams from one AP to another AP, tthe DNS-learned IP addresses from the previous access point remain valid on the new AP.
![]() Note |
Attach the URL filter to a policy profile for local mode. In FlexConnect mode, attach the URL filter to the flex profile; attaching it to a policy profile is not required. |
![]() Note |
DNS-based URLs require an active DNS query from the client. For URL filtering to work, configure DNS settings correctly. |
![]() Note |
The URL filter takes precedence over punt or redirect ACLs, as well as custom or static pre-authentication ACLs. |
Define ACLs
Extended ACLs are similar to standard ACLs, but they identify traffic more precisely.
-
These commands allow you to define ACLs by name or by identification number. Device(config)#ip access-list extended ? <100-199> Extended IP access-list number <2000-2699> Extended IP access-list number (expanded range) WORD Access-list name -
This is the structure of a CLI ACL statement:
<sequence number> [permit/deny] <protocol> <address or any> eq <port number> <subnet> <wildcard> -
For example:
1 permit tcp any eq www 192.168.1.0 0.0.0.255
The sequence number specifies where to insert the Access Control List Entry (ACE) in the order of ACEs within the ACL. You can define your statements using sequence numbers such as 10, 20, 30, 40, and so on.
The controller GUI allows you to write a complete ACL by going to the Configuration > Security > ACL page. You can view a list of protocols to choose from and make changes to an existing ACL.
Methods for applying ACLs
Security ACL: A security ACL defines the types of traffic to allow through the device and the types to block or drop. A security ACL can be applied in various scenarios:
-
On SVI interfaces: The ACL is evaluated only against traffic routed through the interface. Device(config)# interface Vlan<number>Device(config-if)# ip access-group myACL in/out -
On a physical interface of the controller: The ACL is evaluated against all traffic passing through the interface. This method also restricts traffic on the controller management plane, along with SVI interface application. Device(config)#interface GigabitEthernet1Device(config-if)#ip access-group myACL in/out
In the wireless policy profile or WLAN. You can configure an ACL to apply to wireless client traffic in cases of central or local traffic switching. These ACLs are supported only in the inbound direction.
On the AP during FlexConnect local switching. The ACL is configured and applied from the policy profile on the controller. The ACL must be downloaded to the AP through the FlexConnect profile before it can be applied. Fabric mode APs in Software Defined Access also use Flex ACLs, even though these APs are not operating in FlexConnect mode.
A punt ACL or redirect ACL specifies which traffic is sent to the CPU for further processing instead of normal handling by the dataplane. For example, the Central Web Authentication (CWA) redirect ACL determines which traffic is intercepted and redirected to the web login portal. The ACL does not define traffic to drop or allow. It follows normal processing or forwarding rules and identifies what is sent to the CPU for interception.
A redirect ACL includes an implicit deny statement at the end. This security access list entry drops any traffic not explicitly allowed or sent to the CPU.
URL filters
A URL filter is a wireless network access control feature that
-
restricts access to websites based on specified URLs
-
can operate before or after client authentication, and
-
is applied together with an IP-based ACL for granular access control.
There are the two types of URL filters:
-
Standard: Standard URL filters can be applied before client authentication (pre-auth) or after a successful client authentication (post-auth). Pre-auth filters are extremely useful for external web authentication because they allow access to the external login page and some internal websites before authentication takes place. After authentication, filters can block specific websites or allow only selected websites, while all other websites are blocked by default. After authentication, this type of URL filtering can be handled more flexibly by using Cisco DNS Layer Security (formerly called Umbrella). The standard URL filters apply the same action (permit or deny) for the whole list of URLs. It is either all permit or all deny.
-
Enhanced: Enhanced URL filters allow you to specify a different action (deny or permit) for each URL in the list and include per-URL hit counters.
In both types of URL filters, you can use a wildcard sub-domain such as *.cisco.com. URL filters are standalone features but are always applied together with an IP-based ACL. A maximum of 20 URLs are supported in a given URL filter. Because one URL can resolve to multiple IP addresses, each client can track up to 40 resolved IP addresses. URL filters track only DNS records. The controller or APs do not track the resolved IP address if the DNS response uses a CNAME alias record.
![]() Note |
If you have a POST-type URL filter and an ACL applied to a policy profile, the ACL blocks traffic to the URL if it does not include permit statements for the URLs. This issue can occur when the URL filter is POST with a permit statement but the ACL does not include a permit statement for the URLs. We recommend creating permit statements within the ACL for the IP addresses of the URLs rather than relying on the POST URL filter. |

Feedback