Hi, I've been running stunnel for years to shuttle my syslogs off to a syslog server. It's performed flawlessly up until a few weeks ago. Recently, rebooting my syslog server results in the clients filling up /var/log/syslog with messages like below[1].
I'm not certain where the issue is. We've gone through some Ubuntu 16.04 > 18.04 upgrades on some hosts, as well as the syslog server. Is there a configuration item in stunnel to at least tell it to chill out a little and not try reconnecting 1000 times a second? My config from a client is here[2]
Last time this happened (few weeks ago) I googled around and found the TIMEOUTconnect parameter to try and get stunnel to at least wait 10 seconds before attempting another connect, but guess it doesn't work that way.
Any thoughts? The stunnel client is on Ubuntu 18.04. I'd rather not compile out-of-band for the latest stunnel version unless I must. I"m assuming this is a config issue on my end. The version I'm stuck with right now is stunnel 5.44 on x86_64-pc-linux-gnu platform
Thanks!
[1] May 23 17:42:04 shuriken stunnel: LOG5[44922183]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket May 23 17:42:04 shuriken stunnel: LOG5[44922184]: Service [syslog_tunnel] accepted connection from 127.0.0.1:55440 May 23 17:42:04 shuriken stunnel: LOG3[44922184]: s_connect: connect 192.168.1.96:51400: Connection refused (111) May 23 17:42:04 shuriken stunnel: LOG3[44922184]: No more addresses to connect May 23 17:42:04 shuriken stunnel: LOG5[44922184]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket May 23 17:42:04 shuriken stunnel: LOG5[44922185]: Service [syslog_tunnel] accepted connection from 127.0.0.1:55444 May 23 17:42:04 shuriken stunnel: LOG3[44922185]: s_connect: connect 192.168.1.96:51400: Connection refused (111) May 23 17:42:04 shuriken stunnel: LOG3[44922185]: No more addresses to connect
[2] client = yes cert = /etc/stunnel/shared/stunnel.pem pid = /var/run/stunnel4/syslog_stunnel.pid
[syslog_tunnel] accept = 127.0.0.1:5140 connect = 192.168.1.96:51400 TIMEOUTconnect = 10
This is indicative of the remote server not running on the right ports normally or actively blocking you, given the "Connection Refused" errors. Verify your system stunnel is on actually can connect to the specified IP and port combo independently of stunnel to start with.Sent from my Sprint Samsung Galaxy Note10+. -------- Original message --------From: digitek [email protected] Date: 5/23/20 19:18 (GMT-05:00) To: [email protected] Subject: [stunnel-users] /var/log/syslog is filling up with stunnel errors Hi,I've been running stunnel for years to shuttle my syslogs off to a syslog server. It's performed flawlessly up until a few weeks ago. Recently, rebooting my syslog server results in the clients filling up /var/log/syslog with messages like below[1].I'm not certain where the issue is. We've gone through some Ubuntu 16.04 > 18.04 upgrades on some hosts, as well as the syslog server. Is there a configuration item in stunnel to at least tell it to chill out a little and not try reconnecting 1000 times a second? My config from a client is here[2]Last time this happened (few weeks ago) I googled around and found the TIMEOUTconnect parameter to try and get stunnel to at least wait 10 seconds before attempting another connect, but guess it doesn't work that way.Any thoughts? The stunnel client is on Ubuntu 18.04. I'd rather not compile out-of-band for the latest stunnel version unless I must. I"m assuming this is a config issue on my end. The version I'm stuck with right now is stunnel 5.44 on x86_64-pc-linux-gnu platformThanks![1]May 23 17:42:04 shuriken stunnel: LOG5[44922183]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socketMay 23 17:42:04 shuriken stunnel: LOG5[44922184]: Service [syslog_tunnel] accepted connection from 127.0.0.1:55440May 23 17:42:04 shuriken stunnel: LOG3[44922184]: s_connect: connect 192.168.1.96:51400: Connection refused (111)May 23 17:42:04 shuriken stunnel: LOG3[44922184]: No more addresses to connectMay 23 17:42:04 shuriken stunnel: LOG5[44922184]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socketMay 23 17:42:04 shuriken stunnel: LOG5[44922185]: Service [syslog_tunnel] accepted connection from 127.0.0.1:55444May 23 17:42:04 shuriken stunnel: LOG3[44922185]: s_connect: connect 192.168.1.96:51400: Connection refused (111)May 23 17:42:04 shuriken stunnel: LOG3[44922185]: No more addresses to connect[2]client = yescert = /etc/stunnel/shared/stunnel.pempid = /var/run/stunnel4/syslog_stunnel.pid[syslog_tunnel]accept = 127.0.0.1:5140connect = 192.168.1.96:51400TIMEOUTconnect = 10_______________________________________________stunnel-users mailing [email protected]https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Thomas Ward wrote on 5/23/20 7:09 PM:
This is indicative of the remote server not running on the right ports normally or actively blocking you, given the "Connection Refused" errors. Verify your system stunnel is on actually can connect to the specified IP and port combo independently of stunnel to start with.
Ok I will look into that. Is there a way to configure stunnel so it doesn't try to reconnect so often? 1500 entries in one second is excessive.
# grep '16:45:46' syslog | wc -l 1580
Thomas Ward wrote on 5/23/20 7:09 PM:
This is indicative of the remote server not running on the right ports normally or actively blocking you, given the "Connection Refused" errors. Verify your system stunnel is on actually can connect to the specified IP and port combo independently of stunnel to start with.
I noticed this morning there are possible malloc issues appearing in syslog as well. Is this perhaps related? This is log from a postgres stunnel client.
May 24 06:27:12 copper stunnel: LOG5[1022959]: Service [postgres_tunnel] connected remote server from 192.168.1.24:41350 May 24 06:27:12 copper stunnel: LOG5[1022958]: Service [postgres_tunnel] connected remote server from 192.168.1.24:41348 May 24 06:27:12 copper stunnel: LOG5[1022960]: s_connect: connected 192.168.1.9:15432 May 24 06:27:12 copper stunnel: LOG5[1022960]: Service [postgres_tunnel] connected remote server from 192.168.1.24:41352 May 24 06:27:12 copper stunnel: LOG5[1022920]: Connection closed: 3278 byte(s) sent to TLS, 2024 byte(s) sent to socket May 24 06:27:12 copper stunnel: LOG4[1022920]: Possible memory leak at ../crypto/bn/bn_lib.c:224: 30007 allocations May 24 06:27:12 copper stunnel: LOG5[1022918]: Connection closed: 4519 byte(s) sent to TLS, 1972 byte(s) sent to socket May 24 06:27:12 copper stunnel: LOG5[1022919]: Connection closed: 1174 byte(s) sent to TLS, 732 byte(s) sent to socket May 24 06:27:12 copper stunnel: LOG4[1022918]: Possible memory leak at ../crypto/bn/bn_lib.c:224: 30007 allocations May 24 06:27:12 copper stunnel: LOG4[1022919]: Possible memory leak at ../crypto/bn/bn_lib.c:224: 30007 allocations
-
digitek -
Thomas Ward