Dynamic Authorization Failed - No Response has been received - CoA

[Arne Bier]

Hello,

Issue - I see these in the Dashboard Alarms and I want to know the cause.

The PAN, MNT and PSN are all on the same subnet.

ISE 3.3p3

Catalyst switch: IOS-XE17.06.05 (but happens on other versions too)

I need some advice with why ISE is reporting that CoA failed, when I can successfully do the following:

• In Context Visibility, CoA Session Reauth - always successful
• When Endpoint is seen in ISE for the first time, I see in Live Logs that the profiler causes CoA to be sent successfully
• In the cases above, the CoA is always successfully ACK'd by the IOS-XE

However, the event I cannot understand or reproduce, is this one - anyone know what triggers it? Notice the UDP/3799 - I only have Cisco equipment and everything is using UDP/1700.  

I have a horrible suspicion that the trigger for the CoA is NOT coming from the PSN, as is shown above, but either from the MNT or the PAN, and then sent to the PSN (ISE internal) - and possibly something internal to ISE is broken. 

I should also mention that the ISE Authorization Profile returned to the switch is a simple Access-Accept and I don't set any Session-Timeouts.  The screenshot above seems to indicate that this event was triggered by the Profiler. The profiling works just fine and no CoA errors when ISE detects a new endpoint.  

[MHM Cisco World]

CoA request send by ISE toward NAD and response from NAD to ISE 
so error you see in ISE indicate that the CoA response not received from NAD
check if any FW close the CoA Port (1700)

MHM

[Arne Bier]

I know perfectly well how CoA works and as you can re-read my original posting, CoA is actually working for both manually triggered Reauths (in Context Visibility), as well as during the first authentication of the endpoint - it's all working well.  

The issue I am facing is due to some process in ISE that decides occasionally that it will initiate a CoA (who reasons unknown to me) and then ISE gets no response to the CoA.  But in all other cases ISE gets a response to the CoA.  

I have no determined what this trigger in ISE is - if I did, I could reproduce the problem and run captures to see what's going wrong. 

PAN, MNT and PSN are all on the same IP subnet, as I said in my posting - since it's on the same subnet, there is no firewall.

[MHM Cisco World]

Cisco Bug: CSCwe09064 - ISE 3.2: COA triggered from ISE for a 3rd Party NAD which doesn't support COA

check this 

MHM

[Arne Bier]

Cisco is not a 3rd party product

[andrewswanson]

The ISE node 3.0 communications diagram below shows the following CoA udp/3799 traffic

RADIUS CoA: udp/3799 (PAN thru PSN)
RADIUS CoA: udp/3799 (PSN to PSN CoAs)

As you only have 1 PSN, maybe the CoA is being sent from PAN to PSN. Do you have trustsec enabled in this deployment? If so, how are the nads configured for Trustsec Notification and Updates - CoA is the default. Is the "send from" option set to the pan or the psn?

hth
Andy

[Arne Bier]

I considered the requirement to allow UDP/3799 to be for 3rd party devices that implement the modern CoA port standard (e.g. Aruba) - and UDP/1700 used for Cisco devices only. But I had not thought about UDP/3799 being sent, even when a Cisco Catalyst is involved.  The other confusing thing is that when we read/learn about CoA, the story is always "the RADIUS server send CoA to the NAD" - thus, I don't expect the CoA to come from a dedicated PAN node.

My setup is 2 x PAN, 2 x MNT, 2 x PSN - and the primary PAN/MNT/PSN is on IP subnet A, and the secondaries are on IP subnet B - there is no firewall on the same subnet, or between subnets - these are dedicated management VLANs.

The question about CTS is a good one. I don't intentionally have or want CTS (we don't do SDA), but it's been forced onto me because of DNAC provisioning. When DNAC provisions a device that uses RADIUS, then the Catalyst will use "PAC" mode - which is great in theory (to make the shared secret harder to crack) but comes with a load of overhead and headaches that I wish I didn't have. TLS 1.0 is the first nightmare - as long as CTS is in your network, you cannot disable TLS 1.0 support in ISE. the EAP-FAST is used for PAC provisioning and this uses TLS 1.0 - ISE 3.4 and IOS-XE 17.15.1 have PAC-less provisioning, but Catalyst Center has not yet joined the party.

So, to answer your question, yes we have CTS config on switches, and I am keen to rip it out if I could - and if for some reason the device has some messed up configuration where the CTS component of the switch is not communicating correctly with ISE, you have errors in ISE. Perhaps that's the problem here. I also noticed that if ISE has some messed up or incorrect CTS config for that NAD, then it will send spurious CoA messages to a NAD that perhaps no longer responds to CTS. 

In an ideal world, when commissioning a switch with DNAC, where DNAC is integrated with ISE (pxGrid), the plan is as follows:

• Switch does not yet exist in ISE 
• Switch does not yet exist in DNAC
• Switch has no AAA/TACACS configuration

Step 1 is to add the switch to DNAC. Then assign switch to a DNAC Site, then provision switch with DNAC. After doing all that, ISE will have the switch added (with all the RADIUS, TACACS, SNMP and CTS PAC "stuff" put there by DNAC). Happy days.

When such a greenfield switch has been provisioned by DNAC, and where the switch RADIUS/AAA/CTS config is not touched by the CLI, then you have no issues. But in the real world we often end up having to provision brownfield switches with DNAC (where ISE already has knowledge of the switch, but all the CTS/PAC stuff is missing), and then we see all types of anomalies, because of config inconsistencies. I have not found the method to retrofit the ISE config in the way that it ends up with all the config it needs to talk CTS (identical to a clean DNAC onboarding). My only solution has been to delete the device from ISE, and delete from DNAC, and wipe the aaa/radius/tacacs commands from the switch, and start from fresh. If there is an easier way I'd like to know what it is.