cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
754
Views
2
Helpful
6
Replies

ISE 3.2 not sending Vendor Specific Attributes(VSA) in CoA Request

jitendrac
Level 1
Level 1

Hi ISE Community

Looking for some assistance to troubleshoot the CoA Request that ISE is sending to Arista AP ?

I have ISE 3.2 patch 4 running; We have The Arista access point (AP) mojo C-230 as a RADIUS Client. 

We are doing  802.1X with Posture Assessment.

We have defined all settings as per the documentation published by Arista https://wifihelp.arista.com/post/integration-with-cisco-ise-wireless-802-1x-and-mba-use-cases#section-25 

On the Arista WiFI Controller, we have defined 3 User Role Profiles (Unknown, Compliant and Non-Compliant) with Firewall Configuration to restrict traffic. e.g in Compliant Everything is allowed , Non-Compliant only few access is allowed.

On ISE under Authorization Policy we have defined Authorization Rule for each posture status (Unknown, Non-Compliant and Compliant)  Under Advanced Attributes Settings, we have set the role that we have created Arista Controller for clients whose posture is (Unknown, Non-Compliant and Compliant)

Our 802.1X Authentication is successful, The unknown Authorization Policy is also getting triggered with Web redirection. On ISE logs we can see Authorization Profile is moving from Unknown to Non-Compliant however on end point we can see that everything is allowed. 

On Packet Capture on PSN we can see CoA request is going from ISE to AP but not sure why AP is not applying User Role to Session.

Arista TAC is saying that they are not able to see User Role getting pushed from ISE as CoA request and hence default rule is applied which is allow all traffic.

For reference I am attaching packet capture screen shot (ISE PSN is 10.50.40.212 and Arista AP IP is 10.3.246.116)

I think CoA request should have VSA attributes but this is missing in packet capture. Can anyone guide me on this ? 

1 Accepted Solution

Accepted Solutions

Just an Update 

The problem is resolved after we disable CoA Push in the Network Device Profile of Arista AP. 

There are 3 setting in CoA for Network Device Profile

  1. CoA Disconnect (RFC 5176)
  2. CoA Re-authenticate
  3. CoA Push (RFC 5176)

We came to know that Arsta AP Understand CoA Disconnect

Now Flow is 

  1. Access-Request—sent by the client (NAS) requesting access (Radius Code 1)
  2. Access-Challenge—sent by the RADIUS server (ISE) requesting more information in order to allow access. (Radius Code 11)
  3. Access-Request - The NAS, after communicating with the user, responds with another Access-Request. (Radius Code 1)
  4. Access-Accept—sent by the RADIUS server (ISE) allowing access with VSA as Unknown Profile (Radius Code 2)
  5. Accounting-Request—sent by the client (NAS) requesting accounting (Radius Code 4)
  6. Accounting-Response—sent by the RADIUS server (ISE) acknowledging accounting (Radius Code 5)
  7. Posture Starts
  8. Disconnect-Request - (Radius Code 40) sent by the RADIUS server (ISE) after posture Completed 
  9. Accounting-Request—sent by the client (NAS) requesting accounting (Radius Code 4)
  10. Disconnect-ACK - (Radius Code 41) sent by the client (NAS) to RADIUS server (ISE) 
  11. Accounting-Response—sent by the RADIUS server (ISE) acknowledging accounting (Radius Code 5)
  12. Access-Request—sent by the client (NAS) requesting access (Radius Code 1)
  13. Access-Challenge—sent by the RADIUS server (ISE) requesting more information in order to allow access. (Radius Code 11)
  14. Access-Accept—sent by the RADIUS server (ISE) with VSA as Quarantine Or Compliant Profile (Radius Code 2) as per Posture Result
  15. Accounting-Request—sent by the client (NAS) requesting accounting (Radius Code 4)
  16. Accounting-Response—sent by the RADIUS server (ISE) acknowledging accounting (Radius Code 5)

View solution in original post

6 Replies 6

I have no experience with Arista but I don't think the user Role should be in the CoA.  ISE should respond with the client's MAC address telling the Arista AP tp drop/re-authenticate the device.  Then a second RADIUS auth would occur with ISE responding with the correct user group.

Ok thanks for this direction.

Any idea how I can validate that ISE is sending drop or reauth as part of CoA ?

It should be in the packet capture. More importantly though which CoA actions does Arista support?

Packet Capture Shows CoA Request with Type 80 and Length 18 with Message-Authenticator. I have attached a Screenshot for reference

Before CoA i can see RADIUS Access-Accept from ISE to AP with AVP Type 26 (I think RADIUS Type 26 is Vendor-Specific vsa) Under VSA of Type 26 I can see Type 7 Framed-Protocol and I can see Use Role as Unknown Attribute (Here Unknown i believe is User Role "Unknown" that i created) and I can Named Matching in the Packet Capture. Just Look at ScreenShot Attached

On endpoint I am getting redirected to CPP portal. Which indicate that User-Role "Unknown" is getting applied by AP. 

On endpoint after this Posture Scanning Starts .

I can see logs of same in ISE.  Non-Compliant Authorization Rule is also getting trigger but don't know why CoA is not happening after this point. 

Just an Update 

The problem is resolved after we disable CoA Push in the Network Device Profile of Arista AP. 

There are 3 setting in CoA for Network Device Profile

  1. CoA Disconnect (RFC 5176)
  2. CoA Re-authenticate
  3. CoA Push (RFC 5176)

We came to know that Arsta AP Understand CoA Disconnect

Now Flow is 

  1. Access-Request—sent by the client (NAS) requesting access (Radius Code 1)
  2. Access-Challenge—sent by the RADIUS server (ISE) requesting more information in order to allow access. (Radius Code 11)
  3. Access-Request - The NAS, after communicating with the user, responds with another Access-Request. (Radius Code 1)
  4. Access-Accept—sent by the RADIUS server (ISE) allowing access with VSA as Unknown Profile (Radius Code 2)
  5. Accounting-Request—sent by the client (NAS) requesting accounting (Radius Code 4)
  6. Accounting-Response—sent by the RADIUS server (ISE) acknowledging accounting (Radius Code 5)
  7. Posture Starts
  8. Disconnect-Request - (Radius Code 40) sent by the RADIUS server (ISE) after posture Completed 
  9. Accounting-Request—sent by the client (NAS) requesting accounting (Radius Code 4)
  10. Disconnect-ACK - (Radius Code 41) sent by the client (NAS) to RADIUS server (ISE) 
  11. Accounting-Response—sent by the RADIUS server (ISE) acknowledging accounting (Radius Code 5)
  12. Access-Request—sent by the client (NAS) requesting access (Radius Code 1)
  13. Access-Challenge—sent by the RADIUS server (ISE) requesting more information in order to allow access. (Radius Code 11)
  14. Access-Accept—sent by the RADIUS server (ISE) with VSA as Quarantine Or Compliant Profile (Radius Code 2) as per Posture Result
  15. Accounting-Request—sent by the client (NAS) requesting accounting (Radius Code 4)
  16. Accounting-Response—sent by the RADIUS server (ISE) acknowledging accounting (Radius Code 5)