Check version via VPN (or proxy?)
I've used a VPN with Vuze (force=yes) for several months and two trackers show my ISP IP# instead of VPN IP# so i guess it's sent sometime somehow (though i didn't detect it in simple traffic captures of scrape requests).
I'm not sure on the implications of this for my privacy/anonymity but at least it defeats some purposes of using a VPN with BT.
What i've found in the SVN:
"(HttpURLConnection)url.openConnection();" needs to be replaced (to use NetworkManager i guess) in http://svn.vuze.com/public/client/trunk/azureus2/src/com/aelitis/azureus/core/versioncheck/VersionCheckClient.java , http://svn.vuze.com/public/client/trunk/azureus2/src/org/gudy/azureus2/core3/ipchecker/extipchecker/impl/ExternalIPCheckerServiceImpl.java and maybe other places..
Since i don't think i'll be able to implement this myself, until otherwise solved, i'll try to have a local HTTP proxy rewrite the "sourceipaddress" part in Vuze's reply from "http://version.vuze.com/version?" (found in VersionCheckClient.java above with VERSIONSERVERV4 in http://svn.vuze.com/public/client/trunk/azureus2/src/org/gudy/azureus2/core3/util/Constants.java)
Pardon if i'm bumping this old thread but i just wanted to inform, noticing version 5.7.1 release note to "Use bind IP for HTTP based version checks [Parg]", though a quick diff on some here previously and not so mentioned suspects shows nothing significant, as of the update from version 5.7 to 5.7.1, the TransferStatsView now shows my VPN IP# (and ASName).
AdminVuze (CEO / Founder, Vuze) commented
No problem, always good to have people look at code!
The speed manager works by (UDP) pinging other peers in the DHT - the UDP sockets should be bound to the selected interface correctly so the VPN speed/latency should be the one being measured.
Thank you for your reply.
I'm embarrassed to say that i once again have failed to even once confirm my network connection setting of my cell phone, thinking i was using a different ISP to verify that a tracker's web wasn't just repeating the browser's IP#, i was still on my own wireless net instead of the cellular IPS's *sigh*.
So, the lion's share of my concerns are invalid, good riddance.
I thank you especially for mentioning the local HTTP server and ClientIDManagerImpl as this still is a minor privacy/anonymity issue in that it exposes a VPN-user's IP# as using BT.
This is also a minor issue in that, apart from my own mindlessness and that the tracker's web printed my ISP IP# along with my Vuze client information, Vuze itself had me wondering with its incorrect `NetworkAdmin.getSingleton().getDefaultPublicAddress()` (and `speedManager.getASN()`) in http://svn.vuze.com/public/client/trunk/azureus2/src/org/gudy/azureus2/ui/swt/views/stats/TransferStatsView.java#. All of which was also how i found my initial post's code references.
Connecting to those two parts of this issue (the second with the `speedManager.getASN()`) is a question about whether the SpeedManager (auto-speed - i use the modern beta) is probing over the VPN or my ISP. As exposing IP# as using BT is actually no concern for me, i see this mostly as a question about the accuracy of the SpeedManager. Do you know how it does its connections?
Let me know if you think any of this should be moved/posted elsewhere. I wrote here thinking of a ticket-system.
Another thing, connected to not binding traffic to the VPN IP#, is that i discovered that (Apple's) Java's URLConnection doesn't seem to use the (Apple) OS's proxy settings (PAC at least).
This made my proxy-solution invalid as well. Oh well, at least my proxy got a few more rows and capabilities for next net-hack.
Excuse my tl;dr post - i post seldom but lengthy.
AdminVuze (CEO / Founder, Vuze) commented
If a tracker is showing your non-VPN IP address then something's up with either an announce or a scrape request - the version check stuff (while there might be a bind issue) wouldn't cause that.
If you have a bind IP then the way HTTP(S) connections are bound is somewhat complex because Java's built-in HTTP(S) URLConnection stuff doesn't support binding. When Vuze does is indirect via a local HTTP server in ClientIDManagerImpl that should enforce the binding.