I'd like to report an interesting problem I found that occurs on Linux but not Solaris when using the -fd 0 option to read the stunnel configuration in from stdin.

I am using stunnel to establish client tunnels on the fly for one time use by programs such as rsync. The client config file is generated automatically with some dynamic parameters. After the client tunnel is established a client program connects to the specified port on localhost.

This works fine on Solaris but on Linux I found that the client program has to be invoked *twice* before it works.

My work around is to write the config to a temp file and starting stunnel with the location of the file as its argument instead of writing to its standard input.

I am using tcp wrappers to protect the stunnel servers and to limit the connects to the client to localhost.

This isn't an issue for me anymore but it took a bit of troubleshooting to figure out. On Solaris I am running the same version of stunnel, openssl, etc... all compiled very similarly. One difference could be iconv but I don't know enough about it to say.

Regards, David Sorkin

Debug log from the first client invocation: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Nov 10 15:37:02 test03 stunnel: LOG5[32303:182894071744]: stunnel 4.27 on x86_64-unknown-linux-gnu with OpenSSL 0.9.8k 25 Mar 2009 Nov 10 15:37:02 test03 stunnel: LOG5[32303:182894071744]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv4 Auth:LIBWRAP Nov 10 15:37:02 test03 stunnel: LOG6[32303:182894071744]: file ulimit = 1024 (can be changed with 'ulimit -n') Nov 10 15:37:02 test03 stunnel: LOG6[32303:182894071744]: poll() used - no FD_SETSIZE limit for file descriptors Nov 10 15:37:02 test03 stunnel: LOG5[32303:182894071744]: 500 clients allowed Nov 10 15:37:03 test03 stunnel: LOG3[32309:1073809760]: Unexpected socket close (read_blocking) Nov 10 15:37:03 test03 stunnel: LOG5[32309:1073809760]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket Nov 10 15:37:03 test03 stunnel: LOG5[32309:182894071744]: Received signal 15; terminating

My client config is similar to the following: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ debug = local4.info foreground = no sslVersion = TLSv1 RNDfile = /dev/random RNDoverwrite = no pid = %s

[stunnel] client = yes key = /path/to/private_key.pem cert = /path/to/public_key_cert.pem verify = 0 accept = 127.0.0.1:12345 # ephemeral port connect = remote_host:123 # well known port ciphers = AES256-SHA

Server Config: ^^^^^^^^^^^^^^ debug = local4.info foreground = no pid = /var/run/stunnel.pid sslVersion = TLSv1 RNDfile = /dev/random RNDoverwrite = no

[rsync] client = no key = /path/to/private_key.pem cert = /path/to/public_key_cert.pem CAfile = /path/to/authority_certs.pem verify = 3 accept = 123 exec = /usr/bin/rsync execargs = rsync --daemon --no-detach ciphers = AES256-SHA

hosts.allow ^^^^^^^^^^^^ stunnel: 127.0.0.1 rsync: <ip of authorized server>

/usr/local/bin/stunnel -version

stunnel 4.27 on x86_64-unknown-linux-gnu with OpenSSL 0.9.8k 25 Mar 2009 Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv4 Auth:LIBWRAP

Global options debug = 5 pid = /var/run/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes

Service-level options cert = /usr/local/etc/stunnel.pem ciphers = AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH key = /usr/local/etc/stunnel.pem session = 300 seconds stack = 65536 bytes sslVersion = SSLv3 for client, all for server TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds verify = none

/usr/local/bin/stunnel -sockets

Socket option defaults: Option Accept Local Remote OS default SO_DEBUG -- -- -- 0 SO_DONTROUTE -- -- -- 0 SO_KEEPALIVE -- -- -- 0 SO_LINGER -- -- -- 0:0 SO_OOBINLINE -- -- -- 0 SO_RCVBUF -- -- -- 87380 SO_SNDBUF -- -- -- 16384 SO_RCVLOWAT -- -- -- 1 SO_SNDLOWAT -- -- -- 1 SO_RCVTIMEO -- -- -- 0:0 SO_SNDTIMEO -- -- -- 0:0 SO_REUSEADDR 1 -- -- 0 SO_BINDTODEVICE -- -- -- -- IP_TOS -- -- -- 0 IP_TTL -- -- -- 64 TCP_NODELAY -- -- -- 0

uname -a

Linux test1 2.6.9-89.0.11.ELsmp #1 SMP Mon Aug 31 11:00:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

-- David Sorkin david.sorkin@citi.com CATE - Network Engineering (908) 563-0017