DNS-BASED ACL IN WLC

[jucape2009]

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!

[mikehallevms]

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?

[patrick.kofler]

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.

[gadholwi1]

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.

[patrick.kofler]

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

[gadholwi1]

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

[diondohmen]

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?

[diondohmen]

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

[O_A_H]

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?