Thanks, Peter. That is clear.
Finally I discovered that it was no health check or so but still (unexpectedly) one of our devices trying to setup a connection with wrong settings.

Thanks for your prompt responses.

Marcel

 
 



x

x

x


 

Rijksmuseum.nl


Van: Peter Pentchev
Verzonden: Woensdag, 22 Januari, 2025 17:59
Aan: Marcel de Rooy
CC: stunnel-users@stunnel.org
Onderwerp: Re: [stunnel-users] Re: stunnel warning: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number

On Tue, Jan 21, 2025 at 03:24:36PM +0000, Marcel de Rooy via stunnel-users wrote:
> Thanks Mike.
> The attempts do not seem to come from outside since I am filtering that traffic (tcp stream via nginx).
> The 23.1 address is the docker gateway of the network where the stunnel container lives.
> So I think that we must look for an internal suspect.
> Will still be testing a few things and report back.

If these connection attempts really do come at regular intervals,
I would suggest looking for some monitoring system that tries to
make sure the stunnel server is up and running. Unfortunately,
as you have found out, connecting and then immediately disconnecting
is NOT a good way to check whether an stunnel service is up :)
The only way to really check that would be to:
- know the purpose of the tunnels maintained by the stunnel service
- make sure there is a way to run a monitoring check based on that
  purpose without making any changes to existing data, "just checking"
- if there is indeed such a way, then change the monitoring check to
  actually wait for stunnel to establish the tunnel and then
  send/receive some data along that tunnel to make sure that both
  the tunnel itself and the service behind the tunnel are okay

As I have written in previous e-mails, trying to check whether a host
merely accepts a TCP connection on a particular port is not really a good
health check for many reasons, the most trivial one being that it may be
possible that the connection will be accepted by the kernel, but for
many reasons (overloaded system, a bug in stunnel, many others) stunnel
itself may not be able to process it... so the only way to check is to
make sure the tunnel is established and data flows through it correctly.

G'luck,
Peter

--
Peter Pentchev  roam@ringlet.net roam@debian.org peter@morpheusly.com
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13