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

[Paul B. Henson]

On Fri, Jul 12, 2024 at 02:51:00PM -1000, Baron Fujimoto wrote:
> Thanks, this prompted us to examine our (f5) load balancer's configuration.

We're currently using F5's as well, although the quote we recently
received to replace our aging units was crazy high so we're evaluating
alternatives.

> "...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]

Hmm. Not sure how that would work? Without any state, how would it know
which backend server to forward the random packets to? They'd presumably
be addressed to the F5 VIP.

> 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

We have our timeout set to 1 hour for ldap. We're also running RHEL
(Rocky) 9 for our idp's. However, I tweaked our dev ldap instance on the
F5 to 5 minutes and did a test with just telnet from an rhel 8 box:

rhel8-template ~ # date; telnet 134.71.177.248 389; date
Sun Jul 14 14:58:36 PDT 2024
Trying 134.71.177.248...
Connected to 134.71.177.248.
Escape character is '^]'.
Connection closed by foreign host.
Sun Jul 14 15:03:37 PDT 2024
rhel8-template ~ #

It connects, and 5 minutes later gets booted. As you can see from a
network capture:

14:58:36.447800 IP rhel8-template.unx.cpp.edu.57792 >
campus.ldap-dev.cpp.edu.ldap: Flags [S], seq 1662040191, win 29200,
options [mss 1460,sackOK,TS val 3270772787 ecr 0,nop,wscale 7], length 0
14:58:36.448382 IP campus.ldap-dev.cpp.edu.ldap >
rhel8-template.unx.cpp.edu.57792: Flags [S.], seq 721954530, ack
1662040192, win 28960, options [mss 1460,sackOK,TS val 3073647441 ecr
3270772787,nop,wscale 7], length 0
14:58:36.448400 IP rhel8-template.unx.cpp.edu.57792 >
campus.ldap-dev.cpp.edu.ldap: Flags [.], ack 1, win 229, options
15:03:37.764894 IP campus.ldap-dev.cpp.edu.ldap >
rhel8-template.unx.cpp.edu.57792: Flags [R.], seq 1, ack 1,
win 0, length 0

The F5 sends a reset after 5 minutes to drop the timed out connection.

Are you in a position to sniff the traffic on the idp and confirm a
reset is sent? What do the connections look like in netstat or ss before
and after the expected timeout?

Before they should be established:

tcp   ESTAB 0      0
[::ffff:134.71.246.236]:60604            [::ffff:134.71.178.7]:ldaps            

After they should be gone. Unlike a normal socket close which will
transition from established to a wait state, a reset should completely
and immediately release the state.



-- 
Paul B. Henson | Operating Systems and Network Analyst
henson at cpp.edu | California State Polytechnic University Pomona