Ex: Re: Working around issue of load balancer idle timeout to LDAP data connector

[Baron Fujimoto]

Thanks, this prompted us to examine our (f5) load balancer's configuration.

This should be controlled by a configuration parameter called
reset-on-timeout on our f5. We discovered that it was disabled. In the
process, we discovered that the f5 apparently has a feature called
"loose-initiation" that looks like it should have addressed this situation.

"...with Reset on Timeout disabled, the BIG-IP LTM system quietly removes
the connection entry and neither the client nor the server is aware that
the communication channel has timed out. When the client or server begins
communicating again, the Loose Initiation setting allows the BIG-IP LTM
system to re-add the connection to the connection table, and the newly
arrived packets are forwarded, as expected." [1]

We subsequently learned though that we could not enable loose-initiation
because it is incompatible with another setting that provides protection
against SYN cookie attacks. [2]

Since loose-initiation wasn't viable for us we enabled reset-on-timeout.
Unfortunately, this also does not seem to have the desired effect. Assuming
the f5 is actually sending the TCP RST, the host OS (Redhat 8) TCP stacks
don't seem to be detecting or responding to it. Netstat still shows the
connections as open, which is consistent with the LDAP server and the IdP
behavior as well. ¯\_(o_0)_/¯

We'll try to see if we can get f5 to support to be helpful, but for now
we're still using the kludge to set the IdP's LDAP validate timer period <
f5 idle timeout.

[1] <https://my.f5.com/manage/s/article/K7595>
[2] <https://my.f5.com/manage/s/article/K99545311>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240712/660899d7/attachment.htm>