equivalent command for "ip tacacs source-interface" on ASA

[Hemant Sajwan]

Is there an equivalent command for "ip tacacs source-interface" on ASA? We have a L2L VPN between 2 ASAs and AAA server is across the VPN tunnel and I want the ASA to go to ACS with source interface as inside, not outside.  aaa-server command is pointing towards outside interface and management-access inside is configured but still packets are routed using outside interface as source. Any workaround apart from NAT?

[Jennifer Halim · Accepted solution]

Yes, you can configure the interface within the aaa-server command when you define the ip address of the server.

Eg:

aaa-server mytacacs (inside) host 10.1.1.1

here is the command for your reference:

http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/a1.html#wp1596947

Hope that helps.

[Hemant Sajwan]

Jennifer, thank you. Are you sure that will work? I don't think so because the interface name specifies where the ACS resides, not where the requests should be sourced from. In my case, the ACS is on outside (across the VPN tunnel), so I have to specify the outside interface in aaa-server command but I still want the source of the packets to be inside interface. In the following link, the user resolved the issue using "man i" command but it did not work for me:

http://nat0.net/asa-generated-traffic-part2/

[Jennifer Halim · Accepted solution]

Yes, that will specify the aaa-server to source it from the inside interface, however, it will still route it accordingly as per your routing table.

[Hemant Sajwan]

Hey Jennifer, thanks a lot for the help. What you suggested worked !!  I mentioned inside interface in the aaa-server command (aaa-server  (inside)....) and even though the aaa-server was on outside interface,  it still sent the packets out with source as inside interface.

One last question - was this behaviour always like this from the very beginning or was it changed from some specific version? Because as far as I remember, the interface parameter was used to specify the interface on which the AAA server resided, not the interface where you wanted the packets to be sourced from (and that's why the person in the link I posted above was facing similar issue).

And hey, by the way, I had opened a case with TAC as well before it and they too did not know about it :-D

[Jennifer Halim]

Yes, the behaviour is always like this. If you don't specify the interface within the aaa-server command, it will just use the interface that it routes the packet on as the source interface. If you specify the interface, it will source the packet using that interface.

Also, thanks for the ratings and update.

[Hemant Sajwan]

Jennifer, the command reference does not tell this clearly and I am sure there are a lot of people like me who did not know what you said. As per command reference:

(interface-name)

(Optional) Specifies the network interface where the authentication  server resides. The parentheses are required in this parameter. If you  do not specify an interface, the default is inside, if available.

http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/a1.html#wp1596656

So, as per above, if interface name is not specified, the default is taken as inside, not the one that was used to source the packets.

[Jennifer Halim]

I agree, the documentation is not very clear at all. If you still have the TAC case opened, please advise the engineer to file a documentation bug to get that stated more clearly.

[Hemant Sajwan]

I have asked TAC engineer to file a documentation bug.

[Mark Lancaster]

Hi Jennifer,

Is it possible that Cisco changed the behavior of this command in ASA 9.x?  I am running 9.1(3), and I observe the ASA attempting to locate the next routed hop via the inside interface for the configured AAA server, rather than using the routing table.  I end up with the following errors:

- Routing failed to locate next hop for TCP from identity:x.x.x.x/52711 to INSIDE:x.x.x.x/49

- AAA authentication server not accessible 

This behavior does match the documentation, unfortunately.

( interface-name )

(Optional) Specifies the network interface where the authentication server resides. The parentheses are required in this parameter. If you do not specify an interface, the default is inside, if available.

Apologies for the necropost, but this seems to be the most relevant thread.

[oamarneh]

Hello Hemant,

i think the interface name in the aaa-server command just specifies where the AAA server resides, and it will communicate with it using the IP of that interface.

i think the workaround in your case is to make it as aaa-server (outside) and include your outside interface IP in the crypto ACL interesting traffic.

Regards,

Othman

[Hemant Sajwan]

Hi Othman,

What you said is what I had done earlier but I was specifically looking to source the traffic from inside interface. Surprisingly, what Jennifer suggested above worked !! I mentioned inside interface in the aaa-server command (aaa-server (inside)....) and even though the aaa-server was on outside interface, it still sent the packets out with source as inside interface.

[#13]

Hi Hermant,

I know this is an old topic, are you still using this functionality? Do you know if it still works in more recent versions? I am trying something very similar on 9.6(1) in multi-context mode and it appears it now wants to try and communicate with the RADIUS server via the interface specified in the aaa-server command and not via the interface specified in the routing table (using the aaa-server interface as the source IP/NAS-IP).

Output of "debug aaa"

Marking server 10.1.1.1 in server tag RADIUS-Server Up
AAA_BindServer: No server found
ERROR: No error
Marking server 10.1.1.1 down in servertag RADIUS-Server

# ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

The server works correctly if I specify the interface holding the route (inside).

[Ben Rodriguez]

I can confirm it doesn't route via the routing table. The default behavior is not scalable. I would like to not have to pin it to an interface so I can still use TACACS+ when the primary interface or ISP is down. The command will not take if your TACACS+ server IP if the same for both interface commands. You would need two TACACS+ external IP's to be able to use two interfaces. We are sending the auth requests to the outside for ASA and other external devices.