Cisco ISE load-balancing and Change of Authorization (CoA)

Question

First, let me clearly state that I do not have a Cisco background. I have no experience with the RADIUS protocol, and am not familiar with the details of the CoA, so I am not in a position to know if what I'm being asked to do is appropriate/necessary/makes sense or not.&nbsp;
Our Cisco guys came to me asking for a RADIUS load-balancing VIP, with persistence based on CALLING-STATION-ID. I found https://devcentral.f5.com/questions/load-balance-cisco-ise-servers easily enough. So I created a wildcard UDP VIP with the iRule.&nbsp;
But, they came back with an additional CoA requirement. They claim that the ISE servers periodically send "a CoA packet" to the clients of the RADIUS VIP. They want the LTM to intercept these packets, and SNAT it from the RADIUS VIP address. They claim that the clients of the RADIUS service will only accept CoA packets from the VIP address.&nbsp;
Apart from the link above, the only good resource on the subject I can find is https://supportforums.cisco.com/blog/153056/ise-and-load-balancing. I get somewhat lost in the terminology, but this statement seems important:&nbsp;

Each PSN gets listed individually in the Dynamic-Authorization (CoA).  Use the real IP Address of the PSN, not the VIP.&nbsp;

In the context of this document it sounds to me like the "PSN" is also the Pool Member of the RADIUS VIP, and that we should be adding the IP address of the Pool Member in some CoA field on the clients of the RADIUS VIP. But again not being familiar with RADIUS, I'm very uncertain.&nbsp;
Apart from the question of whether or not I can SNAT from a VIP address at all (which I highly doubt), does anyone have some insight into how to account for these RADIUS/CoA packets in a load-balancing context?&nbsp;

jackf_39445 · Answer

Yes that is correct--you do need to account for that.  You want a forwarding VS from the PSN network outbound: UDP/0.0.0.0:1700 --and to that VS assign a SNAT Pool that uses the same IP as the RADIUS server VS IP.  This way the clients believe the server (which to them is the F5 VS) is responding.  &nbsp;
I also just posted the updated iRule that worked best for us to the main thread, which is: 
when CLIENT_ACCEPTED {
  set framed_ip [RADIUS::avp 8 ip4]
  set calling_station_id [RADIUS::avp 31 "string"]
  log local0. "request from $calling_station_id:$framed_ip"
  persist uie "$calling_station_id:$framed_ip"
}&nbsp;

jackf · Answer

Yes that is correct--you do need to account for that.  You want a forwarding VS from the PSN network outbound: UDP/0.0.0.0:1700 --and to that VS assign a SNAT Pool that uses the same IP as the RADIUS server VS IP.  This way the clients believe the server (which to them is the F5 VS) is responding.  &nbsp;
I also just posted the updated iRule that worked best for us to the main thread, which is: 
when CLIENT_ACCEPTED {
  set framed_ip [RADIUS::avp 8 ip4]
  set calling_station_id [RADIUS::avp 31 "string"]
  log local0. "request from $calling_station_id:$framed_ip"
  persist uie "$calling_station_id:$framed_ip"
}&nbsp;

smp_86112 · Answer

Thank you for yourresponse JackF. What you have described seems like what I am being asked for. However, if there is a way to do this outside the LTM, that is my preference. I realize now that same preference might not be shared by everyone in this forum, and might be partially responsible for the approach you have decided to take.

So after having digested your response, my question can be changed slightly to whether or not the same effect might be achieved by doing what the Cisco forum article I reference instructs:  
("Each PSN gets listed individually in the Dynamic-Authorization (CoA). Use the real IP Address of the PSN, not the VIP.")
I read that as meaning you simply add the IP addresses of the RADIUS/ISE F5 Nodes into some "Dynamic Authorization" field on the "client of the RADIUS VIP". That's obviously my term, and I'm reading into that statement up above slightly because it doesn't come out and explicitly state this. But in context, that's how I read it. Wondering if that interpretation is right or wrong.

smp_86112 · Answer

Thank you for yourresponse JackF. What you have described seems like what I am being asked for. However, if there is a way to do this outside the LTM, that is my preference. I realize now that same preference might not be shared by everyone in this forum, and might be partially responsible for the approach you have decided to take.

So after having digested your response, my question can be changed slightly to whether or not the same effect might be achieved by doing what the Cisco forum article I reference instructs:  
("Each PSN gets listed individually in the Dynamic-Authorization (CoA). Use the real IP Address of the PSN, not the VIP.")
I read that as meaning you simply add the IP addresses of the RADIUS/ISE F5 Nodes into some "Dynamic Authorization" field on the "client of the RADIUS VIP". That's obviously my term, and I'm reading into that statement up above slightly because it doesn't come out and explicitly state this. But in context, that's how I read it. Wondering if that interpretation is right or wrong.

jason_47442 · Answer

The real trick if you are using ISE for mobile/guest provisioning is to redirect the user to the same PSN that they authenticated to on tcp/8443 when that call comes in. The persist method in this case wouldn't work as there would be no radius attributes. Furthermore, if the guest SSID is anchored in a DMZ (Best practice) the radius authentication is done on the local controller before the client can request DHCP. So the radius framed IP address is null in this scenario. I know Cisco states to LB on the MAC &amp; IP as a best practice, but in the anchor scenario I don't believe it will work.&nbsp;
Also it's a bad idea to SNAT with the LTM for ISE RADIUS. ISE does not use the RADIUS NAS-IP field to determine the NAS. It uses the source IP address. So you would be writing authorization rules based on the LTM address rather than the real NAS.&nbsp;
Chances are if you are talking about CoA you're doing some type of NAC either switch based or WLC based, possibly both. While there are many radius fields you can use to narrow down the type of traffic to send authentication to the appropriate ISE policy sets, if the NAS IP was passed through then you wouldn't have to write as granular a selection rule set, not to mention make the reporting logs much more attractive.&nbsp;
Route to ISE via the LTM and make the ISE appliances default gateway a self IP of the LTM. Can be tricky if you need to isolate the ISE appliances with a firewall, you'll need to care out space for the LTM then too as you won't want to bridge the firewall VIA the LTM. That should get you the load balancing as well as the appliance transparency.&nbsp;

Forum Discussion

Cisco ISE load-balancing and Change of Authorization (CoA)

Recent Discussions

ip x-forwarding

F5 ASM API-Protection Policy

ports are showing open on online scanning tool

Upgrade F5 BIGIP

DNS HM Probe issue

Related Content

Re: NGINX for Azure: Load Balancing

Load balancing method specific decision

Load Balancing in a sequential order

Load Balancing versus Application Routing

DNS Topology Load balancing

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS