Information About DNS-Based Access Control Lists
The DNS-based ACLs are used for wireless client devices. When using these devices, you can set pre-authentication ACLs on the Cisco Catalyst 9800 Series Wireless Controller to determine the data requests that are allowed or blocked.
To enable DNS-based ACLs on the controller , you need to configure the allowed URLs or denied URLs for the ACLs. The URLs need to be pre-configured on the ACL.
With DNS-based ACLs, the client when in registration phase is allowed to connect to the configured URLs. The controller is configured with the ACL name that is returned by the AAA server. If the ACL name is returned by the AAA server, then the ACL is applied to the client for web-redirection.
At the client authentication phase, the AAA server returns the pre-authentication ACL (url-redirect-acl, which is the attribute name given to the AAA server). The DNS snooping is performed on the AP for each client until the registration is complete and the client is in SUPPLICANT PROVISIONING state. When the ACL configured with the URLs is received on the controller , the CAPWAP payload is sent to the AP enabling DNS snooping for the URLs to be snooped.
With URL snooping in place, the AP learns the IP address of the resolved domain name in the DNS response. If the domain name matches the configured URL, then the DNS response is parsed for the IP address, and the IP address is sent to the controller as a CAPWAP payload. The controller adds the IP address to the allowed list of IP addresses and thus the client can access the URLs configured.
During pre-authentication or post-authentication, DNS ACL is applied to the client in the access point. If the client roams from one AP to another AP, the DNS learned IP addresses on the old AP is valid on the new AP as well.
Note |
URL filter needs to be attached to a policy profile in case of the local mode. In the flex mode, the URL filter is attached to the flex profile and it is not need to be attached to a policy profile. |
Note |
DNS based URLs work with active DNS query from the client. Hence, for URL filtering, the DNS should be setup correctly. |
Note |
URL filter takes precedence over punt or redirect ACL, and over custom or static pre-auth ACL.s |
Defining ACLs
Extended ACLs are like standard ACLs but identifies the traffic more precisely.
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
<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 ACL order of ACEs. You can define your statements with sequences of 10, 20, 30, 40, and so on.
The controller GUI allows you to write a complete ACL going to the Configuration > Security > ACL page. You can view a list of protocols to pick from, and make changes to an existing ACL.
Applying ACLs
The following are the ways to apply ACLs:
-
Security ACL: A security ACL defines the type of traffic that should be allowed through the device and that which should be blocked or dropped.
A security ACL is applied:
-
On SVI interfaces: The ACL will only be evaluated against the traffic that is 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 will be evaluated against all traffic that passes through the interface. Along with applying ACLs on SVI, this is another option for restricting traffic on the controller management plane.
Device(config)#interface GigabitEthernet1 Device(config-if)#ip access-group myACL in/out
-
In the wireless policy profile or WLAN: This option includes several places where you can configure an ACL that will be applied to the wireless client traffic, in case of central switching or local switching of traffic. Such ACLs are only supported in the inbound direction.
-
On the AP: In case of FlexConnect local switching, the ACL is configured and applied from the policy profile on the controller. This ACL has to be downloaded on to the AP through the Flex profile. ACLs must be downloaded to the AP before they can be applied. As an exception, fabric mode APs (in case of Software Defined Access) also use Flex ACLs even though the AP is not operating in Flex mode.
-
-
Punt ACL or Redirect ACL: Punt ACL or redirect ACL refers to an ACL that specifies as to which traffic will be sent to the CPU (instead of its normal expected handling by the dataplane) for further processing. For example, the Central Web Authentication (CWA) redirect ACL defines as to which traffic is intercepted and redirected to the web login portal. The ACL does not define any traffic to be dropped or allowed, but follows the regular processing or forwarding rules, and what will be sent to the CPU for interception.
A redirect ACL has an invisible last statement which is an implicit deny. This implicit deny is applied as a security access list entry (and therefore drops traffic that is not explicitly allowed through or sent to the CPU).
Types of URL Filters
The following 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 in the case of external web authentication to allow access to the external login page, as well as, some internal websites before authentication takes place. Post-auth, they can work to block specific websites or allow only specific websites while all the rest is blocked by default. This type of URL filtering post-auth is better handled by using Cisco DNS Layer Security (formerly known as Umbrella) for more flexibility. 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 specification of a different action (deny or permit) for each URL inside the list and have per-URL hit counters.
In both types of URL filters, you can use a wildcard sub-domain such as *.cisco.com. URLfilters are standalone but always applied along with an IP-based ACL. A maximum of 20 URLs are supported in a given URL filter. Considering one URL can resolve multiple IP addresses, only up to 40 resolved IP addresses can be tracked for each client. Only DNS records are tracked by URL filters. The controller or APs do not track the resolved IP address of a URL if the DNS answer uses a CNAME alias record.
Note |
In a scenario where you have a URL filter of type POST and an ACL applied to a policy profile, traffic to the URL is blocked by the ACL if there are no permit statements regarding the URLs. This can occur if the URL filter is POST with permit statement and within the ACL there is no permit statement for the URLs. Therefore, we recommend that you create permit statements within the ACL, regarding the IP address of the URLs, instead of using the POST URL filter. |