[Support] binhex - DelugeVPN


Recommended Posts

Hi

I just switched from 1.3.15 to the new 2.0.4.dev38 version of Deluge client in your image.

Everything is running smoothly and I found replacements for all my previous plugins.

 

Only thing which doesn't work are the tracker icons which should show next to the tracker name.

I found this thread which suggested renaming the icons (.ico) to .png, but that didn't help.

 

Not sure if you had this issue before (couldn't find anything in this topic)?

Link to comment

Hi all,

I downloaded https://www.privateinternetaccess.com/openvpn/openvpn.zip
and it got 2 openvpn files for say berlin and I tried both and getting this still:

 

 

2020-12-17 14:03:51,409 DEBG 'start-script' stdout output:
[warn] PIA endpoint 'de-berlin.privacy.network' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow
[info] Please consider switching to one of the endpoints shown below

2020-12-17 14:03:51,410 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

any ideas?

it was working a few months back then suddenly wasn't working so I tied to D/L the openvpn files again thinking it was updated....

Link to comment
3 hours ago, aerosmith9110 said:

Hi all,

I downloaded https://www.privateinternetaccess.com/openvpn/openvpn.zip
and it got 2 openvpn files for say berlin and I tried both and getting this still:

 

 

2020-12-17 14:03:51,409 DEBG 'start-script' stdout output:
[warn] PIA endpoint 'de-berlin.privacy.network' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow
[info] Please consider switching to one of the endpoints shown below

2020-12-17 14:03:51,410 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

any ideas?

it was working a few months back then suddenly wasn't working so I tied to D/L the openvpn files again thinking it was updated....

whilst you have correctly updated your openvpn ocnfig files, you are still using an old tagged image, remove the tag and pull down latest.

Link to comment

I'm still getting "the remote line is referencing PIA legacy network which is now shutdown" error, even though I've downloaded the newest openvpn.zip file from PIA, and am using the latest (and tried the test) branch of binhex-delugevpn. I've also tried another ovpn file (usually using CA\ Montreal.ovpn, tried CA\ Toronto.ovpn), and get the same error. What am I doing wrong?

2020-12-17 11:34:30.164925 [info] PUID defined as '99'
2020-12-17 11:34:30.189888 [info] PGID defined as '100'
2020-12-17 11:34:30.871321 [info] UMASK defined as '000'
2020-12-17 11:34:30.894360 [info] Permissions already set for volume mappings
2020-12-17 11:34:30.918113 [info] Deleting files in /tmp (non recursive)...
2020-12-17 11:34:30.945285 [info] VPN_ENABLED defined as 'yes'
2020-12-17 11:34:30.969321 [warn] VPN_CLIENT not defined (via -e VPN_CLIENT), defaulting to 'openvpn'
2020-12-17 11:34:30.992415 [info] VPN_PROV defined as 'pia'
2020-12-17 11:34:31.608775 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/CA Toronto.ovpn
2020-12-17 11:34:31.646677 [crit] VPN configuration file '/config/openvpn/CA Toronto.ovpn' 'remote' line is referencing PIA legacy network which is now shutdown, see Q19. from the following link on how to switch to PIA 'next-gen':- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md exiting script...
client
dev tun
proto udp
remote ca-montreal.privateinternetaccess.com 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server

auth-user-pass
compress
verb 1
reneg-sec 0
<crl-verify>
-----BEGIN X509 CRL-----
...
-----END X509 CRL-----
</crl-verify>

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>

 

manderso@Tower:/mnt/user/appdata/binhex-delugevpn$ ls -al openvpn/
total 16
drwxrwxr-x 1 nobody users  124 Dec 17 11:34 ./
drwxrwxr-x 1 nobody users  486 Nov  8 14:40 ../
-rwxrwxr-x 1 nobody users 3180 Dec 17 11:34 CA\ Toronto.ovpn*
-rwxrwxr-x 1 nobody users 2025 Dec 17 11:03 ca.rsa.2048.crt*
-rwxrwxr-x 1 nobody users   20 Nov 11 08:26 credentials.conf*
-rwxrwxr-x 1 nobody users  869 Dec 17 11:03 crl.rsa.2048.pem*

Thanks for your help.

Edited by manderso
Link to comment
1 minute ago, manderso said:

[crit] VPN configuration file '/config/openvpn/CA Toronto.ovpn' 'remote' line is referencing PIA legacy network which is now shutdown, see Q19. from the following link on how to switch to PIA 'next-gen':- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md exiting script...

it looks like you switched back to the older ovpn file, please do as instructed in the log shown above.

Link to comment

After updates to my binhex dockers i get [54da0c7] Unknown exception in url **api Error: Not supported proxy scheme in medusa. is this a proxy or a medusa problem?

 

edit: solved my self. seems the new version of medusa needs http:// in front of ip adress of the proxy. Was not needed until this release.

Edited by orlando500
solved it
Link to comment

Hi, so a few months ago my Torrents stopped downloading. When I try to add a torrent it starts like it's going to begin downloading, but then eventually trickles down in speed and stops all together. I'm on Version 6.8.3 and before that it was working great. At first I didn't think anything of it while going away for a couple months visiting family up north. Then I get back and try to solve the problem. I restarted, stopped and updated qbittorrentvpn docker I was using at the time. No dice there. Restarted the computer and that didn't make a difference. I eventually decided to uninstall qbittorrentvpn, and setup binhex-delugevpn (I think) and same experience here. I tried updating the PIA OpenVPN files, but that didn't do anything. If I turn the VPN off, same experience. I've attached my logs for you guys to look at, hopefully one of you can spot something there. Should I update to 6.9.0-rc1? I see 6.8.3 is the most recent. Sorry for the long rant, but hopefully you guys can get me back on track here. 

tower-syslog-20201216-2349.zip

  • Like 1
Link to comment
On 12/10/2020 at 12:24 AM, redpathx said:

Hi All,

 

Hoping for another tip here. Running with PIA & openvpn, I am able to connect to the webui, but am unable to connect to any seeders. This has happened on and off for the past week or so, has mysteriously fixed itself a couple times without me intervening then reverted to this problem. Not sure if its an AUTH problem, but I don't see anything in the logs to point that way. Log attached.

 

Thanks!

supervisord.log 2.16 MB · 4 downloads

Hi All,

 

Been continuing to battle this. It is randomly cycling, some days torrents will download, other days will not connect to any seeders (these are generally just public trackers, RARBG etc.). The only thing I can point to is the listening port that randomizes.

For example, it wasn't working when set as follows. 

Quote

2020-12-18 10:16:27,295 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '24937'

 

I then restarted the container, and it started working again, and the listening port was defined as follows

Quote

2020-12-18 19:10:38,397 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '41687'

I don't know/understand enough about these ports to know what makes one work vs another. Any tips on how I could fix this in settings to it is no longer seemingly rolling a dice?

 

Thanks!

Link to comment
I don't know/understand enough about these ports to know what makes one work vs another. Any tips on how I could fix this in settings to it is no longer seemingly rolling a dice?
 
Thanks!

I don’t think you can, sorry.
The port is randomly given out by PIA from its pool for the particular server you are connecting to.
The container uses a script that asks for a new (random) port on each reconnection to the VPN server.


Sent from my iPhone using Tapatalk
Link to comment
36 minutes ago, yanksno1 said:

Think I'm experiencing the same thing that redpathx is or at least something similar. Think it's something with the PIA OpenVPN files and I should try another server? Only weird thing is when I "turn it off" I still get the same experience and nothing downloads. 

Ah interesting. I switched to wireguard and it didn’t make a difference, but I haven’t tried different servers. (I’m using CA Toronto)

Link to comment
47 minutes ago, redpathx said:

Ah interesting. I switched to wireguard and it didn’t make a difference, but I haven’t tried different servers. (I’m using CA Toronto)

Didn't try that either (or wireguard). I just tried setting up qbittorrentvpn using the new Netherlands OpenVPN files again and it does seem to be working there. Every one so far has completed downloading. I can't seem to get Sonarr working with it again, but that's another story. Then copied those same files to this docker folder and still not working for me. So no idea what it is. But it does sound like we're experiencing the same thing. Are you on version 6.8.3 too? 

Link to comment
2 hours ago, Jorgen said:


I don’t think you can, sorry.
The port is randomly given out by PIA from its pool for the particular server you are connecting to.
The container uses a script that asks for a new (random) port on each reconnection to the VPN server.


Sent from my iPhone using Tapatalk

Would that mean these ports are likely blocked on the tracker end?

Link to comment

Hi,

 

I'm using PIA and I understand somethings have changed now. I am unable to log into delugevpn unless I disable VPN.

I am on an older version (arch-delugevpn:1.3.15_18_ge050905b2-1-04) because before the PIA issues started I was experiencing the same issue as allot of other people on the latest version of delugeVPN where the speeds dropped.

 

Is there a fix to this issue using PIA?

 

Many thanks.

 

Neil

 

Link to comment
2 minutes ago, Lien1454 said:

Hi,

 

I'm using PIA and I understand somethings have changed now. I am unable to log into delugevpn unless I disable VPN.

I am on an older version (arch-delugevpn:1.3.15_18_ge050905b2-1-04) because before the PIA issues started I was experiencing the same issue as allot of other people on the latest version of delugeVPN where the speeds dropped.

 

Is there a fix to this issue using PIA?

 

Many thanks.

 

Neil

 

You can switch to PIA’s next-gen servers to correct your connection issues but this will also require upgrading the docker container (and the Deluge app) to the latest version. You will likely see the original issues with Deluge return since it’s probably still the same version you originally had issues with. I switched docker containers instead. I’m now using binhex-qbittorrentvpn docker with the PIA next-gen servers until Deluge releases an update that hopefully fixes some of their bugs.

  • Thanks 1
Link to comment
12 hours ago, yanksno1 said:

Didn't try that either (or wireguard). I just tried setting up qbittorrentvpn using the new Netherlands OpenVPN files again and it does seem to be working there. Every one so far has completed downloading. I can't seem to get Sonarr working with it again, but that's another story. Then copied those same files to this docker folder and still not working for me. So no idea what it is. But it does sound like we're experiencing the same thing. Are you on version 6.8.3 too? 

yeah also on 6.8.3. i'll give other endpoints and maybe qbittorrentvpn a shot too

  • Like 1
Link to comment

Hi there,

this might be strange, but yesterday I installed the qbittorrent VPN and everything seemed fine. However, now I cannot access the deluge webUI anymore as the password "deluge" does not work.

What can I do?

 

Edit: It turned out there is no password set at all. Just hit enter and it worked. 

Edited by TombRaider
evidence surfaced
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.