I’ll toss in an unpopular opinion here. I have used stunnel since day one. I had over the years problems with it not answering or the parent process dying altogether and other issues. I finally decided to run it from inetd rather than as a service. It is logical that this is a little slower but with modern machines I don’t notice it. inetd always is running. Always. If it is not you pretty much cannot use the machine. It has been a service program forever and is dead reliable. What you get is total reliability for an unnoticeable loss of speed. I suppose a heavily loaded machine running at capacity might not like this – my answer is throw hardware at it. I need reliable more than anything else. I’d at least try it!

E

VICS, LLC

Eric S Eberhard

2933 W Middle Verde Rd

Camp Verde, AZ 86322

928-567-3727 (land line)

928-301-7537 (cell phone)

http://www.vicsmba.com/ http://www.vicsmba.com

https://www.facebook.com/groups/286143052248115 https://www.facebook.com/groups/286143052248115

From: Jorge Redondo Flames jorge.redondo@gmail.com Sent: Wednesday, April 14, 2021 11:49 AM To: Peter Pentchev roam@ringlet.net Cc: stunnel-users@stunnel.org Subject: [stunnel-users] Re: Fwd: Re: Local socket keeps listening

Got it. Thank you very much!

On Wed, 14 Apr 2021 at 20:41, Peter Pentchev <roam@ringlet.net mailto:roam@ringlet.net > wrote:

On Wed, Apr 14, 2021 at 08:24:51PM +0200, Jorge Redondo Flames wrote:

On Wed, 14 Apr 2021 at 20:19, Jochen Bern <Jochen.Bern@binect.de mailto:Jochen.Bern@binect.de > wrote:

...

On 14.04.21 19:58, Jorge Redondo Flames wrote:

...

Stunnel could listen on its local port *only* when the peer server is listening on its corresponding server socket. So if there is no serve on the other side, there should not be local listening socket. Does not that make sense?

No.

In the general situation (server *not* being on the same machine as stunnel), stunnel CANNOT know whether the server's listening short of trying to connect to it - which it will only do on behalf of an incoming client request, which would never happen if stunnel weren't listening.

Even if server and stunnel run on the same machine/OS, finding out about the server's state would require a bunch of special-purpose code.

Assuming that they *are* on a common Linux (or at least unixoid) system, however, it would be rather trivial to write a root cron job that checks the output of "ss"/"netstat" for the server's LISTEN and simply terminates stunnel if it isn't found.

Or even better, have the server *restarted* automatically whenever it croaks ...

Understood. Although it still seems to me that the code doing more or less what the cron job would do might worth.

So, three points here.

1. There are some services (some servers) that do not react very nicely to somebody connecting to them and disconnecting immediately. Some of them do some work at the moment of the connection (e.g. resolve the client's IP address, check it against firewall rules, or even do some actual, service-specific, work, e.g. allocate buffers, prepare some kind of data...). Some of them are configured in such ways as to avoid portscanners or denial of service attacks or spam or flood or... many other things. In general, unless you *know* that it is safe to connect and immediately disconnect from the remote service, it is very unwise to try to do that. In your particular case, you know that, but in general, it is not a good idea.

2. Even if stunnel would try to connect to the remote service, what happens if the connection fails? OK, you say stunnel should close its local listening socket, but what then - will it never open it again? And if here's the part when you say "it can try to connect to the remote server again and start listening again" - okay, how much time passes between these connection attempts? Even something like a second may be bad if a real client chooses exactly this second to try to connect to stunnel and... stunnel is not listening... even though the remote server has started listening immediately after stunnel's last unsuccessful attempt. So... whatever interval you pick, closing the local listening socket *will* result in real, live clients failing to connect.

3. A more general point: if you really want to check whether a service is operational, only checking whether it will accept a connection is not enough. I've seen *many* failure modes over the years: from an overloaded machine where the OS kernel will accept the connection, but none of the actual server processes will react, through an overloaded service process that accepts the connection but spends too much time processing other requests to pay any attention to it, to a firewall host gone crazy that will pass connection packets, but will then refuse to pass the actual payload (yes, I've seen that happen for at least three different reasons). So an actual service check would be to connect and then send some kind of simple request to the server that you know will not take it too much time and resources to process, but will give you some measure of confidence that the server is actually serving requests and data.

But in short, it is impossible for stunnel to know whether a remote server is listening for a connection without trying to connect, it may not be "polite" for it to try to connect too often, and trying to connect not-too-often *will* result in real clients being unable to connect in the intermediate intervals.

G'luck, Peter