802.1 IOS 15.0 vs 15.2 different behaviour ?

[pieterh]

I'm rolling out C2960CX switches with IOS v15.2(4)E6 installed
authentication of "normal" clients goes fine (dACL, dVLAN), but have problems with workstation deployment (installation) on this switch.

also tried other IOS: 15.2(6)E2 -> same behavior. 

curent installations are done on (e.g) 2960CG with IOS 15.0(2)SE10a => works fine !

configuration is as much same as possible.

logs at time of problem is:

Apr 10 12:22:09.301: %AUTHMGR-5-START: Starting 'dot1x' for client (xxx.xxx.xxx) on Interface Gi0/8 AuditSessionID .....
Apr 10 12:22:13.006: %AUTHMGR-5-START: Starting 'dot1x' for client (xxx.xxx.xxx) on Interface Gi0/8 AuditSessionID .....
Apr 10 12:22:13.219: %DOT1X-5-SUCCESS: Authentication successful for client (xxx.xxx.xxx) on Interface Gi0/8 .....
Apr 10 12:22:13.299: %AUTHMGR-5-FAIL: Authorization failed or unapplied for client (xxx.xxx.xxx) on Interface Gi0/8 .....
Apr 10 12:22:13.303: %DOT1X-5-RESULT_OVERRIDE: Authentication result overridden for client (a44c.c843.1c3d) on I .....

So authentication successful / authorization failed. 

debug output shows radius packet (MS-Windows NPS) with dACL and vlan is received, but seems not applied!

Have done some research and found some reference  (but not for this switch-model) about COA not supported in V15.2

and /or "legacy" radius packet ignored CSCus79132

How can I verify one of above references apply to my situation situations, or the problem lies elsewhere?

[Georg Pauwen]

Hello,

what exactly are you tring to configure ? Post the 'working' 15.0 config and the 15.2 config that doesn't work...

[pieterh]

Hello Georg, thank for your input.

As mentioned I'm trying to move to another model switch with a more recent IOS.

our setup is determined some time ago, before I joined this company.

the global and interface configuration is basically copied from the currently working environment 

the same radius servers are configured (and accessible from the new switch)

But deploying (imaging) new workstations works OK with the 2960-CG and not with the 2960-CX

My colleagues mention the 2960-CG is kept on the old version for exactly the same error, 

but we need to move on to new hardware and IOS; 15.0 is not listed for the 2960-CX it starts at 15.2(3)E  

I look for hints to drill down the issue.

>>>>>

aaa group server radius login-servers
server name L1
server name L2
!
aaa group server radius nps
server name N1
server name N2
!
aaa authentication login default group login-servers local enable
aaa authentication login CONSOLE local enable
aaa authentication dot1x default group nps
aaa authorization console
aaa authorization exec default group login-servers local none
aaa authorization exec CONSOLE local none
aaa authorization network default group nps
!
!
aaa session-id common

dot1x system-auth-control
dot1x guest-vlan supplicant
!
! 

interface GigabitEthernet0/1
switchport access vlan <x>
switchport mode access
switchport voice vlan <y>
authentication event fail action authorize vlan <x>
authentication event no-response action authorize vlan <x>
authentication port-control auto
authentication violation protect
mab
dot1x pae authenticator
dot1x timeout tx-period 3
spanning-tree portfast

<<<<<

[pieterh]

progress status of this post:

a TAC case is opened and Cisco is assisting me, they gave interesting leads, but did not yet find solution .

By own investigation I narrowed it down to the ACL pushed down from Microsoft-NPS to the switch,

the ALC is accepted on the 15.0 switch but not on the 15.2 switch.

when removing or modifying one of the ACE's with syntax 

     ip:inacl#<number>=permit ip <source-network> < mask> <destination> <mask>

to 

     ip:inacl#120=permit ip any <destination> <mask>

the ALC is correctly provisioned to the port

I have found some documentation on IOS12.2 / Cisco-ISE that reads "source MUST be any" ,

as it is a placeholder for Cisco-ISE in combination with ip device tracking

where the source-address of the connected client is replaced in this per-user-ACL

but we do not use Cisco-ISE and IOS 15.2 not 12.2, so I do not think this applies here

Cisco TAC is investigating why this ACE was accepted on 15.0 and is not accepted on 15.2.

[pieterh]

I've got an answer from TAC, but I think the given response does not fully address my issue:
- Kindly be noted that this is expected behavior for switches of 15.x software version,  as the IP device tracking is designed to recognize the “any” keyword and substitute it with the IP of the interface.

They linked a document that may contain the real answer:
For releases earlier than 15.2(1)E, before any feature can use IPDT
it needs to be enabled globally first with this CLI command:
(config)#ip device tracking
For releases 15.2(1)E and later, the ip device tracking command is not needed any more.
IPDT is enabled only if a feature that relies on it enables it.
If no feature enables IPDT, IPDT is disabled.
The "no ip device tracking" command has no effect.
The specific feature has the control to enable/disable IPDT.

With this information:
- On the C2960CG version 15.0 ip device tracking is DISABLED!
and can be manually enabled/disabled
when disabled ip device tracking is not triggered to replace the source "any" in the ACL
-> our original ACE is accepted unchanged

- On the C2960CX versio 15.2 enabling ip device tracking is triggered by enabling specific functions
ip device tracking IS ENABLED, because using dot1x authentication automatically enables it
ip device tracking only accepts source "any" in the ACL
-> our ACL is rejected.

summary:
- when device tracking is not used, source can be specified in the ACL.
15.0 ip device tracking is disabled in our configuration
- when device tracking is used, only source "any" in the ACL is accepted.
15.2 + dot1x -> ip device tracking is allways enabled.

I'm still waiting for TAC to confirm this view.

[pieterh]

This answer from TAC explains different behavior accross IOS versions and platforms.

Comes down that only "any" must be used in the source field of the ACL, disregarding that some in combinations (IOS/platform/configuration) other source field values are accepted by the code.

Our BU team has gone across working and non-working logs. It appears that behavior in 15.0 is little different for INACL in single host mode. If source IP is inserted in INACL in single host mode, sessions will still be authorized. From 15.2 onwards, source IP to be "any" is mandated across all classic platforms (ex 2960, 3750 etc) but nova platforms (ex 3650, 3850 etc) would not check for source IP. Hence, we would not see this behavior in 3650. Source IP to be "any" is basically needed to support use case where same ACL can be shared across different clients. In this case, "any" is replaced programmatically to client's IP address.

Hence, ACL should have source IP as "any". Code is now uniform across host modes whereas in 15.0, there was different action taken for single host mode

[Dong Yeol Park]

i am facing the almost same issue.

switch 3560x with 15.2(4) and radius server is cisco acs.

client pc can not pass the authorizarion after os upgrade from 15.0 to 15.2.

it is really helpful if you share the tac' response or your solution. 

thanks in advance.

[pieterh]

Hi there,
the TAC (=BU team) response is in the previous post
Hence, ACL should have source IP as "any". Code is now uniform across host modes whereas in 15.0, there was different action taken for single host mode

The source field in the ACL must be "any". anything else results in a invalid ACL which results in the acl being ignored.

turn on debugging using the commands debug radius and debug epm
when ACL in error you will see: EPM_SESS_ERR: ACL GigabitEthernet0/1#<dACL-number> provisioning failed!
if succesful you''ll find in the log (search for the inacl)

Jul 3 12:11:05.766: RADIUS: Vendor, Cisco [26] 39
Jul 3 12:11:05.766: RADIUS: Cisco AVpair [1] 33 "ip:inacl#10=permit igmp any any"
Jul 3 12:11:05.766: RADIUS: Vendor, Cisco [26] 57
Jul 3 12:11:05.766: RADIUS: Cisco AVpair [1] 51 "ip:inacl#20=permit ip any <dest-IP1>  <mask>

and

%DOT1X-5-SUCCESS: Authentication successful for client (<mac1>) on Interface Gi0/1 AuditSessionID <sessionid>
%AUTHMGR-7-RESULT: Authentication result 'success' from 'dot1x' for client (<mac1>) on Interface Gi0/1 AuditSessionID <sessionid>
...
EPM_SESS_EVENT:Notifying PD regarding Policy (NAMED ACL) application on the interface GigabitEthernet0/1

[pieterh]

The source field in the ACL must be "any". anything else results in a invalid ACL which results in the acl being ignored.

turn on debugging using the commands debug radius and debug epm
when ACL in error you will see: EPM_SESS_ERR: ACL GigabitEthernet0/1#<dACL-number> provisioning failed!
if succesful you''ll find in the log (search for the inacl)

Jul 3 12:11:05.766: RADIUS: Vendor, Cisco [26] 39
Jul 3 12:11:05.766: RADIUS: Cisco AVpair [1] 33 "ip:inacl#10=permit igmp any any"
Jul 3 12:11:05.766: RADIUS: Vendor, Cisco [26] 57
Jul 3 12:11:05.766: RADIUS: Cisco AVpair [1] 51 "ip:inacl#20=permit ip any <dest-IP1>  <mask>

and

%DOT1X-5-SUCCESS: Authentication successful for client (<mac1>) on Interface Gi0/1 AuditSessionID <sessionid>
%AUTHMGR-7-RESULT: Authentication result 'success' from 'dot1x' for client (<mac1>) on Interface Gi0/1 AuditSessionID <sessionid>
...
EPM_SESS_EVENT:Notifying PD regarding Policy (NAMED ACL) application on the interface GigabitEthernet0/1