(RADIATOR) TACACS disconnect during AuthByRADIUS proxy (bug?)

[Patrick, Robert]

Mike,

Thanks much for the fast response!

Yes, the problem was with the other RADIUS server (RSA ACE) at
192.168.73.100 - over time it had slowed down (likely a memory leak or
other resource problem) to the point where it was taking too long to
respond; the TACACS clients dropped the connection due to the delay
(timeout was set to 3 seconds).


-----Original Message-----
From: Mike McCauley [mailto:mikem at open.com.au] 
Sent: Monday, May 22, 2006 10:31 PM
To: Patrick, Robert
Cc: radius email list
Subject: Re: (RADIATOR) TACACS disconnect during AuthByRADIUS proxy
(bug?)

Hello Robert,

Thanks for the log excerpt.
Looking at the log, I suspect that the tacacs client is doing the
disconnection.
I see a 4 second delay between proxying the request 192.168.73.100 and
an answer being received back from it. But 3 seconds after receiving the
request, Radiator reports the tacacs client disconnected.
I suspect the client is disconnecting after 3 seconds and no reply.
Suggest you investigate the long delay time associated with Radius
server at 192.168.73.100 or else adjust the clinet tacacs timeout.

Cheers.


On Tuesday 23 May 2006 11:14, Patrick, Robert wrote:
> Hello!
>
> We are running the latest 3.14 with consolidated patches as of May 18.
>
> Setup is with Radiator acting as TACACS server, which proxies 
> authentication for users logging into Cisco devices, sending 
> authentication requests via RADIUS to an RSA SecurID RADIUS server so 
> we can use our 2-factor tokens for login access to Cisco routers and 
> switches.
>
> I'm getting a lot of intermittent failures, where the Cisco device 
> prompts a second time for password.  Generally quitting the login 
> session, and trying again will result in a successful "normal" login.
>
> After running with trace set to 4, it looks like a TACACS session 
> disconnect in the middle of the RADIUS back-and-forth (send 
> access-request, receive access-accept) during those times when the 
> login breaks, causing the Cisco device to prompt a second time for
password.
>
> The specific event is:
>
> <timestamp> DEBUG: TacacsplusConnection disconnected from 
> <ip_address:port>
>
>
> Any ideas on a fix for this behavior?
>
>
>
> Log extract below:
>
> Mon May 22 21:03:41 2006: DEBUG: Handling with Radius::AuthRADIUS Mon 
> May 22 21:03:41 2006: DEBUG: Packet dump:
> *** Sending to 192.168.73.100 port 1645 ....
> Code:       Access-Request
> Identifier: 2
> Authentic:  <cropped>
> Attributes:
>         NAS-IP-Address = 192.168.35.189
>         NAS-Port-Id = "tty450"
>         Calling-Station-Id = "192.168.61.99"
>         Service-Type = Login-User
>         User-Name = "username"
>         User-Password = <cropped>
>
> Mon May 22 21:03:41 2006: DEBUG: Radius::AuthFILE IGNORE: : username 
> [username] Mon May 22 21:03:41 2006: DEBUG: AuthBy FILE result: 
> IGNORE, Mon May 22 21:03:44 2006: DEBUG: TacacsplusConnection 
> disconnected from
> 192.168.35.189:64332
> Mon May 22 21:03:45 2006: DEBUG: Packet dump:
> *** Received from 192.168.73.100 port 1645 ....
> Code:       Access-Accept

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060524/a76625d3/attachment.html>