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

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
[home]
uid = root
gid = root
path = /home
comment = home directory.
hosts allow = 127.0.0.1
read only = no
ignore nonreadable = no
refuse options = checksum
dont compress = *

If you notice the "hosts allow" directive only allows access from
localhost(127.0.0.1). 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?

Jeremy

-----Original Message-----
From: Gabe Martin-Dempesy [mailto:gabe@mudbugmedia.com]
Sent: Tuesday, January 03, 2006 1:49 PM
To: stunnel-users@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, 10.10.10.0/24, 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:

Client:
Dec 29 10:19:21 backup stunnel[2568]: 8001 connected from
127.0.0.1:39215
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


Server:
Dec 29 10:20:00 proto stunnel[30434]: 973 connected from
10.10.10.20:54054
Dec 29 10:20:00 proto rsyncd[1776]: rsync on xserve from localhost
(127.0.0.1)
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
Client:
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
[8001]
accept = 8001
connect = 10.10.10.15:973


Server:
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
[973]
accept = 973
connect = 127.0.0.1:rsync


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@mirt.net
http://stunnel.mirt.net/mailman/listinfo/stunnel-users
_______________________________________________
stunnel-users mailing list
stunnel-users@mirt.net
http://stunnel.mirt.net/mailman/listinfo/stunnel-users