my AAA commands;
aaa authentication login default group tacacs enable
aaa authorization exec default group tacacs none
aaa accounting connection default start-stop group tacacs
aaa session-id common
tacacs-server host [server address]
tacacs-server key [key]
ip tacacs source-interface fast 0
and the debug for authentication and tacacs;
00:08:50: AAA/AUTHEN/LOGIN (00000007): Pick method list 'default'
00:08:50: TPLUS: Queuing AAA Authentication request 7 for processing
00:08:50: TPLUS: processing authentication start request id 7
00:08:50: TPLUS: Authentication start packet created for 7()
00:08:50: TPLUS: Using server 188.8.131.52
00:08:55: TPLUS(00000007): Select Timed out
00:08:55: AAA/AUTHEN/ENABLE(00000007): Processing request action LOGIN
00:08:55: AAA/AUTHEN/ENABLE(00000007): Done status GET_PASSWORD
00:08:59: AAA/AUTHEN/ENABLE(00000007): Processing request action LOGIN
00:08:59: AAA/AUTHEN/ENABLE(00000007): Done status PASS
I can ping the tacacs server from the router. This set of commands does work for the 1841's that I'm using.
There are no hits in failed attempts, I can see my passed logins from the other routers. I currently have the source interface set to loopback 0, and have also tried setting the source to fast0 with the same result. The weird part is that these commands work flawlessly on all my 1841's. This is ACS 4.1 on server 03 if that helps.
ACS -->network configuration ---> Router --->IP
The IP address defined in acs should be of the interface defined as "tacacs source" in router.
Did you check the shared secret key?
debug aaa authentication
debug aaa authorization
01:33:46: AAA/AUTHEN/LOGIN (00000008): Pick method list 'default'
The IP of the source interface is the same one specified in ACS, and I also verified the shared secret is correct.
Processing request action LOGIN
01:33:51: AAA/AUTHEN/ENABLE(00000008): Done status GET_PASSWORD
01:33:54: AAA/AUTHEN/ENABLE(00000008): Processing request action LOGIN
01:33:54: AAA/AUTHEN/ENABLE(00000008): Done status PASS
Are you able to clear the first user name password prompt?
or it is not accepting enable password? what error you get after issuing enable password?
the first prompt is using the enable password as failover for ACS, so I can get past the login, and the prompt for the EN password, its just not hitting the ACS box with the request. Here is login/EN without the debug.
Press RETURN to get started.
There are no firewalls other than at the pc level from my desk to the ACS box. I'm starting to think there's something unique with the 1720.
I have had quite a few 1720s that authenticate with ACS without problem. I do not think your issue is something unique about the 1720.
Can you do debug tacacs authentication, try another login, and post the debug output?
This is me trying to login via telnet, with debug on for Tacacs, and authentication/authorization. I'm not sure why its timing out, I can ping the ACS server, however ping fails when I specify the source, Loopback 0, which is my tacacs source.
02:10:57: AAA/AUTHEN/LOGIN (0000000A): Pick method list 'default'
02:10:57: TPLUS: Queuing AAA Authentication request 10 for processing
02:10:57: TPLUS: processing authentication start request id 10
02:10:57: TPLUS: Authentication start packet created for 10()
02:10:57: TPLUS: Using server 184.108.40.206
02:11:02: TPLUS(0000000A): Select Timed out
02:11:02: AAA/AUTHEN/ENABLE(0000000A): Processing request action LOGIN
02:11:02: AAA/AUTHEN/ENABLE(0000000A): Done status GET_PASSWORD
02:11:04: AAA/AUTHEN/ENABLE(0000000A): Processing request action LOGIN
02:11:04: AAA/AUTHEN/ENABLE(0000000A): Done status PASS
02:11:04: AAA/AUTHOR (0xA): Pick method list 'default'
02:11:04: TPLUS: Queuing AAA Authorization request 10 for processing
02:11:04: TPLUS: processing authorization request id 10
02:11:04: TPLUS: Sending AV service=shell
02:11:04: TPLUS: Sending AV cmd*
02:11:04: TPLUS: Authorization request created for 10()
02:11:04: TPLUS: Using server 220.127.116.11
02:11:09: TPLUS(0000000A): Select Timed out
02:11:09: AAA/AUTHOR/EXEC(0000000A): Authorization FAILED
It is helpful to know that a standard ping to the TACACS server does work but that an extended ping which specifies the source as the loopback fails. This suggest that there is a routing problem and that the TACACS server does not have a route to the subnet of the loopback.
Would you be able to start from the TACACS server and do a traceroute toward the loopback address. It might be interesting to see how far that gets and it might help to identify where the problem is.
The problem I'll have with a trace route is that the IP I'm using for Loopback 0 is a real IP outside my network. When I run TR its just going to hop to the real world IP. I can use TR from the ACS server to the outside NAT IP on the router, but thats only one hop.
Tracing route to 18.104.22.168 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 22.214.171.124
Would it be possible for you to post the relevant part of one of your configs so that I can compare it with mine?
Can you tell us about the network translation, is it static translation or dynamic, or is it using overload to PAT on the outbound interface? I wonder if the issue with TACACS has anything to do with the translation?
Relevant information from one of the 1721s that do successfully authenticate with TACACS:
IOS (tm) C1700 Software (C1700-ADVSECURITYK9-M), Version 12.3(22), RELEASE SOFTWARE (fc2)
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable
aaa authorization exec default group tacacs+ if-authenticated
ip address 10.42.186.2 255.255.255.255
ip tacacs source-interface Loopback0
tacacs-server host 172.16.24.20
tacacs-server host 172.16.130.103
tacacs-server key [removed]
and an extended ping from the router to the TACACS server using the loopback as source does get successful responses.
We use static translation. As for PAT I dont believe we are using it, I made any port settings in the router or in the ACS server. I do have this command in the router;
ip nat inside source route-map nonat interface FastEthernet0 overload
Could you post the route map nonat and any access list that it references. And if the address of the loopback is in any of those could you point it out?
I changed the tacacs source to fastethernet0 just for testing, here is the ACL and the route-map nonat
access-list 120 permit ip 126.96.36.199 0.0.0.255 188.8.131.52 0.0.0.255
access-list 120 permit ip 184.108.40.206 0.0.0.255 220.127.116.11 0.0.0.255
access-list 120 permit ip 18.104.22.168 0.0.0.255 22.214.171.124 0.0.0.255
access-list 120 permit ip 126.96.36.199 0.0.0.255 188.8.131.52 0.0.0.255
access-list 120 permit ip 184.108.40.206 0.0.0.255 220.127.116.11 0.0.0.255
access-list 130 deny ip 18.104.22.168 0.0.0.255 22.214.171.124 0.0.0.255
access-list 130 deny ip 126.96.36.199 0.0.0.255 188.8.131.52 0.0.0.255
access-list 130 deny ip 184.108.40.206 0.0.0.255 220.127.116.11 0.0.0.255
access-list 130 deny ip 18.104.22.168 0.0.0.255 22.214.171.124 0.0.0.255
access-list 130 deny ip 126.96.36.199 0.0.0.255 188.8.131.52 0.0.0.255
access-list 130 permit ip 184.108.40.206 0.0.0.255 any
no cdp run
route-map nonat permit 10
match ip address 130
We need at least one more set of information to sort out the potential NAT issue. Can you post the output of show ip interface brief?
This post indicates that you changed the tacacs source to fastethernet0. Did you change the tacacs configuration to use that IP address? And does tacacs work with this address configured?
Here is the output you wanted;
Nacogdoches#sh ip int brief
Interface IP-Address OK? Method Status Protocol
Ethernet0 220.127.116.11 YES NVRAM up up
Ethernet1 unassigned YES NVRAM up down
FastEthernet0 18.104.22.168 YES NVRAM up up
Loopback0 unassigned YES NVRAM up up
I changed the source interface to fast0 to see if it made a difference, it does not seem to change anything. I can still run;
ping 22.214.171.124 and get 5/5
Several of your posts have described using loopback0 as the source. But the output in this post shows that loopback0 has no IP address. What is going on?
And what does ping 126.96.36.199 have to do with access to your TACACS server?
Thats correct, I'm sorry for the confusion; I started out using Loopback0 as the tacacs source. I changed it to Fastethernet0 to test with. I'll be changing the source back to Loopback0 before I deploy the router.
188.8.131.52 is my tacacs server, again I didnt provide the needed detail, sorry about that.
If your tacacs server is 184.108.40.206 then why does the debug output from several of your posts consistently indicate that the server is at a different address:
02:11:04: TPLUS: Using server 220.127.116.11
18.104.22.168 is my host router, the IP of the acs box is the 22.214.171.124 address. 126.96.36.199 is a network address, not a real world IP. The real world IP of the ACS server is 188.8.131.52
I have changed the source interface back to Loopback0, and migrated the address information over as well.