The binding is still leaking

[LuvVuze]

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.

[parg]

Silly question but do you have the 'enforce IP bindings even when the interface is not available' option checked?

[LuvVuze]

Definitely checked.  Here is a screen shot showing my VPN disconnected, eth1 not active (VPN), and still downloading the torrent.

[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:

1. Actual torrent file data exchanges: This seems to only happen when I2P is enabled.
   
2. 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.
   
3. 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
   
4. 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 5.7.2.1_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.

[soulkris]

I finished developing a forcevpn.sh script to overcome these leaks.
Basically, this forcevpn script:

• puts the Vuze process in a Linux cgroup in order to mark packets originating from Vuze
  
• creates a custom routing table for this cgroup with only a tun0 route
  
• creates a secondary blackhole routing table for the cgroup should tun0 be down and the first routing table fails
  

ONLY for LINUX

Script auto sudo and installs cgroup dependencies.

Code:

wget https://gist.githubusercontent.com/kriswebdev/c19e103bd69c994a1c16ced004908c76/raw/685a667fe6f69e08dc26103de255f7270e9c721c/forcevpn.sh
sudo chmod +x forcevpn.sh
./forcevpn.sh --help
./forcevpn.sh -b vuze
# or
./forcevpn.sh -b azureus

[parg]

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?