# rsyncd listening on both IPv4 & IPv6 address?



## Bucky (Aug 19, 2015)

Looks like rsyncd can be set up to listen to either an IPv4 or an IPv6 address but not both at the same time.

"hosts allow" can be set to both IPv4 & IPv6 at the same time it seems.  But when I try to do that with "address = ", it fails.

Anyone know a way around this?


----------



## Jeckt (Aug 19, 2015)

Are you sure rsync can't do both at the same time? If the server address isn't explicitly set either way in rsync.conf, It should bind to "*:873" . Check `sockstat -46l | grep rsync`


----------



## kpa (Aug 19, 2015)

Jeckt said:


> Are you sure rsync can't do both at the same time? If the server address isn't explicitly set either way in rsync.conf, It should bind to "*:873" . Check `sockstat -46l | grep rsync`



Done more simply by:

`sockstat -l46 -p 873`


----------



## Bucky (Aug 19, 2015)

Okay, I removed the "address =" line, restarted and sure enough, rsyncd binds to EVERY IPv4 and IPv6 address on every NIC.

Maybe I'm being overly paranoid about this.  I run a bunch of jails and wanted to limit the addresses that rsyncd binds to by not having it bind to the jail IPs or the internet-facing NIC.  Should I just use the "hosts allow =" directive and pf firewall to limit the effects of rsyncd binding to everything?  A jail tutorial I read a year ago said it was essential that none of the host's daemons bind to jail addresses by default.

I need to run the rsyncd outside of a jail (I think) because it needs access to my NAS system on the same box.  Yep, just tried it and inside the jail cannot see my zfs storage array.

Thoughts?

Thanks.


----------



## Jeckt (Aug 20, 2015)

I think you're right not wanting it binding on all interfaces in that case. However this sounds like you're in control of both sides of the connection, so I'm not sure why you'd need to bind to both. Is there a reason incoming connections can't all reach it via ipv4 or ipv6?


----------



## Bucky (Aug 20, 2015)

Not sure I understand what you mean.  By default, rsyncd apparently binds to all available addresses (and therefore all available NICs) - that can only be controlled by setting the "address =" directive in rsync.conf and then it will bind only to that specified address (on that particular NIC).  With the "address=" directive, that address can be either an Ipv4 or an IPv6 but not both.

"in control of both sides of the connection..."?  My box (like all server/routers?) has two NICs.  One faces the internet (cable modem box) and the other faces my LAN.  The pf firewall allows me to control connections to and through both NICs.  Say I run 10 jails which have their IPs (4s & 6s) attached to the LAN NIC.  Running rsyncd without the "address=" directive attaches rsyncd to every address (both IPv4 & IPv6) on every NIC, including all the jail IPs.

Does that matter?  I can control who connects to rsyncd with the "hosts allow=" directive *and* the pf firewall.

Isn't that good enough?

The issue is the jails and their IPs.  I don't see why the tutorial said to never allow anything to attach to jail IPs just willy nilly.  One of the processes I run is Samba outside a jail, since it needs access to my zfs storage array to serve up media on the LAN.  There is zero way to control the smbd(8) and nmbd(8) Samba daemons - they connect to all available IPv4 addresses on the box, including all the jails and I've never had trouble with Samba.  Another jail tutorial said not to run the base ntpd(8) daemon for the same reason (net/openntpd is better behaved and actually easier to setup and use).  The base ntpd(8) attaches to all addresses on the box.

Thoughts?


----------



## junovitch@ (Aug 20, 2015)

Bucky said:


> ...
> Maybe I'm being overly paranoid about this.
> ...



If this is the case than the simplest recommendation is you would be far better off just using key based SSH for all rsync rather than rsyncd.



Bucky said:


> ...
> There is zero way to control the smbd(8) and nmbd(8) Samba daemons - they connect to all available IPv4 addresses on the box, including all the jails and I've never had trouble with Samba.  ...


There is a very limited amount of what you can do in /usr/local/etc/smb4.conf.  It's not completely clean but at least it's something.  This would be best as a topic of a whole other thread however.


```
[global]
  interfaces = 10.100.102.2/32 127.0.0.1/32
  bind interfaces only = yes
```


----------



## Bucky (Aug 20, 2015)

The key based ssh is a good suggestion for rsync.

I was mistaken about Samba, the smbd(8) can be instructed to bind to specific addresses, it is the nmbd(8) that binds to everything:

`sockstat -4`

```
root  smbd  870  32 tcp4  10.0.0.1:445  *:*
root  smbd  870  33 tcp4  10.0.0.1:139  *:*
root  nmbd  867  12 udp4  *:137  *:*
root  nmbd  867  13 udp4  *:138  *:*
```


----------



## Jeckt (Aug 20, 2015)

> "in control of both sides of the connection..."?  My box (like all server/routers?) has two NICs.



Yes. My understanding of your situation is that 1) do not want it bound to the public IP address. 2) do not want it bound to jailed IP addresses.

This leaves the internal interface which talks via IPv4 or IPv6 or both. However you control your internal network, so you already know how your machines will connect. In this case I would just bind rsyncd to the internal interface address (either the IPv4 or IPv6 one). If you're running a public Rsync server, that's another story.

Limiting via PF is mostly a confidence based thing, but I'd say that would be fine. I would use access controls in the config file regardless. SSH is a good option if you're okay with accounts on the server, and easiest to set up. Although it's kind of a pain, binding Rsync to the loopback then using Stunnel might give you additional flexibility this way.

nmbd(8) isn't required for Samba to run and share files, however the "browsing" connectivity won't work if disabled. I believe you also need to set smbports = 445 in smb.conf, and nmbd_enable="NO" in rc.conf. I believe this leads you to the same point as binding to one address in rsyncd though.

The base ntpd(8) is pretty obnoxious the way it binds to all interfaces, so I avoid it in situations like yours where there are a lot of addresses / interfaces involved, and use OpenNTPD instead. For whatever reason this doesn't seem to set the system clock on the machine which has caused me issues, but was solved with using ntpdate="YES" in rc.conf.


----------



## Bucky (Aug 20, 2015)

Lots of good info in there.  I'll need to copy and study it.  Thanks!


----------

