Leaking IP when using VPN

[GoogleCodeExporter]

I have 2 complaints about this in the qbittorrent tracker.
One user is using this pretty nice tool to detect leaks: 
http://dev.cbcdn.com/ipmagnet/
The other user has a wireshark dump which is pretty close to mine.

Fist user: https://github.com/qbittorrent/qBittorrent/issues/1593
Second user: https://github.com/qbittorrent/qBittorrent/issues/378

I have only tested this in my home VPN since I don't have a VPN subscription. 
The VPN gives to one of machines the ip 10.8.0.6

What I observed: If tell qbt to use tun0, then the ipmagnet tool shows both my 
VPN's outgoing ip and the 10.8.0.6 ip. If I choose to just connect to any 
interface (0.0.0.0) it only shown the VPN's outgoing ip. However the first user 
reports that he gets both IPs leaked regardless of chosen interface.

My wireshark dump shows the request to the tracker has this 
".....&ipv4=10.8.0.6..." (the second user has ipv6 instead of ipv4)

Why libtorrent does this? I thought that this was controlled by announce_ip but 
if I set that I just get another field eg "....&ip=1.2.3.4&ipv4=10.8.0.6..." Is 
this a mistake?

PS: The second user states that you also encode wrongly the ipv6 address.

Original issue reported on code.google.com by hammered...@gmail.com on 22 Apr 2014 at 11:12

[GoogleCodeExporter]

To clarify some things:
I connect to any interface (0.0.0.0, :: ) while I am connected to the VPN and 
all traffic is routed through it.

Original comment by hammered...@gmail.com on 22 Apr 2014 at 11:14

[GoogleCodeExporter]

the additional arguments to the tracker is part of a tracker IPv6 extension. 
It's not really used by any tracker as far as I know and should probably be 
removed. fundamentally though, in order to not leak IPs and identity, there is 
an anonymous mode in the settings which disables these features. It only makes 
sense to enable this when using a proxy or a vpn.

Original comment by arvid.no...@gmail.com on 23 Apr 2014 at 5:41

[GoogleCodeExporter]

It seems that anonymous mode does way more than that. From the description if 
there is no proxy or i2p connections nothing goes through.
I enabled it on my system and nothing went through the VPN when qbt was 
launched. (I even left the capture filters empty).

Original comment by hammered...@gmail.com on 23 Apr 2014 at 10:37

[GoogleCodeExporter]

oh, right. I separated those into two settings in trunk. anonymous_mode and 
force_proxy.

for 0.16.x, maybe I should just remove the force_proxy aspect of it...

Original comment by arvid.no...@gmail.com on 23 Apr 2014 at 2:01

[GoogleCodeExporter]

http://wiki.hidemyass.com/Tutorials:Force_Vuze_to_only_load_Torrents_through_VPN

id like to see this feature added for both pptp and openvpn connections while 
your add it

torrenting through vpn is prefered over proxy since you can use a lot more 
fetures anonymously 

any idea how much id have to donate to get you to code such a feature

Original comment by zed...@gmail.com on 26 Apr 2014 at 8:13

[GoogleCodeExporter]

Could anybody try this patch against 0.16.16?

It removes the proxy requirement from anonymous mode, and makes it behave the 
same as in trunk.

http://dpaste.com/030M9AS/

If this looks good, I'll include it in 0.16.17

Original comment by arvid.no...@gmail.com on 7 May 2014 at 8:12

[GoogleCodeExporter]

Arvid, Unfortunately I do not have the means to test this patch. However I am 
very interested in this patch because I am using a SOCKS5 proxy with anonymous 
mode. I am hoping I can get sledgehammer of qBittorent to test it or produce a 
build that I can test.

It looks like the code is heading in the right direction for anonymous. If I am 
reading the code correctly, it seems you are now allowing DHT and listening 
sockets to remain open when running anonymous. Is this correct?

Original comment by gsoud...@cox.net on 12 Jun 2014 at 2:45

[GoogleCodeExporter]

The patch primarily makes it possible to use anonymous mode with a VPN. The 
current semantics of anonymous mode is to force all traffic to either be 
blocked or go via a proxy. The reason why this may be useful is because it 
seems very common for SOCKS proxies to not support UDP, and then all UDP 
traffic may leak, not being sent via the proxy.

Original comment by arvid.no...@gmail.com on 12 Jun 2014 at 5:26

[GoogleCodeExporter]

I finally did a build with that patch applied. I also decoupled the DHT 
settings and anonymous mode in the GUI.
Here is a test build: 
http://builds.shiki.hu/temp/qbittorrent_3.2.0alpha_20140612_anonymous_proxy_patc
h_setup.exe

Original comment by hammered...@gmail.com on 12 Jun 2014 at 5:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Arvid, I finally had a chance to test the alpha build from sledge with your 
patch. I have access to an external VPN. I tested first with anonymous mode 
without the VPN and results were good. Things got through just fine. Then I 
connected the VPN and things went through just fine. I also used 
http://dev.cbcdn.com/ipmagnet/ magnet to test for leaks. I could not get it to 
leak.

However I still am getting funny things happening with DHT and the listening 
sockets. 

The current regular release of qBittorrent 3.1.9.2 running Libtorrent: 
0.16.16+svn9872, does not contain this patch and DHT is disabled when you run 
anonymous via qB UI. So if I enable anonymous mode WITH or WITHOUT a VPN 
nothing get through. However if I backdoor the qB settings file and enable DHT, 
then torrents work with or without VPN by way of DHT peers. This contradicts 
the code which in this release should stop DHT. Another thing to note is that 
no trackers are contacted at all. This explains why nothing get through without 
DHT or trackers. I will also note that in this release anonymous is supposed to 
disable listening sockets so nothing should go out. However this is not true. 
With DHT enabled by backdoor, then I hand out pieces to others.

OK so with Sledges anonymous alpha build with your patch, things behave a bit 
differently. BTW I am not sure what SVN this alpha build uses. Anonymous 
without DHT works just fine. The reason is that the trackers are contacted and 
used. Obviously with DHT enabled it works as well. Also outgoing sockets work 
as well as I am sending others pieces.

I think the patch should be applied but I just wanted you to understand the 
reasons that anonymous was not working before. As for DHT I still see another 
place in session_impl.cpp. I am not sure if it ever gets called or why but I do 
not see why DHT should ever be disabled. As for the listening sockets, I feel 
they should also remain open. However I am not sure why the code before the 
patch was allowing them to remain open.

I think what we need here is a complete description of what anonymous mode 
really does. For example sledge has allowed local peer discovery with this 
alpha release but your code before and after the patch indicates it will be 
stopped. I am not sure if it should be allowed or not. Please give us all a 
description of what the code will do when running anonymous.

Lastly I would like to offer you access to my friends VPN and Socks5 proxy 
accounts so you can really test this stuff for yourself. He has agreed to this 
and we both want to be a team players. Please let me know if you are willing to 
do this. I can send you the info via email. Sorry to be so long winded and 
thanks for your support...

Original comment by gsoud...@cox.net on 8 Jul 2014 at 2:57

[GoogleCodeExporter]

> I will also note that in this release anonymous is supposed to disable 
listening sockets so nothing should go out. However this is not true. With DHT 
enabled by backdoor, then I hand out pieces to others.

Did you expect to not upload pieces to anyone?
The relevant question is; do  you accept incoming connections?

The first version of anonymous mode was primarily targeted to socks5 users. It 
was later split up in two separate settings, anonymous and force-proxy. In the 
latest release of 0.16.x I removed the force-proxy aspect of anonymous mode to 
make it work with VPNs, since that seems useful.

force-proxy means that all communication _must_ go through a proxy. If the 
proxy is down or doesn't support some feature, that feature is disabled. for 
instance, a proxy may not support incoming connections (which is pretty common 
I believe), in which case incoming connections won't be supported. Another 
common feature to not support correctly is UDP, in which case UDP trackers, DHT 
and uTP is disabled.

anonymous mode essentially is meant to be used by VPN users (and socks5 users). 
It makes sure the local IP is not included in any packets, it scrubs peer IDs 
to make tracking harder as well as a few other minor things. grep the source 
for anonymous mode for details.

In the 1.0 release, the settings are separated as force_proxy and 
anonymous_mode.

Original comment by ar...@bittorrent.com on 8 Jul 2014 at 7:54

[GoogleCodeExporter]

Hi Arvid, Thanks for your speedy response, patience and explanations. So is 
this patch or a variant of included in 1.0? I did SVN down all the source from 
the trunk and looked at all files pertaining to anonymous mode including 
documentation files. So please be patient with me.

Anonymous mode has been misunderstood in the qB world and has received bad 
press by many. Sledge must know what settings to disable in the qB GUI when 
anonymous is selected if any at all. He must also fix the definition of 
anonymous at GitHUb 
https://github.com/qbittorrent/qBittorrent/wiki/Anonymous-Mode

So let me see if I have this correct with some questions.

Anonymous mode now does not require a proxy. That was a needed change for VPN. 
Thanks!

This is the change to manual.rst in your patch yet I do not see this in 
manual.rst
in the trunk. Perhaps it has not been added yet or moved to another doc file. 
Is this statement correct for the 1.0 release for anonymous?

anonymous_mode defaults to false. When set to true, the client tries
to hide its identity to a certain degree. The peer-ID will no longer
include the client's fingerprint. The user-agent will be reset to an
empty string.  NAT-PMP, UPnP and local peer discovery are all turned off
when this setting is enabled.

I will add this and ask if this is also true for anonymous?

DHT will remain enabled if the user has enabled it
and listening sockets will remain open.

Now I would like to discuss force_proxy. First of all I do not think that qB 
has an option to force proxy. You can certainly set up a proxy and there is a 
check box under the proxy settings "Use proxy for peer connections". I do not 
think this equates to force_proxy true. Perhaps qB passes the force flag to 
your code automatically if the user sets up a proxy. Based on my testing and 
examining your code, I suspect that qB is never passing force_proxy true. Do 
you know if this is the case? I think Sledge might need to weigh in on this one.

So once your code is passed force_proxy true, then it looks like the following 
will occur. Is this correct?

NAT-PMP, UPnP, DHT and local peer discovery are all turned off. All listening 
sockets will also be closed.

Essentially all incoming connections will be blocked except through the proxy.

Thanks for your patience with me and for all your hard work on libtorrent...

Original comment by gsoud...@cox.net on 9 Jul 2014 at 4:47

[GoogleCodeExporter]

force_proxy is a new setting introduced in libtorrent 1.0.0. qbt 3.1.x doesn't 
support 1.0.0. qbt 3.2.0 supports 1.0.0 but I haven't introduced force_proxy (+ 
other new features) into the codebase. It basically uses the same features as 
0.16.x.

I suspect when anonymous mode/force_proxy are enabled libtorrent automatically 
disabled unneeded features(eg DHT).

However, it would be nice to know what is disabled with anonymous 
mode/force_proxy so I can have a consistent UI representation. This will 
prevent users complaining "DHT doesn't work even though I have it enabled".

Original comment by hammered...@gmail.com on 9 Jul 2014 at 5:43

[GoogleCodeExporter]

>I suspect when anonymous mode/force_proxy are enabled libtorrent automatically 
disabled unneeded features(eg DHT).

I suspect when anonymous mode/force_proxy are enabled libtorrent automatically 
disables unneeded features(eg DHT).

Original comment by hammered...@gmail.com on 9 Jul 2014 at 5:44

[GoogleCodeExporter]

Sledge, thanks for weighing in on this. I just checked and looks like Arvid 
split anonymous and force proxy into seperate settings on SVN r8031. This is 
what has been confusing me. I thought simply entering in a proxy in qB equated 
to force proxy in Arvid's code. It is now clear why my testing behaved the way 
it did because qB was never passing the force proxy flag. Since they are now 
separate settings, we need to know what is disabled for three different 
scenario's.

Anonymous
Force Proxy
Anonymous + Force Proxy

Then the question becomes if the user enters a proxy, do you automatically set 
the force proxy flag in qB to pass to libtorrent or do you have a separate 
checkbox to force the proxy. I suspect we want the latter. Lets see what Arvid 
suggests...

Original comment by gsoud...@cox.net on 9 Jul 2014 at 7:07

[GoogleCodeExporter]

I think this should be closed: 
https://github.com/qbittorrent/qBittorrent/issues/1894#issuecomment-53520223 
(linked comment confirming force_proxy working as expected)

Original comment by hammered...@gmail.com on 27 Aug 2014 at 7:39

[GoogleCodeExporter]

Original comment by arvid.no...@gmail.com on 27 Aug 2014 at 8:27

• Changed state: Fixed