Binding to a local IP is still leaking. My VPN did not lauch at startup as it usually does. Not realizing it, I started Vuze. Four different torrents were downloading at 30-40 kBs. Checked advanced connections and the program was running off my normal IP. Obviously, it had not bound to my VPN on ETH04 since it was not started at startup. Was running off my installed network card. My normal speeds are > 3.0 MBS so there was SOME attenuation, but still leaking.
06-18-2016, 03:37 AM (This post was last modified: 06-18-2016, 04:41 AM by soulkris.)
I confirm Vuze is leaking a lot through Wireshark capture, in two cases:
When Vuze is launched and the VPN is not yet up
When Vuze is running and the VPN goes down
Vuze prevents actual torrent file data exchanges when the VPN is down but there are several types of leaks when the VPN is down:
Actual torrent file data exchanges: This seems to only happen when I2P is enabled.
UPnP leak: Not tested, however it has been reported that UPnP server is leaking: it opens ports on the local router, making the Vuze client visible from the Internet. If that's really the case, that's at best a documentation issue (VPN setup wiki page) or a vulnerability that needs to be fixed in the UpnP plugin when VPN is configured to force IP bindings.
DNS leak: There's a lot of DNS requests leaking : version.vuze.com, plugins.vuze.com, vrpc.vuze.com and most importantly tracker DNS resolution and reverse DNS resolution of the swarm clients
Tracker connection: Connection to the trackers are not prevented! That's a major leak since the stream knows your real IP. Wireshark traces show actual connections initiated from the Vuze client OUTBOUND to clients of the swarm, with small UDP packets.
Tested on Ubuntu 16 with network-manager-openvpn and latest Vuze Beta 18.104.22.168_B11, force-binded to tun0.
OpenVPN is configured with the pushed config of the VPN providers (that often includes a redirect-gateway of the "real interface" to tun0 when the VPN is up).
At this time, it is extremely unsafe to use Vuze with a VPN without a killswitch, process-based firewall rules or process-based routing table.
I2P doesn't know anything about the bindings set in Vuze which is why you see activity - however as it is I2P traffic it doesn't leak anything.
UPnP is, as you say, a possible issue in that it opens ports although of course Vuze shouldn't accept any incoming connections if the bindings are enforced.
DNS leaks are indeed possible - Vuze does attempt to install its own DNS provider in the JVM to cover some other resolution issues involving the use of SOCKS, it may be possible to do something here for the disconnected VPN case, not sure
Tracker leaks shouldn't be happening - are these UDP trackers? Or HTTPS? In (4) you also talk about UDP packets being sent to swarm peers - is this separate from the tracker issue?