[Support] binhex - rTorrentVPN


Recommended Posts

28 minutes ago, dvd.collector said:

Is PIA removing port forwarding ability completely?

The situation for PIA is as follows (at present):-

  • Port forwarding on their legacy network is near enough dead, there are only certain servers for endpoint ca-vancouver that still work right now.
  • Port forwarding using openvpn on their next-gen network is currently not possible, api is not accessible.
  • Native wireguard support on their next-gen network is currently not possible (hacks are available but they are fragile!).

So where does that leave us?, well not quite up sh*t creek without a paddle :-), you can set 'STRICT_PORT_FORWARDING' to 'no' and this will then allow you to connect to any legacy endpoint, however this will mean you wont have a working incoming port so speeds will be lower than usual - its not ideal i know, but its the best we have got right now until PIA sort their sh*t out (not happy).

 

If you want to help out then PLEASE raise a support ticket via PIA web portal (https://www.privateinternetaccess.com/helpdesk/new-ticket) and bitch about the above, the more people that complain the more pressure they have to do something about it!.

 

If you are completely pissed off with PIA (and i would completely understand this!) and want to switch then i recommend Mulllvad at this time, they are more pricey but they are solid and are privacy focused and support port forwarding.

Edited by binhex
  • Like 2
Link to comment
2 minutes ago, Cull2ArcaHeresy said:

My theory is that they have old and new servers at the location, and when it reaches the endpoint it is directed to one of the available servers and so it is luck of the draw as to if it gets connected to an old or new server. Pure speculation, so might be 100% wrong.

i think you are probably spot on here, its frustrating to say the least!

Link to comment
Just now, Cull2ArcaHeresy said:

Only officially supported one left?

officially i have heard nothing from PIA, i have posted on reddit (which they used to respond to and monitor), nothing!, i have raised a support ticket, nothing!, so right now i can only assume they are slowly disassembling the current network and working on their next-gen network, leaving people who require port forwarding and dont want to use their 'app' high and dry.

Link to comment
25 minutes ago, dvd.collector said:

 

EDIT, saw this on the PIA website:
* The information contained within this article will only work with our Current/Previous Generation servers. Our Next Generation servers do not currently offer port-forwarding outside of the application. *

 

So I guess as they upgrade their servers this will stop working.  Back to my other question then, can anyone recommend a different VPN that will work well with this docker?

Thanks for pointing out how port-forwarding will be done by PIA in future. I too will be in the same boat - and looking for suggestions for an alternative VPN.

Link to comment
On 9/7/2020 at 5:20 PM, testdasi said:

While we wait for binhex, I built a docker on top of his to randomly pick an .ovpn file from a folder on docker start/restart. Sort of a quick fix for now.

  1. Create a folder called 'openvpn_files' under your rtorrentvpn appdata folder (e.g. mkdir /mnt/user/appdata/rtorrentvpn/openvpn_files)
  2. Extract / copy the (PIA) .ovpn files to the above openvpn_files folder.
  3. Edit your docker template and change Repository to 'testdasi/rutorrentvpn-plus-plus' and Docker Hub URL to 'https://registry.hub.docker.com/r/testdasi/rutorrentvpn-plus-plus/'
  4. Apply and check log. If doesn't work then restart the docker and it will pick a random one from the openvpn_files.

 

 

To revert back to binhex's one, edit the docker template and change Repository to 'binhex/arch-rtorrentvpn' and Docker Hub URL to 'https://registry.hub.docker.com/r/binhex/arch-rtorrentvpn/'

 

 

 

this method requires restarting the container, any reason to not have the line where an openvpn connection is established to pick a random *.ovpn file? Been meaning to try it, just havent yet. This way whenever it resets the connection it will try a new one (or pick the same again as random).

Link to comment
4 minutes ago, Cull2ArcaHeresy said:

this method requires restarting the container, any reason to not have the line where an openvpn connection is established to pick a random *.ovpn file? Been meaning to try it, just havent yet. This way whenever it resets the connection it will try a new one (or pick the same again as random).

I tried but gave up. Binhex scripts are too complex for my amateur head. I managed to get openvpn to load with a random .ovpn file but it fails the privoxy and rutorrent stage. I have got my stuff on git so feel free to have a look if it helps in any way.

https://github.com/testdasi/rutorrentvpn-plus-plus/tree/master/stuff

Link to comment
55 minutes ago, testdasi said:

I tried but gave up. Binhex scripts are too complex for my amateur head. I managed to get openvpn to load with a random .ovpn file but it fails the privoxy and rutorrent stage. I have got my stuff on git so feel free to have a look if it helps in any way.

https://github.com/testdasi/rutorrentvpn-plus-plus/tree/master/stuff

in all fairness this is non trivial, the problem is very simple but the solution is not, one of the issues is around dns, as i block dns to prevent any leakage, so name resolution when switching vpn endpoint would not be possible when the openvpn connection goes down, or in the case of pia, when you cannot allocate a incoming port., there are other issues too around env var's for the remote line and passing these around to child shell processes.

 

picking a random ovpn file at startup is trivial, but of course then requires manual intervention from the user to restart the container.

Edited by binhex
Link to comment
36 minutes ago, binhex said:

in all fairness this is non trivial, the problem is very simple but the solution is not, one of the issues is around dns, as i block dns to prevent any leakage, so name resolution for another vpn endpoint would not be possible when the openvpn connection goes down, or in the case of pia, when you cannot allocate a incoming port., there are other issues too around env var's for the remote line and passing these around to child shell processes.

 

picking a random ovpn file at startup is trivial, but of course then requires manual intervention from the user to restart the container.

i had assumed that it more or less did something like 1-[ established vpn conn ], 2-[ locked down connections (including dns) ], 3-[ started rtorrent/rutorrent ], 4-[ monitored connection and if need be kill *torrent and go back to #1 ]

 

knowing the dns issue (and yea docker env variables are a pain to change), it is a much more closed locked down system :) Can a container restart itself? Rough idea that is it counts number of fails (connection or pia forward), and at some arbitrary threshold it restarts (or kill itself with the restart flag in docker command)? Could always have it create a file when that threshold is met and a script running on unraid sees the file, deletes it and restarts the container...but idk if it is a big enough problem to do that.

 

just to be clear, all pia with same creds or all other with same creds. Im not against mixing them, but being the same for simplicity.

Link to comment
17 minutes ago, Cull2ArcaHeresy said:

like 1-[ established vpn conn ], 2-[ locked down connections (including dns) ], 3-[ started rtorrent/rutorrent ], 4-[ monitored connection and if need be kill *torrent and go back to #1 ]

 

no it is a lot more locked down than that, more like:-

 

1. read in ovpn file

2. resolve endpoint and store answers

3. block using iptables

4. start openvpn client

5. start app

 

there are other checks in place, such as port forward assignment and remote ip address resolution too, all of which must start in a particular order to prevent any chance of ip leakage, as well as a tight looped dns check to ensure we have internet connectivity.

 

 

Edited by binhex
Link to comment
33 minutes ago, Cull2ArcaHeresy said:

an a container restart itself?

potentially yes, you could kill pid 1, this would then cause the entire thing to collapse, but you would need to ensure that the restart flag is set on the container otherwise it would be in a stopped state, this would also mean an unclean shutdown as you are in essence pulling the power plug.

 

edit - just so we dont forget, this is all nice and all but wont be of any use with pia right now, as all endpoints (pretty much) are screwed when it comes to port forwarding 🙂

Edited by binhex
Link to comment
19 minutes ago, binhex said:

potentially yes, you could kill pid 1, this would then cause the entire thing to collapse, but you would need to ensure that the restart flag is set on the container otherwise it would be in a stopped state.

compared to a "graceful stop", would this cause any issues like rtorrent corrupting a file or leakage (or other)? Also not a hard threshold, but a count that resets each hour might be much better so a series of reconnects over time wouldn't cause a restart.

Link to comment

Changing of pia vpn files to get to different endpoints while whatever is going on, what is the best way to measure "quality" for each? There are different tools to measure container stats but also connecting directly to rtorrent could give data. I have enough seeding torrents that that should be constantly at limit (when connection is good), fewer downloads but that would be easy to change. Trying to figure out the best way to keep track of upload and download for each vpn file. Being early on this would be raw totals for each day and later being more of a line graph probably. Raw scaled by how many hours that vpn file was used that day (other options too like hourly average, but that is a later thing).

 

So say your connection is bad right now, you stop the container and run this script that would give you a list of vpn files and their daily quality history (from your runs) and ask you to select which one you want to copy in for the container to use. Then you start the container again and it will connect using the chosen file. While container is running this script is logging the network usage.

Link to comment

hey guys, i'm having trouble setting up jackett rss feeds with vpn on (mullvad if it matters).  Works fine with vpn turned off, but with vpn turned on it cannot connect to jackett.

 

example rss from jackett:  http://10.0.0.186:9117/api/v2.0/indexers/limetorrents/results/torznab/api?apikey=xxxxxxx=search&cat=&q=

 

i do have LAN_Network set to 10.0.0.0/24 in the docker config.  Is there any other setting i'd need to fix?

 

thanks for any input!

Link to comment

Has anyone who switched to Mullvad get port forwarding to work?  I know the strict port forward is ignored if don’t have PIA, but I’ve added a port forward for my account over at Mullvad and have gone into ruTorrent front end and choose settings > connection > port used for incoming connections and set it to the port and even tried 1234-1234 where 1234 is the real port number. It doesn’t do anything for me. The status icon at the bottom is still a red exclamation mark. 
 

I have a gigabit connection and without port forwarding I get about 60MB/sec on a well seeded torrent, I used to get as high as 85MB/sec with PIA and port forwarding enabled. 
 

EDIT: I should add I copied the rtorrent.rc file to .rtorrent.rc with the ports specified from Mullvad and the port status still is red. :(

Edited by cardo
  • Like 1
Link to comment
On 9/9/2020 at 5:58 AM, binhex said:

So where does that leave us?, well not quite up sh*t creek without a paddle :-), you can set 'STRICT_PORT_FORWARDING' to 'no' and this will then allow you to connect to any legacy endpoint, however this will mean you wont have a working incoming port so speeds will be lower than usual - its not ideal i know, but its the best we have got right now until PIA sort their sh*t out (not happy).

its 'STRICT_PORT_FORWARD' for the variable

 

wasnt working and was using this reference instead of the faq you have

 

Always refer to the faq lol

Link to comment
16 hours ago, Cessquill said:

Have you tried setting VPN_ENABLED to "no"?

Yes but my port is reported as closed, even though i have tripple checked everything is set correctly.

 

Docker mapping has 172.17.0.2:51413/UDP192.168.1.253:51413

 

I have that port forwarded on my router, both UDP and TCP, I've edited the rtorrent.rc file to include the port also.

Edited by Spies
Link to comment
  • binhex locked this topic
Guest
This topic is now closed to further replies.