Using BTSync Behind a Corporate Firewall

BitTorrent Sync is pretty neat. I have been using it ever since Scott recommended it in the quintesential backup thread of 2013. It even made it onto my big list of essential tools. It provides a nice alternative to cloud solutions such as Dropbox by enabling you to sync devices directly without storing your data on a centralized server owned by a third party.

One of the major issues I had with it was using it behind corporate firewalls. When you are on a network that only allows outbound communication on port 80 and 443, BTSync is completely useless. Unlike Dropbox or Google Drive which both have absolutely no issues synchronizing folders in such environment, the BTSync client simply does not work at all.

And yes, before you say anything, there are reasons to block outbound traffic on port 22. Firstly, if on average the number of users who need to ssh out of that location approaches zero, then leaving that port open simply increases the attack space for no reason. Secondly, even if users do need to ssh out, chances are they will be communicating with known servers. Why have a wide open port that can be used an abused, when you can control connections on IP and MAC address basis, and require audit trail, and change-of-permission request documentation when devs ask for more access.

The only outbound ports that are typically wide open are HTTP and HTTPS. Your local BOFHs can’t readily lock them down as tight as they would want to, unless they set up a proxy server. Fortunately, proxies break a lot of the modern, dynamic, internet based things so chances are you might not have one. And if you do not, then you can funnel your BTSync traffic through an SSH tunnel on a HTTP/HTTPS port.

To get this working working you will need a few things:

A functional shell with ssh on your work machine

An internet accessible remote machine running sshd server

Recent BTSync client (obviously)

If outbound communications on port 22 are open at your location, any server to which you have shell access will do. If you only can get out on ports 80 and 443, you will need to configure said server to run SSH daemon on one of these ports. This unfortunately requires root access.

You set this up by editing /etc/ssh/sshd_config. Search for the word “Port” and simply add another entry below, like this:

# What ports, IPs and protocols we listen for
Port 22
Port 443

# What ports, IPs and protocols we listen for
Port 22
Port 443

Then restart ssh server:

sudo service ssh restart

sudo service ssh restart

Make sure you can ssh into it from behind the firewall. If your port 22 is closed, you can specify the alternate port on the command line like this:

ssh-p443 you@your.host.net

ssh -p 443 you@your.host.net

If that works, you will now be able to create an SSH tunnel that will act as a SOCKS proxy. On the machine where you want to run the BTSync client, do the following:

ssh-D9988 you@your.host.net -N-p443

ssh -D 9988 you@your.host.net -N -p 443

This will create a SOCKS proxy tunnel running on the local machine on port 9988. You don’t have to use that port number. Feel free to use any other port, as long as it is not taken by anything else. I recommend making a script with this command and saving it somewhere in your path, because you will have to run it whenever you want to enable syncing.

Finally, once you have the tunnel running open the BTSync client, go to Preferences and open up the Advanced tab. Check the “Use proxy server” box, type in the localhost ip and the port number you picked (in my case 9988). Use the default SOCKS4 proxy type:

BtSync Proxy Setup

Save the settings, then pause and restart syncing to make them take effect. Once you do this, you should see your folders syncing up as they should. Of course the sync will stop when the tunnel is closed, but it is better than nothing.

8 Responses to Using BTSync Behind a Corporate Firewall

Nice! Except I moved on from Btsync to Syncthing almost a year ago. Btsync’s recent move to a “limited-features for the free version” model and their continued adherence to closed-source have driven a lot of people away. Syncthing still isn’t quite ready for the “everyman” point-and-click solution but it’s getting pretty close. I highly recommend giving it a spin!

Your SSH tunnel approach would probably work fine with Syncthing as well (it uses port 22000 by default, and 21025 for a global discovery server). I typically just run behind a VPN outside my home network and that works fine (only if you can get the VPN ports opened).

i’ve been using seafile for about a year now. Yes it needs having a server, but since i’d run one anyways that isn’t that big of a difference to me.
Seafile is accessible by http and i can point my parents/friends to an URL they can use to get files i want to share.

i’ve been thinking about setting up a SOCKS-tunnel for different uses, but since i’m until now able to do most things via smartphone (that in doubt uses it’s own internet connection rather than corporate wlan) or browser.
But having SSH respond on 443 is a nice idea. I’m prefering typical mail ports like 25, 110, 465 or 587 or 995 since those should be open too and i’d not need hacks to support https/ssh on the same port (i’ve seen an article on that some time ago).

Oh, nice. I like that it’s open source. I don’t like that it does not seem to have an iOS client but I guess that’s not surprising considering Apple developer fees don’t necessarily mesh with free software ideals.

Seafile actually looks really neat. Thanks for the link. How resource intensive is the server? Is this something you could run from a Raspbery or a PogoPlug at an acceptable speed?

I dont really know, since i run it on my x86-server. But there is a RPi-Version on Seafile.org and it tends to get better performance than that crappy Owncloud-thing (and i know some people use that on RPi)

I never noticed any performance-problems on my system, but when I just looked it used a bit over 300MB RAM, what might be a bit much for RPi.

@ Scott Hansen:
Oh, nice. I like that it’s open source. I don’t like that it does not seem to have an iOS client but I guess that’s not surprising considering Apple developer fees don’t necessarily mesh with free software ideals.

An iOS client is in the works. The beauty of it is that the open API and the thorougly documented Block Exchange Protocol are enabling people to work on multiple clients and even different server implementations. It also just recently got re-licensed (MPLv2 I think) for app-store compatibility.

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page.Click here for instructions on how to enable JavaScript in your browser.