Irans goverment start to detect stunnel with openvpn tunnel. how to avoid this? is there any updates for stunnel for this problem?
1
0
Hello,
I’m working on replacing an older Windows server that uses stunnel 5.71 to connect to an Oracle database running on a Linux box. I can communicate just fine with the older Windows machine and another Linux box; however, when I try to connect with the stunnel 5.72 on the Windows 2022 server, I keep running into issues and the connection is forcibly closed.
Old Windows server: stunnel 5.71
New Windows 2022 server: stunnel 5.72 (I also tried 5.71 and 5.62 just to rule things out
Oracle db server: stunnel 5.72
Other Linux server: stunnel 5.72
My stunnel.conf file is very basic, but this is what is working from my other Windows server (running stunnel 5.71):
debug = 7
[oracle15211]
client = yes
accept = 127.0.0.1:15211
connect = 172.28.125.52:15211
Below is the log with debug level 7… the only issue that I’m seeing is the “transfer() loop executes not transferring any data” message that baffles me but I’m not sure if that’s the cause of my issues or not:
2024.02.23 11:10:21 LOG7[0]: Service [oracle15211] started
2024.02.23 11:10:21 LOG7[0]: Setting local socket options (FD=768)
2024.02.23 11:10:21 LOG7[0]: Option TCP_NODELAY set on local socket
2024.02.23 11:10:21 LOG5[0]: Service [oracle15211] accepted connection from 127.0.0.1:49750
2024.02.23 11:10:21 LOG6[0]: s_connect: connecting 172.28.125.52:15211
2024.02.23 11:10:21 LOG7[0]: s_connect: s_poll_wait 172.28.125.52:15211: waiting 10 seconds
2024.02.23 11:10:21 LOG7[0]: FD=780 ifds=rwx ofds=---
2024.02.23 11:10:21 LOG5[0]: s_connect: connected 172.28.125.52:15211
2024.02.23 11:10:21 LOG5[0]: Service [oracle15211] connected remote server from 172.28.112.245:49751
2024.02.23 11:10:21 LOG7[0]: Setting remote socket options (FD=780)
2024.02.23 11:10:21 LOG7[0]: Option TCP_NODELAY set on remote socket
2024.02.23 11:10:21 LOG7[0]: Remote descriptor (FD=780) initialized
2024.02.23 11:10:21 LOG6[0]: SNI: sending servername: 172.28.125.52
2024.02.23 11:10:21 LOG6[0]: Peer certificate not required
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): before SSL initialization
2024.02.23 11:10:21 LOG7[0]: Initializing application specific data for session authenticated
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): TLSv1.3 read encrypted extensions
2024.02.23 11:10:21 LOG6[0]: CERT: Certificate verification disabled
2024.02.23 11:10:21 LOG6[0]: CERT: Certificate verification disabled
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): TLSv1.3 read server certificate verify
2024.02.23 11:10:21 LOG7[0]: OCSP stapling: Client callback called
2024.02.23 11:10:21 LOG6[0]: OCSP: Certificate chain verification disabled
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read finished
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write finished
2024.02.23 11:10:21 LOG7[0]: 1 client connect(s) requested
2024.02.23 11:10:21 LOG7[0]: 1 client connect(s) succeeded
2024.02.23 11:10:21 LOG7[0]: 0 client renegotiation(s) requested
2024.02.23 11:10:21 LOG7[0]: 0 session reuse(s)
2024.02.23 11:10:21 LOG6[0]: TLS connected: new session negotiated
2024.02.23 11:10:21 LOG6[0]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption)
2024.02.23 11:10:21 LOG6[0]: Peer temporary key: X25519, 253 bits
2024.02.23 11:10:21 LOG7[0]: Compression: null, expansion: null
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully
2024.02.23 11:10:21 LOG7[0]: Initializing application specific data for session authenticated
2024.02.23 11:10:21 LOG7[0]: Deallocating application specific data for session connect address
2024.02.23 11:10:21 LOG7[0]: New session callback
2024.02.23 11:10:21 LOG7[0]: Peer certificate was cached (1375 bytes)
2024.02.23 11:10:21 LOG6[0]: Session id: B36502A30B16F61EFE3A13B7BAA73BBCD57C2C6DB838FFC7CDFDE9BF7D8607A0
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server session ticket
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully
2024.02.23 11:10:21 LOG7[0]: Initializing application specific data for session authenticated
2024.02.23 11:10:21 LOG7[0]: New session callback
2024.02.23 11:10:21 LOG7[0]: Deallocating application specific data for session connect address
2024.02.23 11:10:21 LOG6[0]: Session id: 7FC6ABDCD70443FE70736F725F90792FAC2692FD9AD8F54A3F0443C2403C9A0C
2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server session ticket
2024.02.23 11:10:21 LOG3[0]: transfer() loop executes not transferring any data
2024.02.23 11:10:21 LOG3[0]: please report the problem to Michal.Trojnara(a)stunnel.org<mailto:[email protected]>
2024.02.23 11:10:21 LOG3[0]: stunnel 5.72 on x64-pc-mingw32-gnu platform
2024.02.23 11:10:21 LOG3[0]: Compiled/running with OpenSSL 3.2.1 30 Jan 2024
2024.02.23 11:10:21 LOG3[0]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI
2024.02.23 11:10:21 LOG7[0]: errno: (*_errno())
2024.02.23 11:10:21 LOG3[0]: protocol=TLSv1.3, SSL_pending=0, SSL_has_pending=0
2024.02.23 11:10:21 LOG3[0]: sock_open_rd=Y, sock_open_wr=Y
2024.02.23 11:10:21 LOG3[0]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n
2024.02.23 11:10:21 LOG3[0]: sock_can_rd=n, sock_can_wr=n
2024.02.23 11:10:21 LOG3[0]: ssl_can_rd=n, ssl_can_wr=n
2024.02.23 11:10:21 LOG3[0]: read_wants_read=Y, read_wants_write=n
2024.02.23 11:10:21 LOG3[0]: write_wants_read=n, write_wants_write=n
2024.02.23 11:10:21 LOG3[0]: shutdown_wants_read=n, shutdown_wants_write=n
2024.02.23 11:10:21 LOG3[0]: socket input buffer: 0 byte(s), TLS input buffer: 0 byte(s)
2024.02.23 11:10:21 LOG5[0]: Connection reset: 685 byte(s) sent to TLS, 381 byte(s) sent to socket
2024.02.23 11:10:21 LOG7[0]: remote_fd reset (FD=780)
2024.02.23 11:10:21 LOG7[0]: Remote descriptor (FD=780) closed
2024.02.23 11:10:21 LOG7[0]: local_rfd/local_wfd reset (FD=768)
2024.02.23 11:10:21 LOG7[0]: Local descriptor (FD=768) closed
2024.02.23 11:10:21 LOG7[0]: Service [oracle15211] finished (0 left)
Any help is greatly appreciated!
Thank you,
Mark
1
0
Hi,
I'm running Stunnel on Linux. It needs to connect to a dynamic IP
address (by domain name). The DNS is updated automatically. I noticed
that the last time the address changed, Stunnel stopped working. A ping
from the machine produced the correct address but Stunnel was using the
old one.
Will a reload work?
4
6
Dear Users,
I have released version 5.72 of stunnel.
### Version 5.72, 2024.02.04, urgency: MEDIUM
* Security bugfixes
- OpenSSL DLLs updated to version 3.2.1.
* Bugfixes
- Fixed SSL_CTX_new() errors handling.
- Fixed OPENSSL_NO_PSK builds.
- Android build updated for NDK r23c.
- stunnel.nsi updated for Debian 12.
- Fixed tests with OpenSSL older than 1.0.2.
Home page: https://www.stunnel.org/
Download: https://www.stunnel.org/downloads.html
SHA-256 hashes:
3d532941281ae353319735144e4adb9ae489a10b7e309c58a48157f08f42e949
stunnel-5.72.tar.gz
1037c53f8ab590c2f3001e54cf381c3ea4225e9670b03870191383060e6851e7
stunnel-5.72-win64-installer.exe
668161b90034820198c456b4137ed3680d6fd49d4de920d51e499b84538f63d3
stunnel-5.72-android.zip
Best regards,
Mike
1
0
stunnel - client conexion close by TLS alert (write) fatal decode error
by Rodigo Alvarez 24 Jan '24
by Rodigo Alvarez 24 Jan '24
24 Jan '24
Hi All!
I would appreciate any clue to solve the problem we are having with a client mode service that stopped working this week (we verified that the service works directly without stunnel).
The error I identify in the trace is the following: "TLS alert (write): fatal: decode error"
Stunnel Config (windows version):
[afip-prod-fce]
client = yes
accept = ARSASSRV4DMS06:1031
connect = serviciosjava.afip.gob.ar:443
debug = 7
ws: https://serviciosjava.afip.gob.ar/wsfecred/FECredService
Complete trace:
2024.01.24 09:28:46 LOG5[main]: stunnel 5.71 on x64-pc-mingw32-gnu platform
2024.01.24 09:28:46 LOG5[main]: Compiled/running with OpenSSL 3.1.3 19 Sep 2023
2024.01.24 09:28:46 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI
2024.01.24 09:28:46 LOG5[main]: Reading configuration from file C:\Program Files (x86)\stunnel\config\stunnel.conf
2024.01.24 09:28:46 LOG5[main]: UTF-8 byte order mark detected
2024.01.24 09:28:46 LOG5[main]: FIPS mode disabled
2024.01.24 09:28:46 LOG4[main]: Service [afip-prod-fce] needs authentication to prevent MITM attacks
2024.01.24 09:28:46 LOG5[main]: Configuration successful
2024.01.24 09:29:23 LOG7[0]: Service [afip-prod-fce] started
2024.01.24 09:29:23 LOG7[0]: Setting local socket options (FD=892)
2024.01.24 09:29:23 LOG7[0]: Option TCP_NODELAY set on local socket
2024.01.24 09:29:23 LOG5[0]: Service [afip-prod-fce] accepted connection from 10.70.162.24:57723
2024.01.24 09:29:23 LOG6[0]: s_connect: connecting 200.1.116.19:443
2024.01.24 09:29:23 LOG7[0]: s_connect: s_poll_wait 200.1.116.19:443: waiting 10 seconds
2024.01.24 09:29:23 LOG7[0]: FD=896 ifds=rwx ofds=---
2024.01.24 09:29:24 LOG5[0]: s_connect: connected 200.1.116.19:443
2024.01.24 09:29:24 LOG5[0]: Service [afip-prod-fce] connected remote server from 10.72.0.69:64788
2024.01.24 09:29:24 LOG7[0]: Setting remote socket options (FD=896)
2024.01.24 09:29:24 LOG7[0]: Option TCP_NODELAY set on remote socket
2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) initialized
2024.01.24 09:29:24 LOG6[0]: SNI: sending servername: serviciosjava.afip.gob.ar
2024.01.24 09:29:24 LOG6[0]: Peer certificate not required
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): before SSL initialization
2024.01.24 09:29:24 LOG7[0]: Initializing application specific data for session authenticated
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello
2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled
2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled
2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server key exchange
2024.01.24 09:29:24 LOG7[0]: OCSP stapling: Client callback called
2024.01.24 09:29:24 LOG6[0]: OCSP: Certificate chain verification disabled
2024.01.24 09:29:24 LOG6[0]: Client certificate not requested
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server done
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client key exchange
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read change cipher spec
2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read finished
2024.01.24 09:29:24 LOG7[0]: New session callback
2024.01.24 09:29:24 LOG7[0]: Peer certificate was cached (6643 bytes)
2024.01.24 09:29:24 LOG6[0]: Session id: D63C79766AC02C9A3E8494AD528954A183E9F7C250856695BA05C16A2219A4B3
2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) requested
2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) succeeded
2024.01.24 09:29:24 LOG7[0]: 0 client renegotiation(s) requested
2024.01.24 09:29:24 LOG7[0]: 0 session reuse(s)
2024.01.24 09:29:24 LOG6[0]: TLS connected: new session negotiated
2024.01.24 09:29:24 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption)
2024.01.24 09:29:24 LOG6[0]: Peer temporary key: ECDH, P-256, 256 bits
2024.01.24 09:29:24 LOG7[0]: Compression: null, expansion: null
2024.01.24 09:29:24 LOG7[0]: Remove session callback
2024.01.24 09:29:24 LOG7[0]: TLS alert (write): fatal: decode error
2024.01.24 09:29:24 LOG6[0]: TLS socket closed (SSL_read)
2024.01.24 09:29:24 LOG7[0]: Sent socket write shutdown
2024.01.24 09:29:24 LOG5[0]: Connection closed: 1755 byte(s) sent to TLS, 634 byte(s) sent to socket
2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) closed
2024.01.24 09:29:24 LOG7[0]: Local descriptor (FD=892) closed
2024.01.24 09:29:24 LOG7[0]: Service [afip-prod-fce] finished (0 left)
Thank you!
Kind regards,
Rodrigo.
1
0
Hi,
I've been using Stunnel for many years without a problem but I just changed my email provider and now my mail client can't send emails.
Receiving via POP is still fine, but sending via SMTP is giving the error "SSL_connect: ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number"
The old SMTP server was on port 465 whereas the new server (hotmail) is on port 587 so that may be the source of the problem.
My config file is quite simple:
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
client = yes
[pop]
accept = 110
connect = outlook.office365.com:995
[smtp]
accept = 25
connect = smtp-mail.outlook.com:587
I just changed the POP and SMTP server details to the new ones. POP is still on port 995 as it was before but SMTP has changed from 465 to 587.
I was running an older version of Stunnel but updating to latest version hasn't helped.
Does anyone have any ideas? I'd hate to have to lose my old Email client which has so many messages stored so it would be great to get it working fully with hotmail.
Thanks!
Graham.
4
3
Good morning guys!
I started using stunnel very recently with GLPI to authenticate to
Google LDAP, and it is working, but with extreme slowness at Login.
Something around 35 seconds. I believe there may be some parameters,
adjustments to make. I'm sending the stunnel.conf configuration below,
as well as the attached log file(txt). Could you give me a suggestion.
Thanks,
Luciano
# stunnel.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
debug = 7
output = /var/log/stunnel4/stunnel.log
[ldap]
client = yes
accept = 127.0.0.1:1636
connect = ldap.google.com:636
cert = /etc/certificates/glpi_ldap.crt
key = /etc/certificates/glpi_ldap.key
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1
0
I have a strange problem connecting from a C++ application using the Paho framework to the stunnel.
The certificates are self signed, and MQTT Explorerr hooks up nicely and validates the certificate when fed with the appropriate ca certificate.
So, stunnel seems to behave nicely on some cases, others not.
The stunnel log shows a SSL_accept: ssl/record/ssl3_record_c:354: errror: 0A00010B:SSL wrong version.
I have tried version 1.1 and 1.2 in the Paho library, both failing with the same error code.
Any ideas or suggestions?
1
0
Michael,
On 12/13/23 15:43, Michael D. Setzer II wrote:
> /var/log/secure
Thank you for your reply, but /var/log is basically empty (meaning very
few files located there). journald has absorbed everything and files are
no longer the way to get logs from systemd-based environments.
The only thing which contains non-trivial information is
/var/log/journal/* which is a bunch of binary files.
My reply below shows how you can get the stunnel-related log messages. I
don't believe they are available through any traditional text-based log
file.
-chris
> On 13 Dec 2023 at 15:37, Christopher Schultz wrote:
>
> Date sent: Wed, 13 Dec 2023 15:37:04 -0500
> To: "'stunnel-users(a)stunnel.org'"
> <stunnel-users(a)stunnel.org>
> From: Christopher Schultz
> <chris(a)christopherschultz.net>
> Subject: [stunnel-users] Re: Getting logs in systemd
> environment
> patches" <stunnel-users.stunnel.org>
>
>> Carter,
>>
>> On 12/13/23 14:53, cbrowne wrote:
>>> Have you tried doing "find / -name stunnel.log -print" as root. I have
>>> found that the log file can be in a number of different locations
>>> depending on the system.
>>
>> There are no files named stunnel.log on my system.
>>
>> I do not have a specific setting for "output". I was expecting syslog to
>> be used for that purpose without a specific setting. syslog=yes appears
>> to be the default given the man page for stunnel.
>>
>> But your comment got me more interested in exactly what was happening,
>> so I tried /not/ limiting journalctl --follow to a specific service and
>> I can see all kinds of things coming from stunnel:
>>
>>
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: Found 1 ready
>> file descriptor(s)
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=4
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=11
>> events=0x2001 revents=0x1
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=12
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=13
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=14
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: Service
>> [ORU-outbound] accepted (FD=3) from ::ffff:20.204.213.204:55455
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: Service
>> [ORU-outbound] started
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: Setting local
>> socket options (FD=3)
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: Option
>> TCP_NODELAY set on local socket
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG5[174806]: Service
>> [ORU-outbound] accepted connection from ::ffff:20.204.213.204:55455
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG6[174806]: Peer
>> certificate required
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): before SSL initialization
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): before SSL initialization
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: Initializing
>> application specific data for session authenticated
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: SNI: no
>> virtual services defined
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): SSLv3/TLS read client hello
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): SSLv3/TLS write server hello
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): SSLv3/TLS write certificate
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): SSLv3/TLS write key exchange
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): SSLv3/TLS write certificate request
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS state
>> (accept): SSLv3/TLS write server done
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: Found 1 ready
>> file descriptor(s)
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=4
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=11
>> events=0x2001 revents=0x1
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=12
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=13
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: FD=14
>> events=0x2001 revents=0x0
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[main]: Service
>> [ORU-outbound] accepted (FD=15) from ::ffff:client.ip:44905
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: Service
>> [ORU-outbound] started
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: Setting local
>> socket options (FD=15)
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: Option
>> TCP_NODELAY set on local socket
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG5[174807]: Service
>> [ORU-outbound] accepted connection from ::ffff:client.ip:44905
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG6[174807]: Peer
>> certificate required
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): before SSL initialization
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): before SSL initialization
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: Initializing
>> application specific data for session authenticated
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: SNI: no
>> virtual services defined
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): SSLv3/TLS read client hello
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): SSLv3/TLS write server hello
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): SSLv3/TLS write certificate
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): SSLv3/TLS write key exchange
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): SSLv3/TLS write certificate request
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174807]: TLS state
>> (accept): SSLv3/TLS write server done
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: TLS alert
>> (read): fatal: certificate unknown
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG7[174806]: Remove
>> session callback
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG3[174806]: SSL_accept:
>> ssl/record/rec_layer_s3.c:1605: error:0A000416:SSL routines::sslv3 alert
>> certificate unknown
>> Dec 13 20:31:00 example.com stunnel[300695]: LOG5[174806]: Connection
>> reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
>>
>> So this probably just comes down to either systemd/journalctl or me
>> being stupid.
>>
>> Instead of asking for the journal/log for the "unit" stunnel (i.e.
>> journalctl -u stunnel), you need instead to ask for the "systelog
>> identifier" called stunnel like this:
>>
>> $ journalctl -t stunnel
>>
>> If you use --follow you get tail -f behavior, which is nice to see
>> what's happening in real-time.
>>
>> -chris
>>
>>> On 12/13/2023 2:39 PM, Christopher Schultz wrote:
>>>> other systems (e.g. /var/log/seure, /var/log/auth, etc.). It appears
>>>> the case that I should be able to view the journals using this command:
>>>>
>>>> sudo journalctl --follow -u stunnel.service
>>>>
>>>> But nothing is ever printed there.
>>>
>> _______________________________________________
>> stunnel-users mailing list -- stunnel-users(a)stunnel.org
>> To unsubscribe send an email to stunnel-users-leave(a)stunnel.org
>
>
> +------------------------------------------------------------+
> Michael D. Setzer II - Computer Science Instructor
> (Retired)
> mailto:[email protected]
> mailto:[email protected]
> mailto:[email protected]
> Guam - Where America's Day Begins
> G4L Disk Imaging Project maintainer
> http://sourceforge.net/projects/g4l/
> +------------------------------------------------------------+
>
>
>
2
2
All,
I recently built a server from scratch in Amazon EC2 using Amazon Linux
2023 which is systemd-based.
When having trouble with a client failing to connect to our
stunnel-based service, I tried raising the log level:
debug=7
and restarted the service.
I can't find any indication that the logs are available.
There is no /var/log/stunnel directory. There are none of the usual
files I might expect these logs to be in on other systems (e.g.
/var/log/seure, /var/log/auth, etc.). It appears the case that I should
be able to view the journals using this command:
sudo journalctl --follow -u stunnel.service
But nothing is ever printed there.
Does anyone know how to get logging from stunnel in this kind of
environment?
(BTW, *I* am able to connect to this service, so I know it's running,
etc. This is only a logging-problem, not an stunnel-isnt-working problem.)
Thanks,
-chris
2
1