ISE, RADIUS, ASAs and DACLs

[FY13]

As per @Craig Hyps's excellent Cisco Live session and how-to guide for ISE Load Balancing, I have configured our Netscaler load balancer to persist/stick to a PSN using the Calling-Station-Id(31) field.

This is great and works well mostly but, when it comes to our AnyConnect VPN users connecting through an ASA, the part of the process where it downloads the ACL poses a problem.

After the CoA-Request & CoA-ACK completes, the ASA then sends an Access-Request packet asking ISE to send it the DACL, however, this Access-Request packet doesn't contain the Calling-Station-Id(31) field. So our Netscaler treats this as a fresh connection, no persistence. So be it, it shouldn't matter.

But, the ASA appears to download the ACL multiple times, once from each load balanced PSN, adding time to the process.

Can anyone explain why, and how to resolve this? (Bear in mind Netscaler doesn't have the in-depth functionality of an F5, like iRules.)

[howon]

It will depend on the size of the ACL. If the ACL exceeds 50+ lines, there is a chance that the dACL download will require more than a single packet in which you will need persistence so same PSN responds to the ASA. It doesn't have to be the same PSN that served the initial authentication, but a single PSN will need to serve dACL download request from start to finish. You can try using username as key for persistence.

[FY13 · Accepted solution]

So, for example, the ASA will ask the PSN for the dACL, PSN1 sends the first ~50 lines, the ASA sends the next 'Access-Request', and PSN1 sends the next ~50 lines but, if PSN2 receives the request, it's unaware of anything and sends the first ~50 lines?

---

A colleague of mine found a resolution on the NetScaler (using the ALT keyword in the persistence rule) which will persist based on source IP if, and only if, Calling-Station-Id(31) doesn't exist in the packet. Similar to this thread.

CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT CLIENT.IP.SRC

[howon]

"So, for example, the ASA will ask the PSN for the dACL, PSN1 sends the first ~50 lines, the ASA sends the next 'Access-Request', and PSN1 sends the next ~50 lines but, if PSN2 receives the request, it's unaware of anything and sends the first ~50 lines?"

Yes, that is correct. That may explain the multiple download behavior you described. Your workaround with RADIUS source IP sounds like a reasonable workaround for dACL request.