[stunnel-users] stunnel client: accept on connect success

[mihertz at gmx.de]

Hi everyone,

could use some help for a stunnel client-mode question.

Found no corresponding config directives in the manpage, not sure i am
searching with the correct terms... or going for the correct approach at
all.

So there is a scenario where the stunnel client plaintext side does the
tcp-handshake (S/S./.) and directly terminates the connected client
afterwards (R.). This is caused because the corresponding connect-target
fails to establish a TCP/TLS connection with the server (rejected by
target server for whatever reason).

This could cause a first regular tcp-packet to be send and lost, before
stunnel disconnects on the plaintext-side and the application becomes
aware of that eventually.

I wonder if there is a way to configure stunnel to behave in a similar
way to haproxy /w acl? Where it denies all tcp connects unless at least
1 backend server is available.

So that stunnel would like "delay" the accept-side TCP handshake while
trying to connect to the connect-side via TLS. Based on TCP/TLS
success/failure on the connect-side then continues the accept-side TCP
handshake or quits its. This way the client would never have the short
moment of "ok, i can start"

I know that this behaviour is not optimal/desired with the majority of
cases, just have the impression I have a use-case for this in my
scenario. There is no way to modify the plaintext-side connected
application in any way. Tx/Rx data is just a few bytes, so its always 1
packet for requests/answers.
And relatively often that first packet sent goes out before the reset
(R.) is received by the stunnel client-mode to the software connected on
the accept-side.

Would be happy for your input and ideas on how to work around that.

Best Regards
Michael