[stunnel-users] blackhole problem - please help to tune stunnel

Thu May 28 10:02:07 CEST 2020

On Thu, May 28, 2020 at 10:52:37AM +0300, Michael S. Chusovitin wrote:
> On Thu, May 28, 2020, 10:14 Michał Trojnara <Michal.Trojnara at stunnel.org>
> wrote:
> > On 5/28/2020 2:04 AM, Michael S. Chusovitin wrote:
> > > Dear stunnel users,
> > >
> > > please advise how to solve the following:
> > >
> > > - an Application connects to stunnel-client (installed at the same
> > > machine);
> > > - stunnel-client tries to connect to stunnel-server (remote), fails and
> > > sends RST to the App;
> > > - but the App has already sent some datagrams to stunnel-client during
> > > TIMEOUTconnect period and they aren't transferred to stunnel-server.
> > >
> > > Is there any way to make stunnel-client delay its ACK to the App until the
> > > connection to stunnel-server is established?
> > >
> > > Thanks!
> > 
> > Hi Michael,
> >
> > No, there is no portable way of implementing this feature.  In fact, the
> > OS kernel only notifies server applications (including stunnel) about a new
> > incoming connection *after* the three-way TCP handshake has completed.
> >
> > Some more details:
> > https://groups.google.com/forum/#!topic/comp.protocols.tcp-ip/vk7uY5dkdpY
> 
> Thanks Michal...
> 
> Thus the _only_ way to deliver the data reliably through stunnel is some
> application-level integrity protocol?
> I believed that many people use stunnel for wide variety of applications
> and so they should succeed in workarounding this trouble. Maybe I am
> missing something about the well-known good practice of stunnel usage?..

Unfortunately, with the way TCP/IP works, if you want assurance that
the other side has received and processed your data, you still need some
kind of application-level conversation. You need that with plain old TCP
connections, too - it's not about a forwarder/proxy. I've seen all sorts
of rare, weird, and absolutely insane failures, some due to OS/library
bugs, some due to network equipment, some due to actual cut cables...
It is possible for a TCP session to take minutes and, in some cases,
*days* to time out, and that's assuming you even *receive*
the notification about it timing out.

Yes, I know, it does say "reliable"... well, it is *more* reliable than
UDP, but that's all you can trust.

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at debian.org pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20200528/f4c3e0ed/attachment.sig>