Determining whether TACACS+ access is being dropped by server or firewall?

alan1smith — Mon, 11 Mar 2019 00:37:37 GMT

I have a router with the following aaa and tacacs+ config:

aaa new-model
!
!
aaa authentication attempts login 5
aaa authentication fail-message ^CCFailed login. Five consecutive fails will revoke.^C
aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa authorization exec default group tacacs+ if-authenticated
aaa accounting suppress null-username
aaa accounting exec default start-stop group tacacs+

ip tacacs source-interface Loopback0

tacacs-server host 167.64.248.52 single-connection
tacacs-server host 167.64.148.12 single-connection
tacacs-server timeout 6
tacacs-server directed-request
tacacs-server key 7 XXXXXXXXXXXXXXXXXXXXXXXXXX

The loopback address is 167.64.82.53/32, and the following routes and ACLs are in place to ensure that connectivity for ssh and tacacs are in place:

ip route 167.64.148.12 255.255.255.255 212.123.3.156 name Tacacs+ <---- Firewall is the gateway
ip route 167.64.248.52 255.255.255.255 212.123.3.156 name Tacacs+ <---- Firewall is the gateway

access-list 101 remark /**********************************************
access-list 101 remark Allows SSH access for management
access-list 101 remark **********************************************/
access-list 101 permit tcp host 212.123.3.146 any eq telnet
access-list 101 permit tcp host 212.123.3.158 any eq telnet
access-list 101 permit tcp host 212.123.3.146 any eq 22
access-list 101 permit tcp host 212.123.3.156 any eq 22
access-list 101 permit tcp host 212.123.3.158 any eq 22
access-list 101 permit tcp 172.30.127.0 0.0.0.31 any eq 22
access-list 101 permit tcp host 10.1.9.13 any eq 22
access-list 101 permit tcp host 10.6.35.35 any eq 22
access-list 101 permit tcp host 10.11.15.35 any eq 22
access-list 101 deny ip any any log

The following is configured on the ACS server:

AAA Client IP Address

Shared Secret

Network Device Group

Authenticate Using

RADIUS Key Wrap

Key Encryption Key

Message Authenticator Code Key

Key Input Format

ASCII

Hexadecimal

Log Update/Watchdog Packets from this AAA Client

RADIUS Options

Replace RADIUS Port info with Username from this AAA Client

Log RADIUS Tunneling Packets from this AAA Client

Match Framed-IP-Address with user IP address for accounting packets from this AAA Client

TACACS+ Options

Generate account stop packet for unexpected Single-Connect termination

Single Connect Flag support

	Legacy TACACS+ Single Connect support for this AAA client
	TACACS+ Draft compliant Single Connect support for this AAA client

The following error is received when users try to connect using TACACS credentials:

Nov 30 17:19:46 EST: TPLUS: Queuing AAA Authentication request 12 for processing
Nov 30 17:19:46 EST: TPLUS: processing authentication start request id 12
Nov 30 17:19:46 EST: TPLUS: Authentication start packet created for 12(alansmit)
Nov 30 17:19:46 EST: TPLUS: Using server 167.64.248.52
Nov 30 17:19:46 EST: TPLUS(0000000C)/0/IDLE/65AB8424: got immediate connect on new 0
Nov 30 17:19:46 EST: TPLUS(0000000C)/0/WRITE/65AB8424: Started 6 sec timeout
Nov 30 17:19:46 EST: TPLUS(0000000C)/0/WRITE: write to 167.64.248.52 failed with errno 257((ENOTCONN))
Nov 30 17:19:46 EST: TPLUS: Authentication start packet created for 12(alansmit)
Nov 30 17:19:52 EST: TPLUS(0000000C)/0/WRITE/65AB8424: timed out
Nov 30 17:19:52 EST: TPLUS(0000000C)/0/WRITE/65AB8424: timed out, clean up
Nov 30 17:19:52 EST: TPLUS(0000000C)/0/65AB8424: Processing the reply packet

The ACS server does not register a failed attempt. Is it likely that this traffic is possibly being blocked by the firewall at IP address 212.123.3.156?

Re: Determining whether TACACS+ access is being dropped by serve

Tarik Admani — Thu, 02 Dec 2010 04:34:37 GMT

This is a little tricky to tell without actually knowing or setting up a capture at the firewall that you mentioned. First thing I would do is to see if the tacacs services on the ACS is started...if you are running acs for windows you will just got to the server that ACS is installed on and see if the CSTacacs services are started. If you are on the solution engine you can verify the services are started when you click on "Service Control" under the System Configuration menu on the left. If the tacacs services are started then you can try to issue a telnet 49 from the firewall and if the connection is open but closed when you issue the same command from the device that you are trying to authenticate then it is a possibility that the firewall is blocking the traffic from passing through.

Hope that helps,

Tarik Admani

Re: Determining whether TACACS+ access is being dropped by serve

cadet alain — Thu, 02 Dec 2010 10:45:43 GMT

Hi,

Could you try ticking this: Legacy TACACS+ Single Connect support for this AAA client on your ACS.

Regards.

Re: Determining whether TACACS+ access is being dropped by serve

Richard Burts — Sat, 04 Dec 2010 23:13:12 GMT

Alan

I am interested in this error message from your original post:

write to 167.64.248.52 failed with errno 257((ENOTCONN))

can you verify that there is IP connectivity between your router loopback interface and the TACACS server (extended ping from the router specifying the source address as loopback 0 and destination as 167.64.248.52

I am also curious. You posted access list 101 but do not tell us how that access list is used. Can you clarify that for us?

HTH

Rick

topic Re: Determining whether TACACS+ access is being dropped by serve in Network Access Control

Determining whether TACACS+ access is being dropped by server or firewall?

Re: Determining whether TACACS+ access is being dropped by serve

Re: Determining whether TACACS+ access is being dropped by serve

Re: Determining whether TACACS+ access is being dropped by serve