Hello

A few days ago we ran into issue where the number of stunnel threads sky rocketed to over 3000 open stunnel threads. When this happen connections to our website slowed down considerably or failed to connect. It was resolved by flipping to our other proxy which accepted any new connections. It took about 5 minutes for the threads to die off on the other proxy. I was wondering if anyone has come across this problem? 

Here are some details of our stunnel version and config.

Stunnel 4.44 with patch for x-forwarder

[root@brm-proxy01 ~]# stunnel -version
stunnel 4.44 on x86_64-unknown-linux-gnu platform
Compiled/running with OpenSSL 1.0.0-fips 29 Mar 2010
Threading:PTHREAD SSL:ENGINE Auth:LIBWRAP Sockets:POLL,IPv6
 
Global options:
debug           = daemon.notice
pid             = /var/run/stunnel.pid
RNDbytes        = 64
RNDfile         = /dev/urandom
RNDoverwrite    = yes
 
Service-level options:
ciphers         = ALL:!SSLv2:!aNULL:!EXP:!LOW:-MEDIUM:RC4:+HIGH
curve           = prime256v1
session         = 300 seconds
sslVersion      = TLSv1 for client, all for server
stack           = 65536 bytes
TIMEOUTbusy     = 300 seconds
TIMEOUTclose    = 60 seconds
TIMEOUTconnect  = 10 seconds
TIMEOUTidle     = 43200 seconds
verify          = none appriacated


Our stunnel.conf.

/etc/stunnel/stunnel.conf 
#sslVersion      = TLSv1
pid             = /var/run/stunnel.pid
syslog          = yes
output = /var/log/stunnel.log
debug = 3

[https]
cert        = /etc/stunnel/ssl/wildcard.blah.com.pem
accept      = 443
connect     = 80
xforwardedfor   = yes
TIMEOUTbusy     = 300
TIMEOUTclose    = 0
TIMEOUTconnect  = 10
TIMEOUTidle     = 60

Is there anything we could add for performance tuning in stunnel? Any suggestions on what I could look for when this happens again would be appreciated. Our platform does between 2000 to 3000 rpm (request per minute) during peak hours. 

We constantly see a lot of these messages every hour but I am not sure what is happening as the connections seem to be working.

SSL_accept: Peer suddenly disconnected

There was a higher spike of them as per the normal rate during our incident described above.

Thanks

Stephen Griffin
Sr. System Administrator
www.achievers.com

 

Confidentiality: The information contained in this e-mail and any attachments are confidential. If you are not the intended recipient, you may not copy or distribute this information. If you have received this communication in error, please notify the sender immediately and delete it from your system.