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