Define Ip4 (And Ip6) Ranges For Predefined Hosts

[vw183]

User story:

"As an administrator I want to set up subnets where clients that have access to the subnet are able to sync in this subnet but I don't want to use broadcasting due to security and traffic reasons."

 

Background:

In local network use it can make sense to restrict syncing only in a dedicated sub-net (VLAN or VLAN branch) where a DHCP server is assigning IPs to machines joining this network. In this case, it can be cumbersome to define 254 adresses (or even more) to enalbe syncing.

[dms2013]

This sounds more like missing firewall rules.

[vw183]

Yes, you could also work with firewall rules but never the less might it me more effective to restrict on the tools side than working only on the network side. Also, it is handy if you do not have to type in so many numbers.

[Moe]

I think you haven't sniffed in a test environment how the predefined hosts work right?

A predef. host will give BitTorrent Sync a hint where to find it's counterpart but that won't make it stop to just look for a specific list of clients via broadcasts.

Your kind of using that feature "wrong".

 

I would really really think about using a Firewall instead - I am not talking about Windows Firewall but an appliance like the an ASA or so.. The rule would be so simple and clear and could not be disabled by normal users. In the BitTorrent Sync GUI users could just enter another client to the predifined hosts or delete one of them.

[vw183]

Hi Moe,

no I have not sniffed. Thanks for that hint - I did not know that it will still broadcast. So then basically there is no difference between "know host list" and "search LAN"?

[Moe]

Maybe one of the Team members can explain how it really works. Would be interesting to know.

[goli]

Hey there.

 

I doubt those features have changed from 1.4 to 2 significantly.

 

The "search on LAN" is nice because it broadcasts. So every host being reachable through broadcasts is covered. There are two drawbacks.

The first one is: That only covers the current LAN segment. I could e.g. create one IP segment per team and have a couple of teams. They are free to communicate whatever they want, so firewall rules are *not* what I want to set up.

The second one is: Whenever I sign in to a public WiFi like Starbucks or any hotel, I need to disable the "search on LAN" thing since there is a chance the firwall just blacklists me because of creating torrent like traffic.

 

The "know hosts" list is completely different. Here I put single host names in that are *not* reachable through broadcasts. I run a couple of VPS in different data centers. I don't want them to be on DHL tables since that's just not necessary. I know their static IPs and they never change.

 

I really doubt one can combine those features. Broadcasts are meant to stop on network segment borders, and this is for a reason. Adding "foreign LAN segments" to the broadcast thingy would mean dropping the broadcast feature and use a "brute force IP range" instead. That's clearly not what I want.

 

 

Instead, you could go for something like a "broadcast relay". That's something your router (or any other host having different legs in different network segments) could do. If you look for regular UPNP (which is used for DLNA, for example), you use tools like "igmpproxy" which does that job. I haven't digged into the sync broadcast. There are chances protocol changes to the broadcast mechanism can make it IGMP compliant so igmpproxy works with no changes.

 

Might this be worth a feature request? Adjusting the broadcast thingy to default IGMP?

 

Regards,

Stephan.

[vw183]

Hi Goli,

 

again: I have not tested what kind of traffic "search on LAN" or "known hosts" produce but I have a sense of understanding it - and that sense most likely is wrong.

 

Note to BT-Team: as you see it would make sense to give a better explanation how both features work precisely since you are aiming for a commercial (datacenter?) use.

[RomanZ]

@all

 

If one specifies a peer in "Predefined host" - Sync is going to behave like it knows there is a peer for sure and attempt to connect there over unicast TCP / send UDP datagrams.

 

The "Search LAN" works differently (and it is NOT using broadcasts) - Sync will:

a ) Subscribe to multicast group 239.192.0.0 to receive notifications from other Sync instances

b ) Send multicast packets to group 239.192.0.0 over port 3838 for around 10 seconds when Sync starts up or detects some network interfaces changes - to inform other Sync instances about its presence.

 

Multicast packet contains no private info - it delivers peer ID, share IDs and the port to connect to. Also, all multicast packets have default TTL of "3", so it depends on company routers and appliances configuration on how far multicast traffic will propagate (usually, "1" means - restrict to local subnet, <32 means - restrict to same organization / site).

 

@vw183

For your case I see 2 optimal solutions

1) Set up own tracker server in your LAN (not yet supported, although we'd like to implement it in future).

2) Enable "Search in LAN", make sure that routers between networks will drop multicast packets with TTL<4. If you've got "multicast-aware" routers, they won't generate too much traffic.