[Support] binhex - DelugeVPN


Recommended Posts

Swichted to PIA today.

 

VPN is working but not port fordwarding. I request PF in osx PIA app and can find the port in that app using one of the PF server. Then I use spain.ovpn in docker but I can't connect to the same ip server in osx and in the docker so even I request a port number in osx I can't use it on docker.

 

should I use same port number in deluge net options and docker vpn_host options? I believe I don't. 

 

last question pls, I copy ca.rsa.2048 crt and pem next in openvpn folder (next certificates.conf and .ovpn), is that right?

 

thxs

 

supervisord-copy.txt

Link to comment
41 minutes ago, garion said:

Swichted to PIA today.

 

VPN is working but not port fordwarding. I request PF in osx PIA app and can find the port in that app using one of the PF server. Then I use spain.ovpn in docker but I can't connect to the same ip server in osx and in the docker so even I request a port number in osx I can't use it on docker.

 

should I use same port number in deluge net options and docker vpn_host options? I believe I don't. 

 

last question pls, I copy ca.rsa.2048 crt and pem next in openvpn folder (next certificates.conf and .ovpn), is that right?

 

thxs

 

supervisord-copy.txt

 

scroll down to the newbie vpn guide, its all answered in there:-

 

https://lime-technology.com/forums/topic/44108-support-binhex-general/

 

  • Like 1
Link to comment

Thanks @binhex it is clear "don't change docker port numbers", include crt and pem next to ovpn.

 

About PF it seems all is working fine and is my torrent server that show an non reachable msg with my vpn pia ip.

 

I did a port test with the port is deluge configured (it seems a dynamic port changed by docker after vpn starts) and it shows open

 

Port 56581 is open on 185.230.1xx.yy

 

?

 

EDIT: after half an hour non-reachable msg disappears. 

 

Edited by garion
Link to comment

Hi,

I mostly use my unraid server remotely. To access all of my container's UIs I connect to a openvpn-as server and I have to run all of the containers with the network mode as Host.

Apparently I can't run delugevpn as host. (I don't quite understand why but when connected to openvpn-as I can't access containers in bridge mode)

 

How can I access the deluge webUI from both the lan and when connecting remotely to the openvpn-as server.

 

unraid LAN IP: 192.168.1.73

unraid openvpn-as IP: 172.27.224.1

 

openvpn-as network: 172.27.224.0/20

 

delugevpn LAN_NETWORK: 192.168.1.0/24

 

Thanks

 

 

Edited by RicaFett
Link to comment

Hi,

 

I am hoping someone can help me figure out why I am getting limited speeds when VPN_ENABLED is set to "Yes".

 

When I have VPN turned off I get 18,000kb/s download, which is what Deluge is set to cap at. When it is turned on my speed is seemingly capped at 1,100-1300kbs (flat, not spiking). I changed no other settings to experience this difference.

 

Things I have tried:

  • Read through most of this 140pg thread!
  • Followed SpaceInvaderOne's youtube guide for initial set-up.
  • Followed binhex's newbie VPN and docker set-up guide.
  • I have tried multiple VPN endpoints (Sweden, France, Czech Republic), and while VPN'd into these I get close to my un-VPN'd speed when testing outside of Deluge.
  • I have downloads going to my cache drive.

Interestingly, my unRaid server's LAN IP is 192.168.2.1, and it does not seem to matter whether I have LAN_NETWORK set to 192.168.2.0/24 (which I understand to be correct), or to the default of 192.168.1.0/24. Not sure if this has any relevance.

 

Another thing is that the docker will choose a random port (e.g. 39605) instead of the assigned port (58846). I understand this to be normal behavior.

 

I am unsure which port and IP to check to be Open. I have been using the port specified in the log lines "Setting listen_ports to (39605, 39605).." and the IP specified in the log lines "[info] Successfully retrieved external IP address 185.216.35.68". These values are both specified in the attached log - however - they return as "closed" when checking on yougetsignal.com - why would this be?

 

This is a new unRaid installation (my first) and so I am not very experienced, and I'm at a bit of a loss as to why the docker is behaving as it does with VPN enabled. Any help would be appreciated!!

 

Edited by exoexo
Link to comment

Hello,

 

I got 2 Problems with this Container:

 

1. PIA splitted the endpoint Germany in 2 (DE Frankfurt and DE Berlin) unfortunately your script does not recognize those so there is no port forwarding enabled.

Please change that. Thanks.

 

2. Don't know if this is a problem with the Container or with unRaid or my Router:

I activated UPnP everywhere I found an option to do so but Deluge does not create a forward in the Router.

Does anyone have an idea how I can get that to work?

My Router is a AVM fritz.box 6490 and I run unRAID 6.5.3 on the Server.

 

Thanks

Edited by Llamrei
Link to comment
On 8/4/2018 at 11:47 AM, exoexo said:

I have tried multiple VPN endpoints (Sweden, France, Czech Republic), and while VPN'd into these I get close to my un-VPN'd speed when testing outside of Deluge.

 

what do you mean by 'when testing outside of deluge' do you mean you are exec'd into the container and you can curl or some such command and see decent speeds?.

 

On 8/4/2018 at 11:47 AM, exoexo said:

Interestingly, my unRaid server's LAN IP is 192.168.2.1, and it does not seem to matter whether I have LAN_NETWORK set to 192.168.2.0/24 (which I understand to be correct), or to the default of 192.168.1.0/24. Not sure if this has any relevance.

 

its of no relevance, you need the correct value entering in order to be able to connect to the webui from other machines in your lan, this however wont affect dl/ul speeds.

 

On 8/4/2018 at 11:47 AM, exoexo said:

I am unsure which port and IP to check to be Open. I have been using the port specified in the log lines "Setting listen_ports to (39605, 39605).." and the IP specified in the log lines "[info] Successfully retrieved external IP address 185.216.35.68". These values are both specified in the attached log - however - they return as "closed" when checking on yougetsignal.com - why would this be?

 

i have no idea, you are correct in what you are doing, so it should be showing as open.

 

Link to comment
On 8/2/2018 at 4:28 PM, RicaFett said:

Hi,

I mostly use my unraid server remotely. To access all of my container's UIs I connect to a openvpn-as server and I have to run all of the containers with the network mode as Host.

Apparently I can't run delugevpn as host. (I don't quite understand why but when connected to openvpn-as I can't access containers in bridge mode)

 

How can I access the deluge webUI from both the lan and when connecting remotely to the openvpn-as server.

 

unraid LAN IP: 192.168.1.73

unraid openvpn-as IP: 172.27.224.1

 

openvpn-as network: 172.27.224.0/20

 

delugevpn LAN_NETWORK: 192.168.1.0/24

 

Thanks

 

 

 

try changing LAN_NETWORK=172.27.224.0/20,192.168.1.0/24

Link to comment
On 8/5/2018 at 2:24 AM, Llamrei said:

1. PIA splitted the endpoint Germany in 2 (DE Frankfurt and DE Berlin) unfortunately your script does not recognize those so there is no port forwarding enabled.

Please change that. Thanks.

 

yeah thats PIA being shit again, basically their list of port forward enabled endpoints is a random article they have posted which they dont update, great eh!. so ive now put both of these endpoints in as port forward enabled endpoints, im assuming both are but hey its impossible to tell until you try using them.

 

On 8/5/2018 at 2:24 AM, Llamrei said:

I activated UPnP everywhere I found an option to do so but Deluge does not create a forward in the Router.

Does anyone have an idea how I can get that to work?

My Router is a AVM fritz.box 6490 and I run unRAID 6.5.3 on the Server.

 

rookie mistake, you don't do any port forwarding on your router, please remove the port forward, think of it like this, PIA is now your router when vpn is enabled, so they do the port forwarding, not you. 

Link to comment
39 minutes ago, binhex said:

 

what do you mean by 'when testing outside of deluge' do you mean you are exec'd into the container and you can curl or some such command and see decent speeds?.

 

 

binhex - thanks for the response. I had meant that I had simply ran a speed test while VPN'd to each of the PIA nodes I was connecting to - and I was experiencing speeds while VPN'd that were close to the maximum for my ISP, so I don't think it was an issue with the speed of PIA's nodes (which is always my first thought when VPN'd).

 

Quote

its of no relevance, you need the correct value entering in order to be able to connect to the webui from other machines in your lan, this however wont affect dl/ul speeds.

 

 

i have no idea, you are correct in what you are doing, so it should be showing as open.

 

 

In the end I gave up, and switched to your ruTorrent docker. This worked great out of the box for me with good speeds while VPN'd, using the same values I had entered for the Deluge docker. This leads me to believe the problem was something within the Deluge client itself, that was restricting my speed while VPN'd, rather than your docker. My testing was with a public Ubuntu distro, so it wasn't like the tracker was restricting me either, and like I said, Deluge was fine when not VPN'd - very weird...

Edited by exoexo
Link to comment
59 minutes ago, binhex said:

 

yeah thats PIA being shit again, basically their list of port forward enabled endpoints is a random article they have posted which they dont update, great eh!. so ive now put both of these endpoints in as port forward enabled endpoints, im assuming both are but hey its impossible to tell until you try using them.

 

 

rookie mistake, you don't do any port forwarding on your router, please remove the port forward, think of it like this, PIA is now your router when vpn is enabled, so they do the port forwarding, not you. 

 

Hi,

 

yes both Endpoints support Port Forwarding, tested it on my PC.

 

Ok, deleted all Forwards in the Router, looks like it Torrent works now.

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

yes both Endpoints support Port Forwarding, tested it on my PC.

 

ok thats good to know, the image is still building so it will be a couple of hours before you will see the change to the list of allowed endpoints, for now test with sweden, thats relatively quick.

Link to comment
14 hours ago, yanksno1 said:

Still can't log into the webui with any password I try (including "deluge"). What should I do?

 

delete the file /config/web.conf (and config/web.conf~ if it exists) and then restart the container, when prompted enter a password of 'deluge' without the quotes, all lower case.

Link to comment
10 hours ago, binhex said:

 

delete the file /config/web.conf (and config/web.conf~ if it exists) and then restart the container, when prompted enter a password of 'deluge' without the quotes, all lower case.

 

Where should that be? Not seeing a config folder in the binhex-delugevpn folder there. Sorry, pretty new to unRaid still.

Link to comment

Trying to get the daemon port to work, port 58846 is open in config, docker in bridge mode and privileged, core.conf has "allow_remote": true, and a user is set in auth file with user:password:10.

I guess im missing something? do you have to create a user in the docker?

Link to comment

I've been using this container for at least a year,  without issue. Then my watchtower updated to the most recent build (2 days old)

 

Current build (latest) is giving me DNS errors with PIA servers. I swapped DNS providers (Cloudflare, Google) to no avail. I recreated the container, same problem. I tried current build of arch-rtorrentvpn with the same errors. I changed PIA servers (swiss, montreal, etc). Tried toggling with port forwarding on and off. No difference.

 

I created a new container with the arch-rtorrentvpn container with the previous build (0.9.7-1-07) and it worked*. Just did the same with arch-delugevpn back to 1.3.15_14_gb8e5ebe82-1-11 and it also works. The latest builds seem to be causing DNS errors with Synology DSM docker. I reloaded the old docker settings without issue on the manually specified build, so it doesn't seem to matter if it's from scratch or existing, the old builds work. New ones do not.  ?

 

 

2018-08-07 22:12:57,733 DEBG 'start-script' stdout output:
[info] Adding 1.1.1.1 to /etc/resolv.conf

2018-08-07 22:12:57,741 DEBG 'start-script' stdout output:
[info] Adding 1.0.0.1 to /etc/resolv.conf

2018-08-07 22:12:58,006 DEBG 'start-script' stderr output:
random.c:102: fatal error: RUNTIME_CHECK(ret >= 0) failed

2018-08-07 22:12:58,018 DEBG 'start-script' stdout output:
[crit] swiss.privateinternetaccess.com cannot be resolved, possible DNS issues

2018-08-07 22:12:58,018 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 140398907495416 for <Subprocess at 140398907496280 with name start-script in state RUNNING> (stdout)>
2018-08-07 22:12:58,019 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 140398907495056 for <Subprocess at 140398907496280 with name start-script in state RUNNING> (stderr)>
2018-08-07 22:12:58,019 INFO exited: start-script (exit status 1; not expected)
2018-08-07 22:12:58,019 DEBG received SIGCLD indicating a child quit

 

 

*rutorrent has always been a problem with Synology DSM docker. I think Flood worked fine, but I needed the added functionality of full rutorrent (such as ratio groups), or Deluge and it's plugins. Regular rutorrent worked fine at first, restarting it stopped working (that or I lost patience). I figured either way, the inherent problem is the current builds for both containers. So I didn't waste any more time trying to get rutorrent to work (likely it's that DSM's AppArmor thing again), and that's outside the scope of this thread. 

 

 

 

Link to comment
18 hours ago, ecx said:

I've been using this container for at least a year,  without issue. Then my watchtower updated to the most recent build (2 days old)

 

Current build (latest) is giving me DNS errors with PIA servers. I swapped DNS providers (Cloudflare, Google) to no avail. I recreated the container, same problem. I tried current build of arch-rtorrentvpn with the same errors. I changed PIA servers (swiss, montreal, etc). Tried toggling with port forwarding on and off. No difference.

 

I created a new container with the arch-rtorrentvpn container with the previous build (0.9.7-1-07) and it worked*. Just did the same with arch-delugevpn back to 1.3.15_14_gb8e5ebe82-1-11 and it also works. The latest builds seem to be causing DNS errors with Synology DSM docker. I reloaded the old docker settings without issue on the manually specified build, so it doesn't seem to matter if it's from scratch or existing, the old builds work. New ones do not.  ?

 

 


2018-08-07 22:12:57,733 DEBG 'start-script' stdout output:
[info] Adding 1.1.1.1 to /etc/resolv.conf

2018-08-07 22:12:57,741 DEBG 'start-script' stdout output:
[info] Adding 1.0.0.1 to /etc/resolv.conf

2018-08-07 22:12:58,006 DEBG 'start-script' stderr output:
random.c:102: fatal error: RUNTIME_CHECK(ret >= 0) failed

2018-08-07 22:12:58,018 DEBG 'start-script' stdout output:
[crit] swiss.privateinternetaccess.com cannot be resolved, possible DNS issues

2018-08-07 22:12:58,018 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 140398907495416 for <Subprocess at 140398907496280 with name start-script in state RUNNING> (stdout)>
2018-08-07 22:12:58,019 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 140398907495056 for <Subprocess at 140398907496280 with name start-script in state RUNNING> (stderr)>
2018-08-07 22:12:58,019 INFO exited: start-script (exit status 1; not expected)
2018-08-07 22:12:58,019 DEBG received SIGCLD indicating a child quit

 

From the above log the issue is that dig is crashing and thus unable to resolve name to ip, this looks to be affecting Synology boxes only, my guess is that the kernel is way out of date and thus there is a mismatch between the latest version of dig (updated in the docker base image, thus the appearance of the problem) and the kernel running on your Synology box. so for now i can rollback the version of dig to the previous version, this should then fix the issue for you.

Link to comment

@ecx and @MikeyP new image currently building with the rolled back version of dig, it should be ready in about an hour from now, can you please confirm whether it fixes the issue as i need to know whether i can roll this out to the other vpn images, and obviously i dont have a synology box in which to test this with so i cant confirm whether my fix works.

 

scrub that, issues with new base and old pkg bind-tools, need to look into alternative cmd when exit code != 0 for dig.

Edited by binhex
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.