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