<div dir="ltr">Thanks, this prompted us to examine our (f5) load balancer's configuration.<div><br></div><div>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.</div><div><br></div><div>"...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]</div><div><br></div><div>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]</div><div><br></div><div>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)_/¯ </div><div><br></div><div>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.</div><div><br></div><div><div>[1] <<a href="https://my.f5.com/manage/s/article/K7595" target="_blank">https://my.f5.com/manage/s/article/K7595</a>></div></div><div>[2] <<a href="https://my.f5.com/manage/s/article/K99545311">https://my.f5.com/manage/s/article/K99545311</a>></div></div>