lifetime and idle_timeout in clients.conf
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. 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. 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. So my questions are 1.) Are the keywords lifetime and idle_timeout supported in clients.conf? 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).) 4.) In addition to lifetime and idle_timeout, would something like a keep alive be reasonable? Thanks. Any and all feedback is welcome. Jason Rohm Communication Architect jason.rohm@srctechnologies.com
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.
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. *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.
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. Alan DeKok.
Alan, Thanks for the response. Additional comments below. On 4/13/12 10:04 AM, "Alan DeKok" <aland@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
Jason Rohm wrote:
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.
Yes.
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.
It *should* work. It's a bit of a mystery why it doesn't. It should be fixed before 3.0 is released. Alan DeKok.
On 13/04/12 16:04, Alan DeKok wrote:
Don't do that. That kind of a configuration on a firewall is bad.
To be fair, my experience has been that most firewalls will timeout inactive connections. Some won't even let you turn it off. TCP keepalive might be an option here?
Phil Mayers wrote:
TCP keepalive might be an option here?
Maybe. I've had bad experiences with that. It sometimes doesn't make a difference. In any case, I've pushed support for "idle_timeout" and "lifetime" to git "master". The incoming "listen" sections and "client" sections now support that for TCP sockets. The default is idle_timeout of 30. If it doesn't receive packets for 30s, there's no reason to keep the TCP connection open. Alan DeKok.
participants (3)
-
Alan DeKok -
Jason Rohm -
Phil Mayers