Thanks for the feedback. Ive removed the command and the issue still appears to be that the router doesnt recognise TACACs although it accepts the commands. When the config is applied it bypasses TACACs for authentication and goes to the enable pwd? The servers reachable via ICMP but showing failed connect attempts along with the AAA-3-BADSERVERTYPEERROR in the log. Ive rolled out the same config across multiple platforms in the network. Its just this box thats sulking.
Tacacs+ Server : 10.2.2.66/49
Socket opens: 33
Socket closes: 33
Socket aborts: 0
Socket errors: 0
Socket Timeouts: 0
Failed Connect Attempts: 29
Total Packets Sent: 0
Total Packets Recv: 0
aaa authentication login default group tacacs+ enable
aaa authentication enable default group tacacs+ enable
aaa authorization config-commands
aaa authorization commands 0 default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa accounting commands 0 default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
Does your authentication profile on the aaa server match the orgination of the request from the router ? What does your failed attempts log look like on the server ? Is there an ip address from that router ? I would think so since the socket open was sucessful.
Usually you'd specify the originating interface on the router with a global statement (ip tacacs source-interface Loopback0 for an example) which has to match up with an authentication profile for TACACS+ on the server. Its down near the bottom of a typical configuration, right above the banner section
Guys, Thanks for the continued input. Debugs attached and I also added the tacacs source interface command. From the debugs it appears that the TACACs server is not responding. The server logs didnt come up with anything although its still reachable via ICMP. Think the problem is possibly with the fact that the router is on a public range and the server is on a private range - NAT/PAT may be hindering the authentication? Worked a treat for everything on the private network. Any other ideas? There is nothing explicitly set up on the TAC_plus server to allow specific ranges.
Do check proxy distribution table in ACS, see if it is set up to forward request to any other server. (if you do not see proxy disctribution table in network config. , enable Distributed system settings from Interface Config.)
If it is setup to forward to some other server, config it to forward to its own name.
Taking sniffer might help to check if the request is reaching ACS or dropping somewhere along the path.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...