cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
809
Views
0
Helpful
5
Replies
Highlighted
Participant

9800-CL WLC DACL issue when using ISE

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

5 REPLIES 5
Highlighted
VIP Rising star

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?

Highlighted

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

Highlighted

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

 

Highlighted
Collaborator

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.

          

Highlighted
Beginner

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.