Vuze Plugin: VPN Helper for Private Internet Access

I've created a helper plugin for Vuze.  http://www.vuze.com/plugins/details/vpnpia

As the linked page says, so far, it:

• Ensures Vuze is bound to Private Internet Access' VPN.
• Ensures Port Forwarding, allowing incoming connections.
• Ensures various Vuze settings are correct (Binding, Enforced Binding, disabling of UPnP, NAT-PMP, etc)

I've tested it on Mac, Windows, Ubuntu and Fedora.  For Mac & Windows, I use the PIA Manager to connect to the VPN.  For Ubuntu and Fedora, I used the OpenVPN HowTo (I haven't tried the beta PIA Manager for linux)

Please let me know if you find it useful, know of ways to make it more useful, or have any other questions about it.  Source SVN is at http://svn.vuze.com/public/plugins/azVPN_PIA/
«1

Comments

  • Hi Tux !

    Thanks for your effort, i use linux mint and would like to install your plugin but i am a bit worried about security if i install a plugin from an unknown source.
    How can i be confident that this plugin is nothing more than what it claims to be ?
  • jimmy808,

    You can be as confident in the plugin as you are with Vuze. It's hardly from an unknown source, since I've been developing for Azureus/Vuze since 2004. :)

    If you are a developer, you can look at the code for yourself, and even create your own .jar file. I linked the source in my OP; all of the actual is deeper, at http://svn.vuze.com/public/plugins/azVPN_PIA/src/com/vuze/plugin/azVPN_PIA/

    Please note that most linux distros (including Mint, I believe) ship with a very old version of Azureus (4.3.0.6).  This plugin works with 5.6.1.0 and higher, which is available as a tar.bz2 from our main site (http://www.vuze.com/download ) or SF (https://sourceforge.net/projects/azureus/files/vuze/ )
  • Great idea, thank you!

    Does it work with Win XP?
  • It works. Took me some time to figure it out. If I can do this, ANYONE can! Thanks to all. Did encounter a nasty cloud_backup_setup.exe (Suspicious.Cloud.9) Trojan-Virus that was confirmed by Norton while quarantined. The Malware was in the sourceforge download. Once cleaned however, the vuse plugin works great. I'm not complaining, but I thought it might be good for everyone to know.
  • Hi Tux !

    Thank you for your  answer.
    I am definitely going to try your plugin.
    I wish you a lot of success with it.

    Jimmy
  • VPNTester,

    Yes, it works on Windows XP.  I just tested it, and the only quirk I had was in the status display -- the font on Windows XP does shows square boxes instead of Checkmarks or X's.  However, the sidebar still shows the correct "OK", "??", or "BAD" state and functionality still works.
  • p5531618,

    Yeah, Sourceforge has been in the news lately for wrapping installers with their offers. :(  Probably stating the obvious, but always take extra time when going through the installer to make sure you decline or say no to any stuff you don't want.

    Glad you got it working!
  • edited July 2015


  • Hi TuxPaper,

    Sorry for the stuff up with my previous posts.

    I'm using mac and in using VPN helper for PIA I
    still get "PRC result error port forwarding not available in this
    region" and "Could not get forwarding report. Ensure PIA manager is
    properly set, or set user/pass in plugin config."

    Im still able to download files but does that mean my ip is not protected?

    Thanks for your help!
  • glassi,

    You are still protected and using the VPN.  

    You have PIA set to a region that doesn't support port forwarding.  If you switch to a gateway listed at https://www.privateinternetaccess.com/pages/client-support/#portforward , the warning should go away.  Without port forwarding, only you can connect to peers -- peers can not connect to you.  With port forwarding, peers will be able to connect to you (using your VPN IP address).  So, port forwarding will usually get you more peers and often result in faster downloads.
  • Thanks so much for the quick reply TuxPaper, that worked!
  • VPNTester,

    Yes, it works on Windows XP.  I just tested it, and the only quirk I had was in the status display -- the font on Windows XP does shows square boxes instead of Checkmarks or X's.  However, the sidebar still shows the correct "OK", "??", or "BAD" state and functionality still works.
    Thank you for the info! :-)
  • edited August 2015
    TuxPaper, thank you so much for making this excellent plugin!!!
    Working perfectly on Yosemite 10.10.4 and the latest Vuze!
    You really have taken all the hard work out of Port Forwarding! WOW!!!!

  • edited August 2015
    Hi Tux,
    It says VPN OK, but I would like to understand why I get some different messages then you do.
    Why do I get message  "Non-Vuze probably routing through XXX. Same as Vuze." , but you don't?
    Also, I get comment "Port returned from RPC is XXX" and you get, "Port stored in PIA manager config is XXX"

    Thanks for any insights you can share,

    Michael

    Your Comments:
    VPN OK!
    ✔ Vuze UDP is bound to /10.XXXX aka ethX (TAP - Win32 Adapter V9)
    ✔ Port stored in PIA Manager config is XXXX


    My Comments:
    VPN OK!
    ✔ Vuze UDP is bound to /10.XXXXX aka etXX (TAP-Win32 Adapter V9)
    ✔ Non-Vuze probably routing through /10.XXXXX aka ethX (TAP-Win32 Adapter V9). Same as Vuze.
    ✔ Port returned from RPC is 4XXXX.

  • Mycole98,

    The "Non-Vuze" line was added after the screenshot.  It should be normally what's displayed for you.  The line becomes a warning if non-vuze is not routing through the same VPN.

    The port detection depends on whether you entered your username/password.  If you don't enter credentials, it'll scan the PIA Manager's config for the port number.  If you do enter credentials, it will call PIA's RPC directly.  The latter is more resilient (and will grab a port even if the PIA Manager has the option turned off).  For people who don't want to enter their creds into Vuze, the former seems to always work (until PIA changes their manager's config format)
  • I'm new to Vuze, after uTorrent, and switched mainly for the ability to force the connection to stick to the VPN. I do get downloads, but I've noticed the yellow smiley indicating things aren't going thru as they should. Since the Vuze installation seems to have automatically installed the PIA plugin, I need some clarification about using it and/or getting to the green smiley
      First, is it correct that this plugin requires connecting to a PIA server that allows port forwarding (which, according to the PIA client support page, means there is no server in the US that this will work with?)
     Second, if the first is correct, then does this mean there's no way to set up Vuze to ever get the full green smiley, since incoming ports can't be set to forward with US servers specifically because PIA blocks them?

    In trying to work with this at the moment, I get Errors that the Vuze UDP port is bound to an IP in the range 10.171.xxx.xxx. But the PIA connection shows my IP to be in whatever range the server I'm connected to is in (which is not 10.171.x.x. So I'm not sure how or why the UDP IP is bound to the 10.x.x.x range. Also, if I run the NAT/Firewall test in Vuze, it fails because the selected port is always refused by the IP from the server, not the 10.171.x.x IP. I suppose the 10.x.x.x IP is an internal IP for the VPN, and it's the external/PIA side that's not letting the incoming connection on the port. Is there a fix for this, or is it just a fact of life with PIA and Vuze if you're a US and don't want to connect to a far away server?

    Hoping there's a fix...
  • Mycole98,

    The "Non-Vuze" line was added after the screenshot.  It should be normally what's displayed for you.  The line becomes a warning if non-vuze is not routing through the same VPN.

    The port detection depends on whether you entered your username/password.  If you don't enter credentials, it'll scan the PIA Manager's config for the port number.  If you do enter credentials, it will call PIA's RPC directly.  The latter is more resilient (and will grab a port even if the PIA Manager has the option turned off).  For people who don't want to enter their creds into Vuze, the former seems to always work (until PIA changes their manager's config format)
    Thanks for the reply and the information!
  •   First, is it correct that this plugin requires connecting to a PIA server that allows port forwarding (which, according to the PIA client support page, means there is no server in the US that this will work with?)
    Connecting to a PIA server that supports Port Forwarding is not required by the plugin, but it means you will not be able to get incoming connections, and thus, you'll always have "yellow smileys".  
     Second, if the first is correct, then does this mean there's no way to set up Vuze to ever get the full green smiley, since incoming ports can't be set to forward with US servers specifically because PIA blocks them?
    That's correct.
    In trying to work with this at the moment, I get Errors that the Vuze UDP port is bound to an IP in the range 10.171.xxx.xxx. But the PIA connection shows my IP to be in whatever range the server I'm connected to is in (which is not 10.171.x.x. So I'm not sure how or why the UDP IP is bound to the 10.x.x.x range. Also, if I run the NAT/Firewall test in Vuze, it fails because the selected port is always refused by the IP from the server, not the 10.171.x.x IP. I suppose the 10.x.x.x IP is an internal IP for the VPN, and it's the external/PIA side that's not letting the incoming connection on the port. Is there a fix for this, or is it just a fact of life with PIA and Vuze if you're a US and don't want to connect to a far away server?

    Hoping there's a fix...
    The only fix is to use a non-US PIA server, or for PIA to allow Port Forwarding for US servers.  FWIW, in my testing, I didn't see much of a speed difference between US and non US servers.
  • Hi, I'm not very good with this stuff, I appreciate all the help in advance - I've installed your plugin but it seems my settings are not correct.  Could you please tell me how to fix my settings?  https://www.anony.ws/image/DC1V


  • edited September 2015

  • edited September 2015
    Sorry apparently uMatrix addon (Pale Moon) was preventing text from posting, and now I can't delete the posts.
  • How is this installed on Linux Mint?  I find no installation instructions.  Using the Vuze Installer and navigating to the download shows it's not a "valid Vuze file".
  • edited September 2015
    Thank you for this excellent plugin.

    At first I was having no issues with it. Now, however, I am unable to download with PIA on (everything downloads excellently with it off).

    The main difference I noticed was that the UDP outbound test in the plugin, which says:

    "UDP outbound - Oubound test failed, PRUDPPacketHandler:sendAndReceive failed, no route to host"

    When I do a Network Test, the UDP outbound test fails, as well as the TCP port test. The speed test says I have 0 bytes uploading/downloading. Most of my trackers seem to be down when I have PIA connected, but I don't know if that's related.

    I do not want to do port forwarding. Do I still have to choose a port for Vuze though? I chose one which, according to canyouseeme and my port scan, was open, but that didn't change anything. Even if I am not doing port forwarding, do I have to coordinate this port with PIA somehow?

    I have also ruled out firewall issues. According to a Glasnost test it is not due to my ISP.

    I can move this post in case you all think it belongs somewhere else in the form (general connectivity issues rather than binding issues).

    Any help would be intensely appreciated.

    UPDATE: (five minutes later...) I noticed in Preferences -> Connections -> Advance Network Settings that my "bind to local port [0: disabled]" option was 0, so I changed it to match the open port that I entered for the Incoming TCP listen port and UDP listen port. Now it all magically works! I can instantly download stuff again! Did I fix it? Was I right to assume that even though I haven't done port forwarding, I need a port for Vuze that is consistent with the PIA somehow?
  • Everything was working well until not long ago when I noticed the plugin sidebar showing Bad. It says: Can't reach PIA's site using /10.166.1.6 aka eth4 (TAP-Win32 adapterV9)
    and then Can't determine VPN's local IP.
    Is there anything I can do about it?
  • Hi TuxPaper,  amazing work and the plug-in seems really cool so far.

    I am getting one warning though:
    "Subnet bitmask for /10.69.69.70 on [NIC info] is 24.  Minimum is 30."

    I'm not sure what this means.  My LAN info is:
    10.69.69.70/255.255.255.0

    Any ideas?  Thanks and, again, great work.

  • vmoreau said:
    Can't reach PIA's site using /10.166.1.6 aka eth4 (TAP-Win32 adapterV9)
    Can't determine VPN's local IP.
    I also see these (well, similar) but everything seems to be working okay--I am technically using VPN Helper plugin though (which supports PIA and others).  I would definitely like to know how to resolve it?

    PopperWow said:
    I am getting one warning though:
    "Subnet bitmask for /10.69.69.70 on [NIC info] is 24.  Minimum is 30."
    My LAN info is: 10.69.69.70/255.255.255.0

    I was getting something like this (except 8 instead of 24) and I eventually started running into issues with port forwarding (I received a port in the tool-tip but I was not connectable) along with the VPN Killswitch not working).  The issue is that OpenVPN, which PIA is built upon, has issues the 10.x.x.x subnet as local.  Once I switched to the 192.168.x.x subnet, my issues all went away.  This was easy for me as my client runs in a VMWare VIrutal Machine--all I had to do was change from 'Bridged' to 'NAT'.  I hope this helps (even though it's pretty delayed).  Unfortunately, there hasn't been much discussion on the PIA or VPN helper plugins lately.  
  • Thanks Innoman! Do you know, if I want to switch from a 10.x.x.x to a 192.168.x.x subnet, would I have to change how my router is configured, or is there  a way to do this in Vuze or PIA?
  • Thanks innoman!  Yep, that was it.  I switched to the more common 192.168.0.1 and it went away.

    roadbuster, Yes this is a change in how your LAN subnet is organized.  You need to change your router's LAN IP address to something like 192.168.0.1 and then manually renew the IP addresses for your devices so that they get a new one on the new subnet.  Good luck.
Sign In or Register to comment.