09-18-2014 06:11 AM - edited 03-07-2019 08:48 PM
I am adding new routers to our Corporate network for a new MPLS network. I am getting 13017 Received TACACS+ packet from unknown Network Device or AAA Client errors for these new routers. They are added to ACS 5.4.0.30 correctly just like all of our other devices. We have never had real routers on the network before, just switches and access points. Is there something special I need to set in ACS for these to work and authenticate correctly? I can only access the currently with built in login locally.
One of the new router configs
Current configuration : 2370 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname T666
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$h7b3$.T2idTKb9H98BQ8Op0MAC/
!
aaa new-model
!
!
aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa authorization exec default group tacacs+ local if-authenticated
aaa accounting exec default start-stop group tacacs+
!
aaa session-id common
clock timezone CST -6
clock summer-time CDT recurring
ip cef
!
!
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
voice-card 0
!
!
!
!
!
!
!
!
!
!
!
!
!
crypto pki trustpoint TP-self-signed-2699490457
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-2699490457
revocation-check none
rsakeypair TP-self-signed-2699490457
!
!
username netadmin privilege 15 secret 5 $1$SIR2$A3MpShVNeAOlTPyLZESr..
!
!
!
!
!
!
!
interface FastEthernet0/0
ip address 10.114.2.1 255.255.255.0
ip helper-address 10.30.101.4
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1/0
ip address X.X.X.X 255.255.255.252
no fair-queue
service-module t1 timeslots 1-24
service-module t1 remote-alarm-enable
service-module t1 fdl ansi
no cdp enable
!
router bgp 65065
no synchronization
bgp log-neighbor-changes
network 10.114.2.0 mask 255.255.255.0
neighbor X.X.X.X remote-as 209
neighbor X.X.X.X default-originate
default-information originate
no auto-summary
!
ip forward-protocol nd
!
ip bgp-community new-format
!
ip http server
ip http authentication aaa
ip http secure-server
ip tacacs source-interface FastEthernet0/0
!
no logging trap
!
!
tacacs-server host 10.30.101.221 key 7 1429005B5C502225
tacacs-server host 10.30.101.222 key 7 1429005B5C502225
tacacs-server directed-request
!
control-plane
!
!
!
!
!
!
!
!
banner exec ^CC
C
Login OK
**
^C
banner motd ^CC
C
**
** UNAUTHORIZED ACCESS TO THIS SYSTEM IS PROHIBITED. USE OF
** THIS SYSTEM CONSTITUES CONSENT TO MONITORING AT ALL TIMES.
**
** RUAN Transport Corporation
** Network Services
** netadmin@ruan.com
** 515.245.2512
**
^C
!
line con 0
line aux 0
line vty 0 4
exec-timeout 30 0
transport input all
line vty 5 15
exec-timeout 30 0
!
scheduler allocate 20000 1000
end
T666#
09-18-2014 06:43 AM
In looking through the config that you post I do not see any dynamic routing protocol and not any static routes. So I wonder how the router will get traffic to the ACS server.
But if the server is generating that error then there must be something that you have not shared with us that gets it to work. I wonder if whatever that is might have some impact on this situation.
The configuration of the router for TACACS seems appropriate (assuming that the addressing and the shared key are correct). I do not see anything that you would need to add to the router config to get it to work. I would suggest that it is more likely that there is some issue on the ACS server with how the client is configured.
HTH
Rick
09-18-2014 06:46 AM
It is using BGP as the routing protocol to get back.. and all of that works fine.. I am able to pull DHCP from Corporate and print fine. They only thing that does not work is TACACS+... its baffelling me...
09-19-2014 08:16 AM
Thanks for the additional information. So if the requests from the router are getting to the TACACS server then it seems unlikely that there is a problem on the router. Your router configuration indicates that the TACACS request will be sourced from 10.114.2.1. Can you confirm that your TACACS server sees that address as an appropriate client address?
HTH
Rick
09-19-2014 08:22 AM
AAA Protocol > TACACS+ Authentication Details | ||
| ||
Generated on September 19, 2014 10:21:27 AM CDT | ||
|
|
09-19-2014 12:10 PM
Thanks for the additional details. They are quite clear about the error. So can you show us the part of ACS where this client is configured to be an acceptable client?
HTH
Rick
09-19-2014 12:17 PM
09-19-2014 07:32 PM
Thank you for the additional information. It sure does look like the router should be a valid client to the server. This is getting on the outside edges of my expertise but I wonder if marking the client as single connect has anything to do with the issue?
HTH
Rick
09-22-2014 11:08 AM
Yes I have tried each of those settings with no avail either...
12-19-2014 01:47 AM
Hi Joel
i face this issue too , here is my solution, if you are running ACS 5.X, i thought it is suite for you
log into ACS console with ssh
stop acs applicatoin with the following command line
"acs stop"
after that , restart it
"application start acs"
before you restart acs , it is necessnary to check your network resource configuration is correct.
restart action just make it go into effect
05-25-2016 11:09 AM
Thanks for the support, But I tried this and unfortunately it doesn't work
any other solutions ?
Thanks
05-26-2016 11:13 AM
In addition to stopping and restarting the application have you verified that the ACS has correctly configured the client and verified that the shared key is correct?
HTH
Rick
12-29-2016 08:33 AM
I recently had the same issue when I added a new device to our network. I validated the ACS configuration and the device configuration all looked good, but I kept getting the error message "13017 Received TACACS+ packet from unknown Network Device or AAA Client".
I added the new device to ACS by duplicating another device and then specifying the IP address of the new device. Also, I configured AAA on the new device by reusing our standard AAA configuration from another working device.
Reusing the configuration from another working device is what caused the problem. The working device was running older code (03.03.05) than the new device (03.07.02E). At some point between the old and new code versions, the old method of defining TACACS servers caused this issue. So, try completely removing the old style of defining TACACS servers from your configuration and use the new style. My configuration didn't work until all remnants of the old style of configuration were gone. Also, it's worth noting you may have to change your AAA commands to include the server group name if it doesn't already include a server group name.
Old style example:
tacacs-server host x.x.x.x key 7 1234567890
New style example:
tacacs server TEST
address ipv4 x.x.x.x
key 1234567890
aaa group server tacacs+ servergroup
server name TEST
aaa authentication login default group servergroup local
HTH
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide