[Support] binhex - DelugeVPN


Recommended Posts

2 minutes ago, Burizado said:

OK, I have been reading through all the new posts regarding the nextgen setups.  I updated my docker which was successful.  I can connect successfully using legacy ovpn files from PIA.

 

Deluge: 2.0.4.dev38
PIA ovpn files: legacy
Port Forward: no
Errors: none; connects fine and everything resumes

 

I downloaded the nextgen files via the instructions form Q19 in the VPN Docket FAQ.  I removed the old ovpn and cert files and replaced them with the nextgen files.  I also changed the STRICT_PORT_FORWARD variable to 'yes' since it was set to 'no' while using the legacy files.

 

When I try to start my docker I get the following error in the log:
2020-10-02 10:11:11,741 DEBG 'start-script' stdout output:
Fri Oct 2 10:11:11 2020 AUTH: Received control message: AUTH_FAILED

 

I saw Q16 in the VPN Docker FAQ which states my VPN_USER and/or VPN_PASS are not correct.  I regenerated my username and password from the PIA account site and updated them in the docker settings, but I am still receiving the error.  I even failed back to legacy ovpn files, setting STRICT_PORT_FORWARD to 'no', and everything works fine.  So I am thinking my user ID and password are good/valid since they work with the legacy files just fine.  A couple of questions to those with PIA and have it working with nextgen files:

 

1. Did you download the NextGen zip from the link labeled 'OpenVPN Configuration Files (Recommended Default)'?  The step in Q19 doesn't specify which set of files to use, but I was assuming the top link.

134302754_PIANextGenFiles.png.a42c0a9c40f425238092aeaccff9de1a.png

 

2. Are you using the 'PPTP/L2TP/SOCKS Username and Password' from PIA?  I wasn't sure if I should be using a different username and password for VPN_USER and VPN_PASS for the NextGen setup.  This is what works with my legacy ovpn files.

2061471121_PIACredentialArea.png.cbb88e97e13d68b313c088bc1f7d9134.png

 

3. Are there any other settings you need to change outside of what is stated in Q19 from the VPN Docket FAQ?  I am assuming no or else it would be called out in those steps to switch over to NextGen.


I also tested setting STRICT_PORT_FORWARD variable to 'yes' with legacy files, and another test with nextgen files and the setting it to 'no'.  Both were still failures and I assumed neither of these were the ideal setup so I am not working on troubleshooting those failures.

 

I am attaching my logs for legacy files port forwarding set to 'no', and nextgen files port forwarding set to 'yes' just if anyone wants to look at anything not stated here in my working and not working logs.

LegacyPortFwdNo.txt 103.8 kB · 0 downloads NextgenPortFwdYes.txt 139.39 kB · 0 downloads

 

So I am not sure if I need something in my PIA account flagged so I can use the NextGen servers or something else with my PIA account not setup correctly.  I know I am grasping at straws but I am not sure what is going on here.  I can open a ticket with PIA but I wanted to make sure what I am doing is correct before having them check my account on their side.

 

Any help from anyone would be....well....helpful. :)
Thanks.

which ovpn file did you pick (what location)? is it one of the approved locations that it mentions in the log when starting deluge

  • Thanks 1
Link to comment
36 minutes ago, wgstarks said:

It looks to me as if you have set a tag for this docker in the repository field. Is it set to "latest". If it's set to 1.3.15_18_ge050905b2-1-04 then it won't install the latest update. You'll need to change the version to latest and install the current version on Deluge v2.

Well, hell, I didn't even know that was as thing. I have no idea how I had a specified version when I didn't even know that was something that could be done. 

 

Thanks for the help, that did it and I'm up and running now. 

 

 

Link to comment
3 minutes ago, Cytomax said:

which ovpn file did you pick (what location)? is it one of the approved locations that it mentions in the log when starting deluge

Yes.  I am using CA Toronto.  It is one of the locations mentioned in the my legacy log.  It doesn't get that far in the nextgen log, but I am assuming it works based on a previous post someone stating it works with nextgen.

 

Thanks for the follow-up question.  I forgot to mention what location I am testing.

Link to comment

Hello!

 

I'm struggling with the final 5% of setting up YaRSS2 with my binhex-DelugeVPN docker container. 

 

I've followed the steps detailed here:   

 

I've been able to successfully set up the client deluge (getting passed all the Python version fun that is posted about everywhere), and the connection to the Server/Container deluge. 

 

Then I get a bit confused about what I should be seeing. My understanding is that  I'll *never* see YaRSS2 config in the Docker container WebUI. However, when I'm on the non-server "thin" client, and I set up an RSS, with the connection manager pointed to the Docker container server, it just downloads to the client machine... which isn't what I want.

 

This sorta seems obvious when I look at the Download config of the client Deluge installation - it's pointed at the local machine. But my confusion is around how these steps were to set up RSS for the server. Am I missing something? Is it impossible to have RSS driven downloads in the Docker container? or have I just missed the last few steps of config?

 

One step that I wasn't quite sure if I achieved, was that installing YaRSS2 on the windows client is supposed to *also* install it on the server somehow? (See quote below)

 

Quote

When running the Deluge daemon, deluged and Deluge client on a separate computers, the plugin must be installed on both machines. Installing a plugin egg through the GTK client will copy the egg to both the local plugins directory, as well as the remote daemon's. However if the Python versions on the local machine and remote server do not match, you will have to copy the egg to the remote server manually.

https://dev.deluge-torrent.org/wiki/Plugins/YaRSS2#RunningaserverseedboxwithaDelugedaemon

 

I'll keep investigating on my own, but if someone has any guidance or tips, I'd greatly appreciate it!

 

Thanks!

Link to comment

What’s the best way to test other Binhexvpn downloaders without un-installing this one? If I install qbtorrent (for example) can I set it with adjusted ports and sonarr/Radarr will still be able to connect? Maybe it would be better to uninstall this docker first since I can always re-install from previous apps in CA?

Link to comment
4 hours ago, Burizado said:

Yes.  I am using CA Toronto.  It is one of the locations mentioned in the my legacy log.  It doesn't get that far in the nextgen log, but I am assuming it works based on a previous post someone stating it works with nextgen.

 

Thanks for the follow-up question.  I forgot to mention what location I am testing.

Just wanted to join in that I am having the same exact issues Burizado.  I did try with other Port Forwarding ovpn's to no avail.  Its like my credentials are not being passed correctly or are bad (but PIA works fine from desktop).  I am using the PPTP/SOCKS credentials.

Edited by viciouscircle
clarification
  • Like 1
Link to comment

welp that settles it...

 

i only changed from qbittorrent because i was too dumb to realize i needed the nextget vpn files and not the old files

so i tried deluge and got like 8 megaBytes per second

 

went back to qbittorrent and downloaded 4 Ubuntu ISO's and got to 32 megaBytes without breaking a sweat

 

its absolutely possible different times of the day may of caused this bottle neck but w/e i like the interface of qbittorrent better anways 

 

Thanks binhex for great work!

2020-10-02_17-16.png

Link to comment

Hi, since about a week ago my deluge docker has stopped working and I'm not sure how to fix it. When I start the docker, the logs have these errors:

2020-10-03 13:44:13,427 DEBG 'start-script' stderr output:
/root/openvpn.sh: eval: line 73: unexpected EOF while looking for matching `''
/root/openvpn.sh: eval: line 74: syntax error: unexpected end of file

 

After a minute the docker seems to be using 100% of my CPU and RAM, other dockers start crashing and the Unraid web-ui goes non-responsive.

 

I have tried removing the docker (and also removing the image) and reinstalling. I also tried rolling back to an older version from 2 months ago which gave me a different error:

 

2020-10-03 14:03:00,929 DEBG 'start-script' stdout output:
[warn] Exit code '52' from curl != 0 or no response body received
[info] 7 retries left
[info] Retrying in 10 secs...

 

I also followed the instructions to upgrade to PIA Nextgen thinking that might be the problem, but no change.

 

Does anybody know what the problem is and how I can fix it? Thanks in advance

Link to comment

Since switching over to next gen PIA servers I have been seeing very slow website DNS resolves when using my browser that has its proxy settings pointed to the Deluge privoxy port. After some trouble shooting I decided to remove all the prefilled PIA DNS addresses from Name_Servers in the Deluge templet and only use the Cloudflare addressed. Doing this resolved me slow resolve issue.

 

Turns out that PIA next gen has a new set of server addresses for it as well, link to them below.

https://www.privateinternetaccess.com/helpdesk/kb/articles/next-generation-dns-custom-configuration

I added the new PIA DNS addresses to Name_Servers and everything is working normally again.

 

Not sure if I missed this in binhex's instructions somewhere but I suggest that everyone who has moving over to PIA next gen also update the Name_Servers from PIA legacy to PIA nextgen addresses.

 

Still not sure why I get slow resolves when the I have PIA DSN addresses listed in Name_Servers. Dose anyone else have a browser pointed at the privoxy port and seeing very slow site resolves?

Edited by TrueImpulse
  • Like 2
Link to comment
10 hours ago, viciouscircle said:

Just wanted to join in that I am having the same exact issues Burizado.  I did try with other Port Forwarding ovpn's to no avail.  Its like my credentials are not being passed correctly or are bad (but PIA works fine from desktop).  I am using the PPTP/SOCKS credentials.

It's not the socks credentials you need, it's your main username (pXXXXXXX) & password for PIA.

  • Like 1
  • Thanks 2
Link to comment
8 hours ago, TrueImpulse said:

Turns out that PIA next gen has a new set of server addresses for it as well, link to them below.

https://www.privateinternetaccess.com/helpdesk/kb/articles/next-generation-dns-custom-configuration

I added the new PIA DNS addresses to Name_Servers and everything is working normally again.

 

This doesn't seem to work for me.  My DelugeVPN docker is currently configured with Google name servers.  If I change the Key9 setting to two of the 10.0.0.? addresses, the vpn tunnel fails to come up.  Have I misunderstood?

 

10.0.0.0/8 are private addresses so can't possibly work before the tunnel is up.

 

Edit:

Yep, I've just read again - those DNS addresses are for use within the PIA applications, and are set automatically.

Edited by PeterB
Link to comment
2 hours ago, PeterB said:

This doesn't seem to work for me.  My DelugeVPN docker is currently configured with Google name servers.  If I change the Key9 setting to two of the 10.0.0.? addresses, the vpn tunnel fails to come up.  Have I misunderstood?

 

10.0.0.0/8 are private addresses so can't possibly work before the tunnel is up.

 

Edit:

Yep, I've just read again - those DNS addresses are for use within the PIA applications, and are set automatically.

I'm sure your right. I know that 10.0.0* address are for private network IP schemes, I was kind of tired last night and I just went with it, sorry.

 

This must mean that the container is disregarding all the 10.0.0.* addresses and using the Cloudflare 1.1.1.1 I have in there. Still doesn't explain why its so slow resolving when I have the PIA addresses in there. I suppose the PIA DNS is having issue but I never had this problem on legacy.

 

Dose anyone else have a browser pointed at their privoxy port and noticing very slow site resolves when using the default Name_Servers for a PIA setup?

 

Edited by TrueImpulse
Link to comment

Hello;

I updated my delugevpn after a month and am unable to connect to the web browser.  As soon as I disable VPN, it works.

  I am a slick VPN user, not PIA, and have been having issues.

 

I have confirmed using my local pc that slickvpn works, and works with a torrent client.  When I check the supervisord.log I do get the weird restart issue:
 

Quote

 

Sat Oct  3 18:24:11 2020 /usr/bin/ip addr add dev tun0 local 10.10.8.26 peer 10.10.8.25

2020-10-03 18:24:11,195 DEBG 'start-script' stdout output:
Sat Oct  3 18:24:11 2020 /root/openvpnup.sh tun0 1500 1557 10.10.8.26 10.10.8.25 init

2020-10-03 18:24:11,203 DEBG 'start-script' stdout output:
[debug] Waiting for valid local and gateway IP addresses from tunnel...

 


I have tried different slickVPN locations, have messed around with the slickVPN cert as well, all to no avail.  Checked my network, no changes on port forwarding or anything like that.

Just wondering if anyone can point me in the right direction?  

delugevpnlogs.txt

Link to comment
On 9/20/2020 at 2:21 PM, Ranzingabon Hagglesmith said:

I've noticed some strange problems over the past few weeks-- mostly torrent time-out errors, and now I'm getting the "Error: end of file" on random files from one particular tracker. I thought it might be a problem with the particular AirVPN server I was using, so I restarted the container a few days ago, but the errors just creeped back. Any idea what might  be going wrong? My fear is that might be because of the number of torrents I have (~2500 unpaused). I have the ltConfig plugin set up and adjusted, and that fixed errors that arose when I hit around 2,000 torrents, so I'm hoping it's something that can be fixed by playing around with those settings. Strange that rebooting the Deluge docker fixes the timeout errors for a few days.

 

Actually, it seems the "Error: end of file" error I'm receiving from torrents for one particular tracker is not fixed by rebooting the container, so I have no clue what's going on there.

 

I'm running the latest version of the Binhex DockerDelugeVPN via AirVPN.

 

e: rechecking the torrents does not seem to fix the "Error: end of file" problem

Hi folks, any thoughts?

 

Now I'm getting errors "Error: unexpected end of file in bencoded string" and  "Error: No route to host"

 

Link to comment
11 hours ago, binhex said:

from your log:-

 


2020-10-03 18:23:45,030 DEBG 'start-script' stdout output:
Sat Oct  3 18:23:45 2020 [VPN] Inactivity timeout (--ping-restart), restarting

see Q17 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md


So, the issue I am having is, openvpn works on the docker host:

 

Quote

[root@docker02v openvpn]# openvpn --config /u01/deluge/openvpn/slick_seattle.ovpn
Sun Oct  4 03:04:13 2020 WARNING: file 'credentials.conf' is group or others accessible
Sun Oct  4 03:04:13 2020 OpenVPN 2.4.9 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2020
Sun Oct  4 03:04:13 2020 library versions: OpenSSL 1.0.2k-fips  26 Jan 2017, LZO 2.06
Sun Oct  4 03:04:13 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]50.22.146.42:443
Sun Oct  4 03:04:13 2020 UDP link local: (not bound)
Sun Oct  4 03:04:13 2020 UDP link remote: [AF_INET]50.22.146.42:443
Sun Oct  4 03:04:13 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Oct  4 03:04:13 2020 [VPN] Peer Connection Initiated with [AF_INET]50.22.146.42:443
Sun Oct  4 03:04:15 2020 TUN/TAP device tun0 opened
Sun Oct  4 03:04:15 2020 /sbin/ip link set dev tun0 up mtu 1500
Sun Oct  4 03:04:15 2020 /sbin/ip addr add dev tun0 local 10.10.8.6 peer 10.10.8.5
Sun Oct  4 03:04:15 2020 Initialization Sequence Completed


So I am connected, when I do a curl to http://whatismyip.host

 

Quote

[root@mikedocker02v ~]# curl http://whatismyip.host | grep ipaddress
            <p class="ipaddress">50.22.146.42</p>
 

 

So outside docker container, and on the same host, it works.  I'll try and do the same test on the docker container itself

Link to comment

One of the reasons I have stuck with the 1.3.15 version of deluge is its ability to use the thin client, which I far prefer over the web client. But progress moves on, and I far prefer having the port forwarding OpenVPN with PIA, so a small price to pay. (And the legacy servers are retiring at the end of the month!)

 

I do have a question, however. I force upgraded the newest binhex image, set it up, everything works pretty spontaneously. Thanks for all the quick, hard work, binhex!! The connection to CA Toronto resulted in a port forward connection. I can see this through one of my torrent providers that reports back if your seed is port forwarded. On the thin client, I could press a button on the Network tab of Preferences to "Check Port", which would always show a green ball if the port was forwarded or a yellow triangle/exclamation if not. Since there is no thin client in this version of deluge, and the web client on Network tab of Preferences does not have this, just a filled in port number, my question is this: Is there a way to determine if port forward is active on the connection? Can I inspect either supervisord or through the console window for the docker to easily confirm port forwarding is active for the torrents in the client?

Link to comment
1 hour ago, terag1e said:

One of the reasons I have stuck with the 1.3.15 version of deluge is its ability to use the thin client, which I far prefer over the web client. But progress moves on, and I far prefer having the port forwarding OpenVPN with PIA, so a small price to pay. (And the legacy servers are retiring at the end of the month!)

Thin client works fine - your problem is Microsoft or Apple!

 

Just thinking obliquely - if you were to set up a VM running Linux, could run the thin client on it with a remote desktop.

Edited by PeterB
Link to comment
11 minutes ago, PeterB said:

Thin client works fine - your problem is Microsoft or Apple!

 

Just thinking obliquely - if you were to set up a VM running Linux, could run the thin client on it with a remote desktop.

And I may yet! I have quite a few VMs throughout the network, but right now it's a problem for days in the future (thin client)!!

Link to comment
On 10/3/2020 at 3:46 AM, xxDeadbolt said:

It's not the socks credentials you need, it's your main username (pXXXXXXX) & password for PIA.

xxDeadbolt, thanks for this I have been struggling for awhile now.  Under the old PIA server I used the socks user and password. I have been reading this thread and never saw that.  I'm up and running now.

Link to comment

Anyone have a recommended solution?

 

I've had to restart my container 5 times today and it finally connected with berlin.   I'm not married to PIA, but do need a VPN where I can torrent without worry.  I do need deluge as it fits my needs for automations.   (Can't find another container that can unrar/move files upon download)

 

 

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.