9800-CL WLC DACL issue when using ISE

[Madura Malwatte]

I have a 9800-CL WLC running 16.12.2s with ISE 2.6 patch 3.

I am running into a issue getting guest portal flow working where the DACL specified by ISE authz rule is not working in the 9800. The redirect acl works fine, but after when ISE does CoA for DACL, the 9800 reports the following error.

Mar  9 06:54:43.785: %SESSION_MGR-5-FAIL: Chassis 1 R0/0: wncd: Authorization failed or unapplied for client (f099.b619.0fe5) on Interface capwap_9000000c AuditSessionID 288212AC000000A2BE13066D. Failure Reason: ACL Failure. Failed attribute name #ACSACL#-IP-PERMIT_ALL_TRAFFIC-5165e13c.

Mar  9 06:54:43.785: %CLIENT_EXCLUSION_SERVER-5-ADD_TO_BLACKLIST_REASON: Chassis 1 R0/0: wncmgrd: Client MAC: f099.b619.0fe5 was added to exclusion list, reason: ACL failure

I have double/triple checked the ACL including the name and it is matching on ISE and WLC.

The ISE and Catalyst 9800 Series Integration Guide states the following: "Support for dACL requires use of 'default' as authorization list name", could this be the issue I am facing? My AAA Method List on the WLC is using a custom name and not 'default'.

The document also says "In the case of Catalyst 9800, it is recommended to combine the redirect ACL with dACL such as following to limit access during redirected state." - I am confused as why it recommends to do it this way, as it has always been the redirect acl evaluated followed by DACL evaluation (both separate). This thread asks about it too - https://community.cisco.com/t5/network-access-control/ios-xe-16-9-code-portal-redirect-dacl/td-p/4000322

[pieterh]

I encountered an issue where cross different platforms/versions a "wrong" ACE was accepted/ignored/rejected

check the ACL once more -> do you have "any" as the source in the ACL?

[Madura Malwatte]

Yes, most of the ACL lines have "any" as the source. This DACL is to block all internal and allow internet traffic only. Why would this be an issue?

permit udp any eq 68 any eq 67
permit udp any eq 67 any eq 68
permit udp any any eq 53
permit udp any eq 53 any
permit tcp any any eq 53
permit tcp any eq 53 any
permit tcp any host psn1 eq 8443
permit host psn1 eq 8443 any
permit tcp any host psn2 eq 8443
permit host psn2 eq 8443 any
! deny RFC1918
deny ip any 10.0.0.0 0.255.255.255
deny ip 10.0.0.0 0.255.255.255 any
deny ip any 172.16.0.0 0.0.15.255
deny ip 172.16.0.0 0.0.15.255 any
deny ip any 192.168.0.0 0.0.255.255
deny ip 192.168.0.0 0.0.255.255 any
! permit everything else
permit ip any any

[pieterh]

Hi sorry was not clear.

having any is not the problem, but NOT having any is the problem.

the devices use ANY only as a placeholder

effectively ANY is replaced by the ip-address of the client detected by DHCP snooping and related functions.

as such all ACE's  in a dACL must have any as the source address

like in this guide

   Per-User ACLs and Filter-Ids
  Note: You can only set any as the source in the ACL.
  Note: For any ACL configured for multiple-host mode, the source portion of statement must be any.
           (For example, permit icmp any host 10.10.1.1 .)

 try if the error returns when you removed the ACEs that did not contain "any" as source portion

by the way "permit host psn1 eq 8443 any" does not seem correct I'm missing the ip/tcp/udp keyword

[Arshad Safrulla]

Hi, is the above the Pre-Auth redirection ACL or the ? Are you sure that below part of the ACL? 

deny ip any 10.0.0.0 0.255.255.255
deny ip 10.0.0.0 0.255.255.255 any
deny ip any 172.16.0.0 0.0.15.255
deny ip 172.16.0.0 0.0.15.255 any
deny ip any 192.168.0.0 0.0.255.255
deny ip 192.168.0.0 0.0.255.255 any

If the above is the redirection ACL, i would get rid of all the above with th permit ip any any at the end and add deny ip any any as in IOS-XE denied traffic is the interested traffic to be redirected.

[Cristian Matei]

Hi,

    The problem with "default" and "non-default" authorization list is the following: when using the "default" list, it applies to all authorisations where that RADIUS server is being used, hence the name default, if it exists, everything makes use of it. When you configure a "non-default" list, it is not used, unless applied somewhere, like at the SSID level, which is not supported. The message "Failure Reason: ACL Failure" could either mean that there is something wrong with the ACL so it can't be applied, or there is nothing wrong with the ACL but it can't be applied as it can't match any authorization list.

    I would do the following:

              - use a default list, see if it works; if it works and still want to use a named list, for whatever reason, in order for WLC to match it, you would need to return the name of that list in the authorization received from ISE, via Cisco AVPair of "Method-List"

             - otherwise ensure the dACL is valid

Regards,

Cristian Matei.

[franklinb]

Since you mentioned Guest I assume this won't be a flex session but just on the chance it is, this is a similar error to the one I had. I had applied a dACL to the AuthZ result and I was getting the same error message. Of course I should not have been trying to apply a dACL given it was a FlexConnect WLAN. Removing the dACL from the AuthZ result fixed my issue. 

[OCT]

i am encountering issue where my redirect is not working, under monitoring client details security i can see the redirect URL but not getting the redirect on PC or Mobile device. On the mobile device you have the option to manage the router. When clicking on this it redirect to the default gateway and only then to the Guest login redirect page from ISE.

for the ACL DACL on ISE cisco av pair it needs to match under Authorization Profiles, Advance Attribute settings

cisco:cisco-av-pair = Method-List=ISE_AUTHZ to your controller  AAA Method list Authorization Name ISE_AUTHZ

can you maybe share your config for Guest ?

many thanks

[laposilaszlo]

Hi,

Seems i have the same problem.

Did you ever got to a solution with this problem.

Thanks

Laszlo