[Support] binhex - rTorrentVPN

[tuna83]

1 hour ago, binhex said:

lan network is invalid, from your log:-

 

2020-08-31 22:36:47.204123 [info] LAN_NETWORK defined as '192.168.0.1/24'

see Q4 from the following link for how to calculate it correctly:-

https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Thank you, of course it worked. I combed that log for about 3 hours trying to see something that would flag the issue. What made you see what the problem was?

 

Like I said I was pretty annoyed I couldn't fix it myself, even more annoyed now it turns out the answer is in the FAQ..

[BiGBaLLA]

1 hour ago, binhex said:

if you are using AirVPN then i would be interested to see your log, please do the following:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

I'm not sure if it's helpful, but I attached the latest one and the 3.10 version. Both the same config / torrents. 3.10 shows the vpn ip to the tracker, and latest is showing 127.0.0.1.

 

Thanks, I really appreciate your work!

supervisord_3_10_01.log supervisord_latest.log

[theGrok]

On 8/29/2020 at 7:24 PM, lzrdking71 said:

@binhex It looks like this is happening again https://github.com/binhex/arch-rtorrentvpn/issues/104

 

2020-08-29 17:10:49,842 DEBG 'start-script' stdout output:
[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...
[info] Show name servers defined for container

 

IP in the rutorrent settings/bittorent shows 127.0.0.1. I am using Airvpn as my vpn provider and the latest docker container available to unraid.

 

You helped fix it before, hopefully an easy fix again.

 

I am having the same exact issue above. I am also using AirVPN as my provider and have the latest available container.

[binhex]

10 hours ago, tuna83 said:

What made you see what the problem was?

ive created and supported this image for a LOT of years now, after a while you see the problem quite quickly :-), plus your symptom is classic of misconfigured lan - cannot access the web ui but the container has started successfully.

[binhex]

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

[BiGBaLLA]

2 hours ago, binhex said:

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

This did it for me! I updated all my instances and all are working correctly again, thank you for fixing this so quickly!

[theGrok]

3 hours ago, binhex said:

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

I pulled the update and all seems to working great. Thx @binhex for this great container and for your work!

[lzrdking71]

5 hours ago, binhex said:

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

@binhex, all is working again after the update. You are awesome, thanks for all your hard work!

[omninewb]

@binhex

 

Would it be possible to have the script run through a list of .ovpn files after failing to port forward with one? Use case would be, CA-Montreal is having port-forward API issues right now, and as it is the first in the list alphabetically (I assume), the script only chooses it to retry with. Could it instead take a list of all .ovpn files in the config/openvpn directory and try them each in succession until a successful API call is made?

 

As always, thanks for your work!

Edited September 6, 2020 by omninewb

[testdasi]

On 9/6/2020 at 6:33 PM, omninewb said:

@binhex

 

Would it be possible to have the script run through a list of .ovpn files after failing to port forward with one? Use case would be, CA-Montreal is having port-forward API issues right now, and as it is the first in the list alphabetically (I assume), the script only chooses it to retry with. Could it instead take a list of all .ovpn files in the config/openvpn directory and try them each in succession until a successful API call is made?

 

As always, thanks for your work!

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/'

 

 

 

[dvd.collector]

So I've tried every endpoint in the PIA list and all throw this:
 

2020-09-09 10:39:03,388 DEBG 'start-script' stdout output:
[info] List of PIA endpoints that support port forwarding:-
[info] ca-toronto.privateinternetaccess.com
[info] ca-montreal.privateinternetaccess.com
[info] ca-vancouver.privateinternetaccess.com
[info] de-berlin.privateinternetaccess.com
[info] de-frankfurt.privateinternetaccess.com
[info] france.privateinternetaccess.com
[info] czech.privateinternetaccess.com
[info] spain.privateinternetaccess.com
[info] ro.privateinternetaccess.com
[info] israel.privateinternetaccess.com
[info] Attempting to get dynamically assigned port...

2020-09-09 10:39:24,196 DEBG 'start-script' stdout output:
[warn] Exit code '52' from curl != 0 or no response body received
[info] 12 retries left
[info] Retrying in 10 secs...

2020-09-09 10:39:24,196 DEBG 'start-script' stdout output:
[warn] Exit code '52' from curl != 0 or no response body received
[info] 12 retries left
[info] Retrying in 10 secs...

 

 

Is PIA removing port forwarding ability completely?

 

If so, is there a different VPN that supports port forwarding that anyone would recommend?

 

 

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?

Edited September 9, 2020 by dvd.collector

[binhex]

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 September 9, 2020 by binhex

[binhex]

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!

[Cull2ArcaHeresy]

6 minutes ago, binhex said:

ca-vancouver

Only officially supported one left?

 

I deleted my post since you had a factually correct answer, just didnt pop up until after i had made my comment.

Edited September 9, 2020 by Cull2ArcaHeresy

[binhex]

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.

[sonofdbn]

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.

[Cull2ArcaHeresy]

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).

[testdasi]

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

[binhex]

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 September 9, 2020 by binhex

[Cull2ArcaHeresy]

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.

[binhex]

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 September 9, 2020 by binhex

[binhex]

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 September 9, 2020 by binhex

[Cull2ArcaHeresy]

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.

[binhex]

Just now, Cull2ArcaHeresy said:

compared to a "graceful stop", would this cause any issues like rtorrent corrupting a file or leakage (or other)?

possibly, yes.

[kagzz]

Hello maybe binhex will make wireguard integreted

Sendt fra min ONEPLUS A6003 med Tapatalk