[stunnel-users] Connection reset by peer on same local networ k?

Jeremy Simons jsimons at eagleoptics.com
Tue Jan 3 22:47:11 CET 2006

The problem is not with stunnel, but with rsyncd. I assume you are running
rsyncd on the source machine in conjunction with the /etc/rsyncd.conf file.
The cool thing about running rsyncd through stunnel is the rsync client
appears to the rsyncd as a local machine (obviously) so permissions are a
problem. The best way I could recommend since you need to access root owned
files would be to setup your rsyncd entry something like:

## Example of full access to /home directory
uid = root
gid = root
path = /home
comment = home directory.
hosts allow =
read only = no
ignore nonreadable = no
refuse options = checksum
dont compress = *

If you notice the "hosts allow" directive only allows access from
localhost( The problem is *anyone* can connect to your stunnel
server unless you require security I would recommend using your firewall to
allow access to your stunnel instance and also to use non-standard ports
(I.E. 50000-50010). Using a firewall in lieu of authentication is obviously
NOT secure or even recommended for a production environment but is simply
added security that certainly doesn't hurt. The workaround would be to
secure stunnel and leave rsyncd wide-open to localhost.

As for the "connection reset" errors I was getting the same thing until I
upgraded to the latest version of stunnel. I read a post on stunnel.mirt.net
about it. Are you sure you're using the latest version of stunnel?


-----Original Message-----
From: Gabe Martin-Dempesy [mailto:gabe at mudbugmedia.com] 
Sent: Tuesday, January 03, 2006 1:49 PM
To: stunnel-users at mirt.net
Subject: [stunnel-users] Connection reset by peer on same local network?

I'm attempting to setup an encrypted rsync to pull backups off of a file
server onto a safe backup machine.  To do this I'm using a combination of
stunnel and rsyncd (It needs to pull root-owned files, so -e ssh wouldn't
work unless I want to have a backup script  
remotely logging in as root!!)   For now the machines are both on the  
same local network,, but I'm have weird problems with stunnel
getting a 'connection reset by peer' after a couple minutes of the rsync,
halting the transfer prematurely.  Here's what I see in the logs:

Dec 29 10:19:21 backup stunnel[2568]: 8001 connected from
Dec 29 10:21:09 backup stunnel[2568]: SSL_write: Connection reset by peer
(104) Dec 29 10:21:09 backup stunnel[2568]: Connection reset: 192532 bytes
sent to SSL, 5920666 bytes sent to socket

Dec 29 10:20:00 proto stunnel[30434]: 973 connected from
Dec 29 10:20:00 proto rsyncd[1776]: rsync on xserve from localhost
Dec 29 10:21:49 proto stunnel[30434]: SSL socket closed with 16384
byte(s) in buffer
Dec 29 10:21:49 proto stunnel[30434]: Connection reset: 5953434 bytes sent
to SSL, 98416 bytes sent to socket Dec 29 16:21:49 proto rsyncd[1776]:
rsync: writefd_unbuffered failed to write 4096 bytes: phase "unknown":
Connection reset by peer Dec 29 16:21:49 proto rsyncd[1776]: rsync error:
error in rsync protocol data stream (code 12) at io.c(666)

Note that the client gets the 'connection reset by peer' a good 40 seconds
before the server notices the disconnect.

Here are the associated stunnel.conf's, which are pretty basic
cert = /etc/stunnel/backup.crt
key = /etc/stunnel/backup.key
setuid = stunnel
setgid = stunnel
pid = /var/run/stunnel/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
client = yes
accept = 8001
connect =

cert = /etc/stunnel/proto.crt
key = /etc/stunnel/proto.key
setuid = stunnel
setgid = stunnel
pid = /var/run/stunnel/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
accept = 973
connect =

Both are using:
stunnel 4.09 on i686-pc-linux-gnu PTHREAD+POLL+IPv6+LIBWRAP with OpenSSL
0.9.7e 25 Oct 2004 Global options
cert            = /etc/stunnel/stunnel.pem
ciphers         = ALL:!ADH:+RC4:@STRENGTH
debug           = 5
key             = /etc/stunnel/stunnel.pem
pid             = /var/lib/run/stunnel.pid
RNDbytes        = 64
RNDfile         = /dev/urandom
RNDoverwrite    = yes
session         = 300 seconds
verify          = none
Service-level options
TIMEOUTbusy     = 300 seconds
TIMEOUTclose    = 60 seconds
TIMEOUTconnect  = 10 seconds
TIMEOUTidle     = 43200 seconds

Both of these machines are Gentoo 2005.1, updated to current, using the
hardened 2.6 profile.  Neither of them use non-standard make flags.

Does anyone have some insight?  There shouldn't be any "peer" (besides
themselves) in the way between these two boxes to disconnect them.

stunnel-users mailing list
stunnel-users at mirt.net

More information about the stunnel-users mailing list