Sounds like a possible issue with a DDOS scenario even if it might be internal.. See below on what i mean..
I.e. if you have routing towards the STUNNEL host but for some host remotely that have no return routes..
That could cause the IP stack to run out of possible listeners to serve incoming connections.
In the early days of internet when someone was upset about the funny service hotmail.com they ( ISP in US ) added filters to block spam..
For us in Sweden we got the 1st TCP packet but never the response packets.. Filling up all listening queues.. Now and then the listening queue was cleaned up due to timeouts and a few working session was established.
Might not be this.. But worth checking based on the description, if not just a comment on what we can experience on internet by a simple issue..
I.e. full routing end 2 end on all possible sessions. And FW rules that will allow this.. Ans no asymmetric routing that by mistake drops sessions thru firewalls..
Regards/Uffe
On 2022-02-04 23:08, Eberhard wrote:
We support so many Unix versions with thousands of users of various capabilities. I don’t want to have to learn secret tricks – especially as they change with versions of the O/S. So I use inetd – all the same on every O/S and always works. I see no reason not to do this unless you have a belief that there is a performance issue with it, which is possible I suppose but I suspect completely unlikely in modern computers. Further, inetd is running anyway so the server part is hardly affected by stunnel whereas if you use stunnel in server mode it has overhead … so a real picky person would do performance analysis and it still may be more efficient to use inetd depending on server overhead. Which is like different by O/S and computer hardware and …