lifetime and idle_timeout in clients.conf

[Jason Rohm]

Alan,

Thanks for the response. Additional comments below.



On 4/13/12 10:04 AM, "Alan DeKok" <aland at deployingradius.com> wrote:

>Jason Rohm wrote:
>> I've been having some issues with proxy authentications failing in a
>> federated TCP/TLS configuration. Investigation shows that the
>>connections
>> are failing with an error on the server end of "Info: Ignoring new
>> connection due to client max_connections". A little more digging seems
>>to
>> show that the connections are not being gracefully closed. I suspect
>>this
>> is due to a firewall cleaning up idle TCP translation slots since there
>> are currently few authentication attempts.
>
>  Don't do that.  That kind of a configuration on a firewall is bad.

In many cases I don't control the firewall, so I have to account for this.
Additionally, not putting a reasonable lifetime limit on TCP connections
opens you up to NAT-based DoS attacks.

>
>> I've seen the lifetime keyword in a number of sample configurations here
>> and the configuration parser seems to take it when I run the service in
>> debug mode.
>
>  Uh... you can't just add random keywords and expect it to work.

Didn't really expect it to. I just saw some third-party samples floating
around so I suspected an undocumented feature or something. Thanks for
confirming the lack there of.

>
>  *All* of the keywords that work are in the default configuration
>files, and are well documented.  If a keyword doesn't exist in the
>default config, it's because it doesn't work.
>
>> However, the idle_timeout keyword is silently ignored and the
>> server doesn't seem to be cleaning up old connections based on either
>>the
>> idle_timeout or the max lifetime. I can't find references to either
>> lifetime or idle_timeout in the sample configurations or a quick review
>>of
>> the documentation as it relates to clients.conf.
>
>  Because it doesn't exist.
>
>> So my questions areŠ
>> 
>> 1.) Are the keywords lifetime and idle_timeout supported in
>>clients.conf?
>
>  No.
>
>> 2.) If they are, is there a known bug that would cause them to not work?
>> 3.) If they aren't, would there be value to someone other than me to add
>> this feature? (Yes, I know this means I volunteer, lol).)
>
>  Sure, send a patch.
>
>  However, fixing that will require some in-depth knowledge of the core
>server APIs.

I'll see what I can do. Already have my fingers into the code for the TLS
stuff.
>
>> 4.) In addition to lifetime and idle_timeout, would something like a
>>keep
>> alive be reasonable?
>
>  That's up to the client.
>
>  When FreeRADIUS acts as client (i.e. proxy to home server), it will
>send watchdog packets.

Is this default, or do I need to configure it? If it is default, it
doesn't seem to be working in my configuration.

>
>  Alan DeKok.
>-
>List info/subscribe/unsubscribe? See
>http://www.freeradius.org/list/users.html