On Tue, Nov 14, 2023 at 07:44:32PM -0000, [email protected] wrote:

Hello,

Was wondering if anyone has tried to setup an HA like setup, specifically active/passive through two Stunnel servers and F5 load balancers.

The problem I have is that TCP health checks (active checks) from the F5 are causing session initiation all the way to the 3rd party on the other side and this is causing a lot of unnecessary TCP traffic at the transport layer. The good thing is that the F5 closes these TCP sessions, but the problem is the 3rd party thinks someone is trying to brute force or something.

Does anyone know how to maintain the TCP active health checks that the F5 does, but at the same time not cause a session initiation all the way to the 3rd party? Or if it’s not possible to stop the session initiation, would there be any option where something can be adjusted in the stunnel side so that the other side sees only one TCP health check as opposed to multiple every few seconds?

That would require stunnel to somehow know that this new connection is about to be closed immediately. I don't think Dr Trojnara has implemented support for a PCI- or USB-connected crystal ball yet...

Also, it would require stunnel to somehow know that a no-data connection is "not important", which is... not necessarily true. Your own message shows that a no-data connection can be important for a partial "health check"; why partial? see https://www.stunnel.org/mailman3/hyperkitty/list/[email protected]/t... A connect/disconnect check does not really check whether stunnel works, it only checks whether the kernel knows that there should be some program that listens on that address and port, nothing more. Also, a connection where one side does not send any data does not necessarily mean that the other side has not / will not send any data - there are services that provide some information as soon as something establishes a connection.

Of course, one could think of a technical implementation[1] of something that detects no-data connections by delaying, not opening the connection to the remote side immediately, but waiting for, say, half a second instead, to see if the connection will be closed; but now the question is do you really want all your legitimate connections to also be delayed that way?

So... I guess this was a long-winded way of saying "no, stunnel cannot currently do what you want, and it might not be easy to teach it to, even in the cases in which it would be possible at all".

G'luck, Peter

[1] In theory something like that might be implemented using what was known in FreeBSD as an "accept filter" - basically a kernel module that allows a program to say "do not even tell me that something connected until they satisfy these conditions, e.g. send a full HTTP header or something", but that would still have the problem of "not actually checking whether stunnel is alive".