cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3281
Views
10
Helpful
8
Replies

ACS 5.3 load balancing - TACACS+ NAS IP address

Josef Fuehrer
Level 1
Level 1

Dear all,

I'm currently evaluating a scenario where AAA request are load balanced across multiple ACS 5.3 instances. The application delivery controller runs in L3 mode, which naturally causes the original packet's source IP address to be replaced by a randomly selected proxy address.

As far as RADIUS is concerned, I can perfectly determine the originating NAS by means of a 'Device Filter' condition. Unfortunately, ACS seems to lack the possibility of achieving the same for TACACS+. According to the user manual, only the actual IP address from the received packet is taken into account. I've also come across the 'NAS-Address' attribute in the protocol dictionary, but it can't be used in a custom condition either.

Does anyone happen to know how to retrieve the initial device IP address from a TACACS+ request in order to use it for further policing?

Cheers,

Josef

2 Accepted Solutions

Accepted Solutions

maldehne
Cisco Employee
Cisco Employee

Hello Josef , thats not possible.

View solution in original post

Josef,

That is not an attribute that is present in  the authentication request due to the fact it is in the tacacs  dictionary section. Typically the dictionary values are for attributes  you want to send back in the authorization response, however there isnt  anything online as to what this address is for. At this point there isnt  much you can do from your design but you should open a TAC case so they  can get on a webex with you to see if there something I may have  missed.

Thanks

Tarik Admani

View solution in original post

8 Replies 8

maldehne
Cisco Employee
Cisco Employee

Hello Josef , thats not possible.

Hi,

Thanks for your reply.

So am I right to assume that currently there's no way to load balance TACACS+ requests while maintaining the full ACS feature set? If so, are there any plans to add corresponding functionality to future ACS or ISE releases?

Cheers,

Josef

Josef,

Are the shared secrets the same for all the devices? Are you only authorizing users based on user group (no network device group or network device location used in the authorization policies), if so you can use the default network device option and set a shared secret to decrypt these requests.

If there is a pool of network addresses that this loadbalancer uses, you can create an network device entry and choose the range so it also this this "network device".

let me know if that is something that will fit what you are looking for.

Thanks,

Tarik Admani

Dear Tarik,

my current setup is pretty much as per your description. I've created network device entries for the pool of proxy addresses and assigned a single shared secret for common use among all AAA clients.

However, in certain cases I've to apply further access restrictions to certain devices. In order to identify them, it's necessary to filter out the original NAS IP address from the Tacacs+ request.

For Radius requests this functionality is implemented in the 'Device Filter' policy element. But so far I haven't been able to work out a solution for Tacacs+.

Cheers,

Josef

Josef,

Can you explain why the loadbalancer is randomly re-writing the source ip addresses of the tacacs requests? Can you assign a group of devices to a specific address? There isnt any attribute that has the same source address so what you are trying to achieve isnt possible.

Here is a screenshot of a decrypted tacacs request:

thanks,

Tarik Admani

Dear Tarik,

The source IP addresses are replaced because the load balancer operates in layer 3 mode. Due to the physical placement, switching to layer 2 mode isn't a valid option at the moment. Additionally, the current software release doesn't support static proxy address assignment.

Apparently, a Tacacs+ NAS address attribute does exist. At least it's listed in the protocol dictionary:

Is there a way to make use of it as a policy condition?

Cheers,

Josef

Josef,

That is not an attribute that is present in  the authentication request due to the fact it is in the tacacs  dictionary section. Typically the dictionary values are for attributes  you want to send back in the authorization response, however there isnt  anything online as to what this address is for. At this point there isnt  much you can do from your design but you should open a TAC case so they  can get on a webex with you to see if there something I may have  missed.

Thanks

Tarik Admani

Dear Tarik,

so it seems like a chance in my design is really worth consideration.

Thanks a lot for your help.

Cheers,

Josef