09-24-2013 08:51 AM - edited 03-10-2019 08:55 PM
I'm working on a solution where we have NetScaler load balancers distributing radius requests from the NADs to respectvie PSNs. Authentication works and redirect URLs work etc.. The challenge we're having is with EAP-TLS sessions. The user get's a provisioned certificate and chain that checks out on the endpoint fine. When the user tries to connect with the device we see EAP timeouts from the ISE session to the supplicant. Each PSN has the internal identity cert configured for EAP authentication that has been configured from the same internal CA within the customers PKI.
Has anyone configured a NetScaler for use with ISE and besides the general guidlines below are there more specific things that need to be done to make this work with Citrix NetScalers?
Load Balancing guidelines.
No NAT.
Perform sticky (aka: persistence) based on Calling-Station-ID and Framed-IP-address
VIP for PSNs gets listed as the RADIUS server on each NAD for all RADIUS AAA.
Each PSN gets listed individually in the NAD CoA list by real IP address (not VIP).
Load Balancers get listed as NADs in ISE so their test authentications may be answered.
ISE uses the Layer 3 address to identify the NAD, not the NAS-IP-Address in the RADIUS packet. This is a primary reason to avoid Source NAT (SNAT) for traffic sent to VIP.
Solved! Go to Solution.
05-04-2015 11:56 AM
Ken,
Do you have a RNAT configuration on your NS for the COA packets? This will re-write the from address of the packet so your NAD will see the packet coming from your NS VIP.
add ns acl COA ALLOW -srcIP = <Range of source ISE IP's to catch> -destPort = 1700 -protocol UDP
set rnat COA -natIP <IP of VIP>
Nick
05-06-2015 07:50 AM
Just tried to apply the add ns acl command above and we get an error that the add command is not found. We're running NetScaler 10.1, did they use a different syntax for that release?
05-06-2015 08:23 AM
Got the commands to take, just want to make sure I have this right. My VIP is 172.18.75.82 and my policy server is 172.18.68.53.
We sent the following commands.
add ns acl COA ALLOW -srcIP = 172.18.68.53 -destPort = 1700 -protocol UDP
apply ns acls
set rnat COA -natIP 172.18.75.82
Do we have that right or is it backwards?
05-06-2015 08:26 AM
That looks correct. As long as the COA packet is coming to the NS it should re-write the source IP from 172.18.68.53 to 172.18.75.82.
Nick
05-07-2015 07:41 AM
OK so we were able to get the CoA to work; however, I can only get a device to reauth once. After that, nothing happens. Here's some screen shots of how we have the NetScaler configured. As a side note, the only virtual server that we currently have persistence configured on is the CoA server, not sure if it needs to be applied elsewhere.
05-07-2015 07:50 AM
You shouldn't need a LB setup for the COA response since its a outbound response and the RNAT should translate it back to the server it came from for the return ACK. We just have a LB for 1813 and 1812 RADIUS. Those two should have persistence configured if you have multiple backend policy servers. Based on the COA ACL you posted earlier though it seemed like you only have one policy server. If you don't then that COA ACL needs to include all of them.
05-19-2015 07:58 AM
Sorry it's been so long. The CoA LB has been removed and it still isn't working. I was looking at the switch config, since we're initiating the CoA directly from the policy nodes, the 'aaa server radius dynamic-author' should list the true IPs of each of the policy nodes as clients and not the NetScaler VIP correct? I have tried it both ways and I'm still getting 'no response received' failure messages..
05-19-2015 12:40 PM
The purpose of the RNAT for CoA is to re-write the from address to be that of the VIP vs the policy server since your network device would be pointing to the VIP for requests. So, if you have the RNAT in place then the switch should be using the VIP.
If you do a packet capture do you see the COA packet coming in and out of the NS? You can do the capture right on the NS and see if the RNAT is taking place. If you see it then I would make sure the switch is getting it. If the switch is I would turn on some debugging to see why it isn't accepting it.
I recall having a issue with a wireless controller ignoring the COA packet and never responding because of a issue with persistence. Because of that the COA packet wouldn't have the proper session ID. Do you have the persistence group setup to make sure both accounting and authentication packets go to the same policy server?
05-21-2015 06:31 AM
It looks like I have the switch configuration sorted out. I had to point the 'aaa server radius dynamic-author' to the VIP and set the individual 'radius server <host>' to the real IP of the PSN. On the PSN I left the default GW as the NetScaler and I'm seeing successful auths and reauths consistently!!
Now I just need to test with our WLCs, fingers crossed :)
Thanks for all your help Nick!
09-12-2017 08:38 PM
it make confusion to make gateway for PSN points to Netscaler IP.
The design could possible to have L2 transfer and L3 routing.
it all depend on your design.
09-12-2017 08:39 PM
@Ken Daldine wrote:It looks like I have the switch configuration sorted out. I had to point the 'aaa server radius dynamic-author' to the VIP and set the individual 'radius server <host>' to the real IP of the PSN. On the PSN I left the default GW as the NetScaler and I'm seeing successful auths and reauths consistently!!
Now I just need to test with our WLCs, fingers crossed :)
Thanks for all your help Nick!
it make confusion to make gateway for PSN points to Netscaler IP.
The design could possible to have L2 transfer and L3 routing.
it all depend on your design.
12-25-2019 11:05 PM
02-29-2020 11:19 AM
Please share netscaler persistence configuration and mbf configuration
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: