How to tunnel BitTorrent traffic with SSH and Azureus

Recently I spent a week of vacation in a house where the Interconnection was routed via an Ethernet router I could not change the configuration of. This was a bit of a problem for me as BitTorrent really only runs fast if both remote and local connections can be made from the BitTorrent client.

Traditionally there are a number of options for making it possible to establish a remote connection. Either a specific port is configured to be opened and forward to a host on the inside LAN in the NAT device connecting the BT client to the Internet. Sometimes the NAT device supports upnp in which case the BT client can request via the upnp protocol that a port be opened and forwarded to the inside BT client.

Sometimes however neither of these options are available and so there is no means of getting a remote BT client connect to the local BT client. Obviously, two devices behind a NAT device with no forwarded ports cannot connect to each other and so cannot share traffic. In effect, this means that a BT client behind a NAT device where no port forwarding has been setup cannot accept any incoming connections. Conversely, a BT client on a public IP address or behind a NAT device with a port forwarding configuration can accept incoming connections.

My personal experience (and that of others) is that there is significant difference between the download speed and connection quality of running BitTorrent in these two different modes. A BT client running in Local mode only will run slower than a device that can do both Local and Remote mode.

Anyhow, back to my story about my vacation where no port forwarding could be setup.

So I tried to figure out a way to build a tunnel setup to solve my problem. Needless to say a tunnel setup requires that you have 2 endpoints, and for the purposes of our discussions, one of the endpoints must be on a public IP address (non RFC1918) or have port forwarding setup to accommodate Remote connections.

Azureus is a very flexible BT client that runs on many operating system include Mac OS X which I use. In the following I will walk through how Azureus can be configured to tunnel BitTorrent traffic over SSH to a server located on the public Internet.

In effect how to turn the yellow face in Azureus green…

For this we will use two features of SSH:

- The SOCKS proxy function

- The Remote port forwarding feature

The SSH server on the public Internet where the BitTorrent traffic is broken out we will call “the server”.

The laptop on the restricted LAN running the BitTorrent client and the SSH client we will call “the client”.

Firstly on the server we must configure the ssh daemon to accept and forward incoming connections from other hosts than localhosts. This is done by setting the GatewayPorts configuration directive to “yes”. The server in my case runs FreeBSD 5.4, so I included the line:

GatewayPorts yes

In the file /etc/ssh/sshd_config

After a configuration change has taken place the sshd will need to be restarted. The can be done by running “killall –HUP sshd” as root.

After has been done we can now setup the tunnel on the client by running the command in a shell or “Terminal” window as root:

ssh -2 -R 7654:localhost:7654 -A -D 1080 root@theserver.org

Leave this window open for as long as your session lasts.

The various flags are described in the OpenSSH man page as:

-2 Forces ssh to try protocol version 2 only.

-R port:host:hostport

Specifies that the given port on the remote (server) host is to

be forwarded to the given host and port on the local side. This

works by allocating a socket to listen to port on the remote

side, and whenever a connection is made to this port, the connec-

tion is forwarded over the secure channel, and a connection is

made to host port hostport from the local machine. Port forward-

ings can also be specified in the configuration file. Privileged

ports can be forwarded only when logging in as root on the remote

machine. IPv6 addresses can be specified with an alternative

syntax: port/host/hostport.

-A Enables forwarding of the authentication agent connection. This

can also be specified on a per-host basis in a configuration

file.

Agent forwarding should be enabled with caution. Users with the

ability to bypass file permissions on the remote host (for the

agent's Unix-domain socket) can access the local agent through

the forwarded connection. An attacker cannot obtain key material

from the agent, however they can perform operations on the keys

that enable them to authenticate using the identities loaded into

the agent.

-D port

Specifies a local ``dynamic'' application-level port forwarding.

This works by allocating a socket to listen to port on the local

side, and whenever a connection is made to this port, the connec-

tion is forwarded over the secure channel, and the application

protocol is then used to determine where to connect to from the

remote machine. Currently the SOCKS4 and SOCKS5 protocols are

supported, and ssh will act as a SOCKS server. Only root can

forward privileged ports. Dynamic port forwardings can also be

specified in the configuration file.

The only thing you need to change from the ssh command line above is the “7654” port number to whatever you prefer. I would recommend something in the 1024 -> 65536 range. Also “theserver.org” you should change to whatever you SSH server is called.

This command will do a number of things:

a) Open port 1080 on the client and tunnel traffic from there to a SOCKS proxy server on the server

b) Setup a server socket on the server listening on port 7654 and forward any connection from here back to the same port on the client.

We can now configure Azureus to take advantage of this setup.

Under Preferences (Options) -> Connection:

Set “Incoming TCP listen port” to “7654”

Check: “Enable proxying of tracker communications”

Check: “I have a SOCKS proxy”

Set: “Host” to “127.0.0.1”

Set: “Port” to “1080”

Check: “Enable proxying of peer communications”

Check: “Inform tracker of limitation”

Set: “SOCKS version” to “V5”

Check: “Use same proxy settings for tracker and peer communications proxy”

Under Preferences (Options) -> Transfer:

Check: “Allow multiple connections from the same IP”

Remember to click “Save”.

Now restart Azureus and see the green man smile.

/Lasse L. Johnsen

/FreeBSDCluster.org

/lasse@freebsdcluster.org