Please see highlighted below:

On Fri, May 8, 2015 at 5:27 PM, David H. Durgee <dhdurgee@verizon.net> wrote:
At some point in the near past stunnel stopped working on my laptop.  The laptop is running Linux Mint 17.1 Rebecca x64 and stunnel from the repositories.  I enabled debug=7, but I am not getting much from the log:


2015.05.08 17:12:06 LOG7[10804:140318864611136]: Clients allowed=500
2015.05.08 17:12:06 LOG5[10804:140318864611136]: stunnel 4.53 on x86_64-pc-linux-gnu platform
2015.05.08 17:12:06 LOG5[10804:140318864611136]: Compiled with OpenSSL 1.0.1e 11 Feb 2013
2015.05.08 17:12:06 LOG5[10804:140318864611136]: Running  with OpenSSL 1.0.1f 6 Jan 2014
2015.05.08 17:12:06 LOG5[10804:140318864611136]: Update OpenSSL shared libraries or rebuild stunnel

Is there a reason that you're using libraries from a different compiled Stunnel? In fact, isn't there another Stunnel package you can use that is more up-to-date? If not, perhaps compile your own using the OpenSSL libraries that comes with Mint.
 

2015.05.08 17:12:06 LOG5[10804:140318864611136]: Threading:PTHREAD SSL:+ENGINE+OCSP Auth:LIBWRAP Sockets:POLL+IPv6
2015.05.08 17:12:06 LOG5[10804:140318864611136]: Reading configuration from file /etc/stunnel/stunnel.conf
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Compression not enabled
2015.05.08 17:12:06 LOG7[10804:140318864611136]: PRNG seeded successfully
2015.05.08 17:12:06 LOG6[10804:140318864611136]: Initializing service section [telnets]
2015.05.08 17:12:06 LOG4[10804:140318864611136]: Insecure file permissions on /etc/ssl/certs/stunnel.pem

Warning: the permissions may be too wide-open (should be 700 I assume)
 

2015.05.08 17:12:06 LOG7[10804:140318864611136]: Certificate: /etc/ssl/certs/stunnel.pem
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Certificate loaded
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Key file: /etc/ssl/certs/stunnel.pem
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Private key loaded
2015.05.08 17:12:06 LOG7[10804:140318864611136]: SSL options set: 0x00000004
2015.05.08 17:12:06 LOG6[10804:140318864611136]: Initializing service section [dsp3270s]
2015.05.08 17:12:06 LOG4[10804:140318864611136]: Insecure file permissions on /etc/ssl/certs/stunnel.pem

Same as above, perhaps too wide open, permissions should be 700 I assume.
 

2015.05.08 17:12:06 LOG7[10804:140318864611136]: Certificate: /etc/ssl/certs/stunnel.pem
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Certificate loaded
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Key file: /etc/ssl/certs/stunnel.pem
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Private key loaded
2015.05.08 17:12:06 LOG7[10804:140318864611136]: SSL options set: 0x00000004
2015.05.08 17:12:06 LOG5[10804:140318864611136]: Configuration successful
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Service [telnets] (FD=12) bound to 0.0.0.0:3141
2015.05.08 17:12:06 LOG7[10804:140318864611136]: Service [dsp3270s] (FD=13) bound to 0.0.0.0:7490
2015.05.08 17:12:06 LOG7[10810:140318864611136]: Created pid file /stunnel4.pid
2015.05.08 17:12:31 LOG7[10810:140318864611136]: Service [telnets] accepted (FD=3) from 127.0.0.1:40090
2015.05.08 17:12:31 LOG7[10810:140318864770816]: Service [telnets] started
2015.05.08 17:12:31 LOG7[10810:140318864770816]: Waiting for a libwrap process
2015.05.08 17:12:31 LOG7[10810:140318864770816]: Acquired libwrap process #0
2015.05.08 17:12:31 LOG3[10810:140318864770816]: Unexpected socket close (read_blocking)
2015.05.08 17:12:31 LOG5[10810:140318864770816]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2015.05.08 17:12:31 LOG7[10810:140318864770816]: Local socket (FD=3) closed

that sounds like SELinux permissions perhaps? Have you tried temporarily disabling SELinux, or perhaps you have a firewall (iptables) set up? You'll have to allow the incoming port and possibly an entry in /etc/services IIRC. I don't know if this helps but this is what I found:
https://sites.google.com/site/easylinuxtipsproject/security
A link to "ufw" may prove useful, if your system has that installed. Most systems have locked-down privileged ports (any port less than 1024, like in your example).
 

2015.05.08 17:12:31 LOG7[10810:140318864770816]: Service [telnets] finished (0 left)
2015.05.08 17:12:31 LOG7[10810:140318864770816]: str_stats: 1 block(s), 32 data byte(s), 58 control byte(s)
2015.05.08 17:13:32 LOG7[10810:140318864611136]: Service [dsp3270s] accepted (FD=3) from 127.0.0.1:48534
2015.05.08 17:13:32 LOG7[10810:140318864770816]: Service [dsp3270s] started
2015.05.08 17:13:32 LOG7[10810:140318864770816]: Waiting for a libwrap process
2015.05.08 17:13:32 LOG7[10810:140318864770816]: Acquired libwrap process #1
2015.05.08 17:13:32 LOG3[10810:140318864770816]: Unexpected socket close (read_blocking)

That sounds like some kind of firewall issue (like above).
 
2015.05.08 17:13:32 LOG5[10810:140318864770816]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2015.05.08 17:13:32 LOG7[10810:140318864770816]: Local socket (FD=3) closed
2015.05.08 17:13:32 LOG7[10810:140318864770816]: Service [dsp3270s] finished (0 left)
2015.05.08 17:13:32 LOG7[10810:140318864770816]: str_stats: 1 block(s), 32 data byte(s), 58 control byte(s)


 When in a situation like this, I would first try unprivileged ports with localhost using iperf, just to generate some dummy traffic. A good technique I use when debugging stunnel versus debugging networking or other security issues is to do local traffic only like this:
  1. iperf client connect to localhost port 5000
  2. Stunnel client listen on port 5000, connect to localhost port 6000
  3. Stunnel server listen on port 6000, connect to localhost port 7000
  4. iperf server listening on localhost port 7000
As you can see from that, running iperf client for a few seconds, it should be able to connect to the iperf server. If not, stunnel is not working. Debug this FIRST before proceeding to working with non-localhost IP addresses. The actual procedure would be as follows:
  1. Download/install iperf
  2. Verify iperf works by having one shell run as server, listening on localhost port 7000, and another shell setup iperf client sending on port 7000. If that works, then proceed. Don't use iperf to connect to port 7000 again.
  3. Set up two config files, one for stunnel client and one for stunnel server, with different ports and the "client=yes" in the client config file. For easier detection with "ps" or "top", you can copy the executable file to another name (i.e., "s4client" for the stunnel 4 client, and "s4server" for the stunnel 4 server). Similarly for iperf, you can copy the exe to "iperfc" and "iperfs" for iperf server, for easier process detection.
  4. Start up the stunnel server first, then stunnel client, with the appropriate config files per the port enumeration mentioned above.
  5. Start iperf server listening on port 7000.
  6. Start iperf client sending on port 5000. If you get some really large value or nothing, then your stunnel config (client/server) needs to be debugged first before proceeding to non-localhost IPs. I usually get something like 3GB/sec when using a Windows 7 VM inside Windows 7 doing this from DOS prompts with appropriate server/client configs set up. I usually use four windows: two for iperf (c/s), two for stunnel (c/s).
Hope that helps...
  -Rob