topic I don't remember testing it. in Wireless

DNS-BASED ACL IN WLC

jucape2009 — Mon, 05 Jul 2021 08:56:24 GMT

I,m trying to use DNS-based ACL with pre-authentication ACL, in order to allow access to some URL's before the client will be authenticate by external captive portal without RADIUS

In the bug search web, ( https://tools.cisco.com/bugsearch/bug/CSCup98797) this bug appears as fixed, but i,m running 7.6.130 code in WLC 5500 and the behavior is the same, URL's has not effect because i,m not using RADIUS.

I see in the Cisco Wireless LAN Controller Configuration Guide, Release 8.0 the following advice:

DNS-based ACLs work only when RADIUS NAC (central web authentication or posture) are done on the SSID. DNS-based ACLs do not work with local web authentication or any other form of ACL other than a redirect-ACL used in the case of RADIUS NAC.

so in 8.0 code the behavior is the same as 7.6.130

I can't understand why Cisco WLC is not able to permit access using URL's instead of ip address without RADIUS, most manufactures can do it, even Meraki that now is part of Cisco can do this. Is imposible open thousand of ip address in the ACL if you want to open facebook or akamai for example.

Anybody knows a workarround to achieve this?

Regards!

I have this problem as well.

mikehallevms — Fri, 04 Sep 2015 12:03:23 GMT

I have this problem as well. In fact, it doesn't work when using radius-NAC either. We are trying to perform posture remediation using ISE for MS Updates in our posture redirect ACL using URL-Based ACE's, have engaged countless TAC engineers to no avail. It is also documented in bug CSCuv74219 for version 8.0 and 8.1 code as well and the workaround hasn't work either. Very discouraging. You would think something so simple and common would be fixed quickly. Whats happening at Cisco these days?

I'm not sure what are you

O_A_H — Fri, 09 Oct 2015 15:53:33 GMT

I'm not sure what are you trying to achieve. But to make Local Web Auth (LWA), you can make the pre-auth-ACL on the WLC & refer to the external URL of the protal. I've tried this previously & worked fine. The issue i faced was that i should configure AAA for the WLAN to get the users authenticated because undoing so will make the authentication fail & nit refering to Local WLC users. Is that what you mean?

The configuration guide

patrick.kofler — Mon, 12 Oct 2015 11:07:45 GMT

The configuration guide states that local web auth is not supported.

I quote from the 7.6 configuration guide Restrictions on DNS-based Access Control Lists

DNS-based ACLs work only when RADIUS NAC (central web authentication or posture) are done on the SSID. DNS-based ACLs do not work with local web authentication or any other form of ACL other than a redirect-ACL used in the case of RADIUS NAC.

I think this has been decided to move the unified access forward by encouraging the use of central web authentication, but that is solely an assumption on my part.

@Mike: Try to enable DHCP address assignment required on the WLAN. This feature invokes DHCP snooping and I wouldn't be surprised if the DNS snooping code of the DNS-ACL feature is somehow (inadvertently) dependent on this function. I have successfully tested it with 7.6.110.0, 8.0.115.0 and ~~8.0.120.0~~ running on a 5508 WLC.

Edit: Shot too early. Thought I was running 8.0.120.0 but 7.6.110.0 was still active. 8.0.120.0 is not working. I went through the bugfixes and discovered one related to DHCP - CSCus85767

BTW release 8.0.110.0 is also working. Interestingly when I disable the DHCP address assignment required again it still works.

Did you test WLC version 8.0

gadholwi1 — Tue, 01 Dec 2015 15:03:10 GMT

Did you test WLC version 8.0.100.0?

I configured an access-list with dns based URL, and the SSID is using Radius NAC and dhcp required. Unfortunately the configuration does not work. Eventually 8.0.100.0 is affected by the bug CSCuv74219 also.

I don't remember testing it.

patrick.kofler — Tue, 12 Jan 2016 14:16:37 GMT

I don't remember testing it. Anyway the only way to resolve it without side effects is either going straight to 8.2.100.0, which is already available on CCO or open a TAC case to receive an image from the 8.0 train containing the bugfix.

You will notice it will work when you get the following messages in the client debug output:

*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff DNS SNOOPING: decode clientMac aa:bb:cc:dd:ee:ff,DomainName[lh3.googleusercontent.com] IpAddr: [173.194.44.44]

*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff Fetched IP address [173.194.44.44] DomainName[lh3.googleusercontent.com]

*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff Round-Robin[index 0, flag 0]   Update[2] the mscb with the IP address in DNS response. removed ip[0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [10.32.9.68]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [173.194.112.39]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [173.194.44.44]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.927: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]
*spamApTask2: Jan 12 14:00:46.928: aa:bb:cc:dd:ee:ff IP Addr Updated in MSCB - [0.0.0.0]

8.2.100.0 also provides double the count of ACL entries as well as IPs the MSCB can hold (20/40 as opposed to 10/20). The above ouput reflects this.

Regards,
Patrick

Thank you for the information

gadholwi1 — Tue, 12 Jan 2016 14:25:05 GMT

Thank you for the information. Infact 8.0.100.0 is suffered by the bug CSCuv74219 (and/or CSCus61445), and DNS-based ACL does not work.

The bug is fixed 8.0.121.0 and 8.2.100.0. I got this information from Cisco TAC.

Unfortunately DNS-based ACL is NOT supported in a foreign-anchor setup (auto-anchor). There is an enhancement request to fix this issue: CSCui81308 Auto Anchor Support for DNS based ACL.

Because we are using an auto-anchor setup, DNS-based ACL is not working for us!

Regards

Hi gadholwi...

diondohmen — Fri, 23 Sep 2016 08:25:12 GMT

Hi gadholwi...

I came across the same issue. We are running 8.0.122.44 and we are only able to use preauthentication-ACL when we know the specific IP addresses of the websites.I have added three URL's but they are not working.

Do you know the status of the enchancement request CSCui81308?

Hi gadholwi1, did you receive

diondohmen — Tue, 08 Nov 2016 08:29:39 GMT

Hi gadholwi1, did you receive an update about enhancement request CSCui81308? Or did you find a different solution to your setup?