Cisco ISE pushs DACL but switch port doesn't take it

[antonioyan99]

Hi Cisco ISE guru,

I ran into a weird scenario for an ISE deployment,   I have deployed about 700 endpoint into enforcement mode(low impact).

2 endpoints passes dot1x auth/authorization and the session receives "permit ip any any" DACL, the dacl shows up in the output of command " show access-session interface g1/x/x detail" , but the endpoint  still don't have access to the network.

only if the pre-auth-acl is removed from this switch port then the network access restores.

I have tried to move one of the endpoint to another spare port ( with pre-auth-acl) and the issue seems to be resolved.

I have asked the client to reboot the switch to see if this could fix the issue, but it will take some time for approval.

Has anyone ran into same issue?  Is this a switch bug related?

Thanks.

[Damien Miller]

Provide us your port config, switch model, and IOS version, there have been some bugs in the past with DACLs but generally they work. It seems odd that the same switch but different port is working.

One thing that comes to mind is that IP device tracking might not be working correctly. If IPDT doesn't work, the DACL won't work. If you can recreate the issue, see if the IPDT database has an IP recorded for the endpoint.

[antonioyan99]

Here is the global config and port level config: 

policy-map type control subscriber DOT1X-DEFAULT
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x retries 2 retry-time 0 priority 10
20 authenticate using mab priority 20
event authentication-failure match-first
5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
10 activate service-template CRITICAL
20 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
30 authorize
40 terminate dot1x
50 terminate mab
60 pause reauthentication
20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
10 pause reauthentication
20 authorize
30 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
40 class MAB_FAILED do-until-failure
10 terminate mab
20 authentication-restart 60
60 class always do-until-failure
10 terminate dot1x
20 terminate mab
30 authentication-restart 60
event agent-found match-all
10 class always do-until-failure
10 terminate mab
20 authenticate using dot1x retries 2 retry-time 0 priority 10
event aaa-available match-all
10 class IN_CRITICAL_VLAN do-until-failure
10 clear-session
20 class NOT_IN_CRITICAL_VLAN do-until-failure
10 resume reauthentication
event authentication-success match-all
10 class always do-until-failure
10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
event violation match-all
10 class always do-until-failure
10 restrict
!

###switch port configuration
interface range gi1/0/1 - 46

device-tracking attach-policy otppipdt_policy
ip access-group Pre-Auth-ACL in
authentication periodic
authentication timer reauthenticate server
access-session port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 10
service-policy type control subscriber DOT1X-DEFAULT

The switch is C3850 and the IOS is IXE-16.6.4.

I am using 'device-tracking policy' command for  IP tracking and it is working fine.

Thanks.

[michanna]

I seem to have the same issue. Only the ACL-Default access list shows as applied.

[cpaquet]

I saw the same issue at a customer last week, on C3850 IOS 16.09.04.

The interface has a pre-AuthC pACL, but refuses the dACL pushed by ISE, upon successful MAB authentication. I turned on debug radius authentication and saw the same error messages that are listed on Cisco bug report CSCvr13213:

068083: Aug 26 201909:54:47.272 UTC: %SESSION_MGR-5-FAIL: Switch 1 R0/0: sessmgrd: Authorization failed or unapplied for client (0023.247e.5b91) on Interface GigabitEthernet1/0/3 AuditSessionID EEEBEC0A000077EDCD1FE915.

However, our circumstances were different:  we saw that error with a simple MAB authentication (the bug report is about CWA not accepting the redirect-acl).  I applied the fix recommended in the bug report, but it didn't fix the issue at the customer.  Cisco engs are there this week, for hopefully, the customer will let me know if prob was fixed.

[michanna]

Thanks, I will check out that bug notice.

[Damien Miller · Accepted solution]

There have been a couple bugs discovered since this posting. Your issue might be different depending on the IOS release you are on. If you are on 16.6 then there are two potential issues.
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn81334
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvq17759

You're best to open a TAC case to ensure you are not facing a different issue.

[tauk]

Hi,

I had the same issue which got resolved by applying the command on the switch

radius-server vsa send authentication

In my debug radius -> I could see the DACL being downloaded!

Thanks