ankoh

Well that completely depends on what exactly is blocked in your network. :-) If you're facing a restrictive firewall that does layer 7 packet inspection then BitTorrent Sync could definitely not work. My student housing is behind such a firewall and there I can only sync with my servers via OpenVPN. Just try it out.

Short answer: Don't do it. I've spent quite some time trying to get BitTorrent Sync running through Docker but your problem will be the UDP Multicast on port 3000 that BitTorrent Sync uses for LAN Discovery and the initial Handshake. If you run < 2.0 BTSync (or only 1.4 Folders with separate swarms) you won't have many problems as you can just use the folder secrets to manually link the hosts but if you want to use a single 2.0 swarm you'll run into many problems. If you want to give it a shot you should try to write the initial BTSync config with a completely exposed Docker container (--net host) that can listen to the UDP Multicast and then run a non-exposed container with a shared volume afterwards. Keep in mind that you then need to manually enter the docker host to the "Use predefines hosts" list of your client as you won't find this daemon through LAN discovery. (Not supported on phones yet) You could try to get the Multicast working with Pipework (https://github.com/jpetazzo/pipework) but I decided to stick with the non-docker daemons on my hosts. (If you try out pipework I would be very interested in the outcome!) Here is my Dockerfile that I used to run BTSync with SSL: https://github.com/ankoh/docker-btsync

Great! Thank you.

Hallo, as I haven't found an answer to this question I'll just try it here. My assumption is that the "Sync with..." status of peers is chaining such that peers appear as synced (and online) even though this information is only available through one of the peers. Can somebody confirm that? Let me explain my setup. I am using BitTorrent Sync without tracker and relay server. Those are disabled for every folder on every machine and instead predefined hosts are used to talk to the other peers. I am using two 24/7 linux servers behind a NAT-router without upnp where only one of the servers has the BitTorrent Sync port forwarded through the router firewall. Currently me and my MacBook are in a totally different city. I resolve the mentioned NAT router through DynDns and only added the forwarded port to the predefined host list of the MacBook client. Interestingly I can see 2 relays synced (and online) even though my MacBook should only be able to talk with 1. I'd love to see this chaining feature confirmed. Or is there something I am missing? -- ankoh

Hallo, today I noticed a (for me) very dangerous problem with sync. If you use BitTorrent Sync through a fresh OpenVPN connection, the peer will be discovered through a relay server instead of the broadcast through TUN! Let me explain my situation: I am a student and my student housing is behind a very restrictive firewall that blocks my IP in seconds when I start using peer-2-peer protocols. As I love the idea of BitTorrent Sync I use one of my servers in the Google Compute Engine to host a btsync daemon besides an OpenVPN server that lets me bypass this firewall. The setup is actually working pretty well. As I don't want to route all my traffic through the VPN I am blocking the outgoing bittorrent tracker and sync packets at my local NAT-Router and switch on the VPN from time to time to sync with the server. And here comes the problem: Initially the OpenVPN is switched off and the server peer is offline. When I establish the VPN connection it takes a few seconds and the server peer is detected and sync works fine. Unfortunately if the server checked "Use relay server when required", this new connection is going through a relay server instead of the direct connection! And it remains that way!! If you instead uncheck "Use relay server when required" the connection is also established but NOT through the relay server. I realised that something was wrong when I observed the outgoing traffic of my server. Of course that's not really a widespread setup but I think it points to a little (not so obvious) problem with the peer discovery. Of course this is hardly enough information to check if that is really a bug, but if you want to investigate this I could provide you with additional setup info. -- Andre