[Support] binhex - DelugeVPN


Recommended Posts

After reading the Github Q&As, i got everything working but now my Nzbget is unreachable by my Sonarr and Radarr.

 

  • Sonarr and Radarr are NOT using proxy and are NOT using a VPN
    • The download client "nzbget" is pointed towards the 192.xxx address
  • NZBget is using binhex delugeVPN.
  • In binhex delugeVPN i've added Host Port for 6789. Port 6789 is added in VPN INPUT and OUTPUT ports.
  • NZBget container starts fine, and the webui is reachable. After a few minutes the webui is no longer reachable and sonarr and radarr cannot communicate to NZBget.
    • NZBget log has constant "[ERROR] Binding socket failed for 0.0.0.0: ErrNo 98, Address in use"

deluge.thumb.PNG.110c1a323a60ade9e7345de9f081e9a0.PNG

 

I'm really lost on what to do. Does anyone know why nzbget can be connected to by webui and sonarr/radarr for a few minutes and then it can't communicate/connect?

 

EDIT 1: Restarted the server and restarted docker multiple times. Immediately, I am able to connect to nzbget via the 192 local IP and port 6789. If i go into sonarr/radarr or close nzbget tab and try to go back into it, i can't connect to the webui and sonarr/radarr can't connect to it.

Edited by Foxhound
Link to comment
15 hours ago, Foxhound said:

After reading the Github Q&As, i got everything working but now my Nzbget is unreachable by my Sonarr and Radarr.

 

  • Sonarr and Radarr are NOT using proxy and are NOT using a VPN
    • The download client "nzbget" is pointed towards the 192.xxx address
  • NZBget is using binhex delugeVPN.
  • In binhex delugeVPN i've added Host Port for 6789. Port 6789 is added in VPN INPUT and OUTPUT ports.
  • NZBget container starts fine, and the webui is reachable. After a few minutes the webui is no longer reachable and sonarr and radarr cannot communicate to NZBget.
    • NZBget log has constant "[ERROR] Binding socket failed for 0.0.0.0: ErrNo 98, Address in use"

deluge.thumb.PNG.110c1a323a60ade9e7345de9f081e9a0.PNG

 

I'm really lost on what to do. Does anyone know why nzbget can be connected to by webui and sonarr/radarr for a few minutes and then it can't communicate/connect?

 

EDIT 1: Restarted the server and restarted docker multiple times. Immediately, I am able to connect to nzbget via the 192 local IP and port 6789. If i go into sonarr/radarr or close nzbget tab and try to go back into it, i can't connect to the webui and sonarr/radarr can't connect to it.

Ok, just my 5 cents here, because I'm no expert at this. But, shouldn't the Deluge port be added to VPN_INPUT? And, I don't think that you should have the same port in VPN_output - I'm sure that is adding confusion

See my config here:

delugeconf.JPG.540126310112d5066798cd7050371e7d.JPG

 

Now, I don't have the same setup as you, but before I got NZBHydra added I only had Jacket routed through Deluge and Jacket do not need to access to any containers (except Deluge), it's just the arrs that need access to Jacket. Configured like that I didn't need any port configured for VPN_OUTPUT

 

When I added NZBHydra, that container needed access to the arrs and then I had to add these ports in VPN_OUTPUT

 

I hope that can help a little.

Link to comment
On 5/5/2021 at 1:41 PM, tetrapod said:

Also posted this to Organizr thread

 

Having problems with getting organizr to communicate with deluge docker (using binhex-delugevpn). I have followed the instructions and downloaded the egg file WebAPI-0.4.0-py3.7.egg for Deluge. Renamed it WebAPI-0.4.0-py3.9.egg and installed it. I can however not tick the box to enable the plugin and I'm getting API Error (no. 2) when testing the connection from Organizr.
I also can not find out how to remove the plugin from Deluge to start over again 😐
Is this something I can not do in this container?

 

Got an answer from @ados in another thread.

On 5/6/2021 at 1:18 PM, ados said:

The main issue with that application is support which has decreased over time.

You need to stay on older versions if you wish to have plugin support.

Keeping it short as this belongs over on the Deluge forum, you need to be on a 2.0.X version. 2.0.4 is a good one. 😉

 

...and this container show deluge as being om 2.0.4?

version.JPG.c71048aee9eacc8f505673db46aac519.JPG

 

Now, I have never handled plugins for Deluge befor so it could very well be me who is doing something stupid (again).

plugins.JPG.9ed5a0c8b17d70a0fab68c9466f1f9da.JPG

There the plugin is, but I can't Enable it and I do not know how to remove it.

 

Link to comment
6 hours ago, tetrapod said:

Ok, just my 5 cents here, because I'm no expert at this. But, shouldn't the Deluge port be added to VPN_INPUT? And, I don't think that you should have the same port in VPN_output - I'm sure that is adding confusion

See my config here:

delugeconf.JPG.540126310112d5066798cd7050371e7d.JPG

 

Now, I don't have the same setup as you, but before I got NZBHydra added I only had Jacket routed through Deluge and Jacket do not need to access to any containers (except Deluge), it's just the arrs that need access to Jacket. Configured like that I didn't need any port configured for VPN_OUTPUT

 

When I added NZBHydra, that container needed access to the arrs and then I had to add these ports in VPN_OUTPUT

 

I hope that can help a little.

 

You bring up a very good point, i'm not quite sure if it should be under input and output or just one of them.

SOLUTION: I fixed the problem by completely deleting the config file in appdata after removing nzbget and deleting image. Apparently something from the config was all messed up causing these odd issues. I thought originally it was something with delugevpn. Now I have nzbget working normally through delugeVPN and is able to communicate with sonarr/radarr. Thanks all!

Link to comment

I have an odd issue i cant seem to find a fix for. I'm not really seeding anymore, use PIA and go through IPTor. Currently have the top 10 most leeched items in deluge just sitting there with no seeding. I am getting seeding on some items from time to time but its like they stop seeding way quick.

 

Facts:

1. Downloads are perfectly fine and run at very good connection speeds

2. Torrents do show up in IPTor peers list but with 0 seed time, 0 ratio etc etc.

3. After disabling privoxy some connections would come through but still nowhere near where traffic used to be (56kbps or less for less than 1 minute each connect)

4. Connection speed available is 1000mbps up / 45mbps down

5. running these on a windows computer through deluge yields normal results (seeds properly, shows up in IPTor, seeds at good speeds of mbps instead of kbps) all on the same network.

 

Steps I've taken to remedy

1. Redownloaded PIA certs and changed to Czech

2. Changed queue settings and even went to high numbers just to see if there was any change

image.png.9fe072a75b650fddd7eba960e668c248.png

3. Also changed Bandwidth preferences... no change

image.png.2a355f67e1ae0946271f2aeaa14bed35.png

4. Restarted server, rebooted modem/router and even factory restored both and updated firmware with no change on all

5. Setup unraid as DMZ to ensure there was no port issues (no change) and setup Port Forwarding also with no change

6. Tried with and without Privoxy setting being on (I'm not currently using privoxy). Without would let some connections happen on restart but after a minute or two they would all stop seeding again.

 

Link to comment
33 minutes ago, Remamian said:

Setup unraid as DMZ

Please tell me you undid that within seconds of trying.

 

NEVER put Unraid in a DMZ, best case scenario is crashing your server when all the hack attempts fill the logs. Worst case is your server is compromised and all your data is deleted.

Link to comment
15 minutes ago, jonathanm said:

Please tell me you undid that within seconds of trying.

 

NEVER put Unraid in a DMZ, best case scenario is crashing your server when all the hack attempts fill the logs. Worst case is your server is compromised and all your data is deleted.

100% immedately changed back. Just used it for diagnostics to rule out a port forwarding issue.

Link to comment

Hi,

 

Im running delugevpn - All is working fine but the torrents themselves are not downloading. The dht seems to work and I can see traffic flowing there. The downloads are added etc and I can reach the console. Not seeing anything odd in the logs either. I started openvpn and the connection is established.

 

The setup is somewhat advanced since its docker in lxc on proxmox...

 

Anyone has a clue how to start figuring it out?

 

/M

Link to comment
6 hours ago, Mikki74 said:

Hi,

 

Im running delugevpn - All is working fine but the torrents themselves are not downloading. The dht seems to work and I can see traffic flowing there. The downloads are added etc and I can reach the console. Not seeing anything odd in the logs either. I started openvpn and the connection is established.

 

The setup is somewhat advanced since its docker in lxc on proxmox...

 

Anyone has a clue how to start figuring it out?

 

/M

This sounds like a volume mapping issue or a wrong path in the downloads section in deluge. Post your docker run command and a screenshot of the downloads section in deluge.

Link to comment

I am running into some trouble with what I believe is the LAN_NETWORK parameter and the IP_TABLES blocking me from accessing the deluge web GUI from a different subnet depending on the docker network configuration. I tired to use the binhex FAQ and some other searches, but I just couldn't find anything that applied to my particular situation.

 

Here is the setup ONE:

unRAID is at 192.168.10.40/24

PC I am attempting to access the binhex-delugevpn web GUI from is at 192.168.130.50/24

LAN_NETWORK is set to 192.168.0.0/16 to encompass everything

Docker is configured as a bridge network.

Here is the docker run command:

user@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-delugevpn' --net='bridge' --privileged=true -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='user' -e 'VPN_PASS'='pass' -e 'VPN_PROV'='custom' -e 'VPN_CLIENT'='openvpn' -e 'VPN_OPTIONS'='' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='no' -e 'LAN_NETWORK'='192.168.0.0/16' -e 'NAME_SERVERS'='nameserver' -e 'DELUGE_DAEMON_LOG_LEVEL'='info' -e 'DELUGE_WEB_LOG_LEVEL'='info' -e 'VPN_INPUT_PORTS'='' -e 'VPN_OUTPUT_PORTS'='' -e 'DEBUG'='false' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '8112:8112/tcp' -p '58846:58846/tcp' -p '58946:58946/tcp' -p '58946:58946/udp' -p '8118:8118/tcp' -v '/mnt/user/appdata/data':'/data':'rw' -v '/mnt/cache/appdata/binhex-delugevpn':'/config':'rw' --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-delugevpn'

When I run this docker, the VPN connects (verified via docker log), but I cannot access it from my PC on a different subnet. However, if I fire up a Firefox docker also in bridge mode, I can access the deluge web GUI. 

 

 

Here is the setup TWO:

unRAID is at 192.168.10.40/24

PC I am attempting to access the binhex-delugevpn web GUI from is at 192.168.130.50/24

LAN_NETWORK is set to 192.168.10.0/24

Docker is configured as br0 network with IP of 192.168.10.210/24

Here is the docker run command:

user@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-delugevpn' --net='br0' --ip='192.168.10.210' --privileged=true -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'TCP_PORT_8112'='8112' -e 'TCP_PORT_58846'='58846' -e 'TCP_PORT_58946'='58946' -e 'UDP_PORT_58946'='58946' -e 'TCP_PORT_8118'='8118' -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='user' -e 'VPN_PASS'='pass' -e 'VPN_PROV'='custom' -e 'VPN_CLIENT'='openvpn' -e 'VPN_OPTIONS'='' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='no' -e 'LAN_NETWORK'='192.168.10.0/24' -e 'NAME_SERVERS'='nameserver' -e 'DELUGE_DAEMON_LOG_LEVEL'='info' -e 'DELUGE_WEB_LOG_LEVEL'='info' -e 'VPN_INPUT_PORTS'='' -e 'VPN_OUTPUT_PORTS'='' -e 'DEBUG'='false' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -v '/mnt/cache/appdata/data':'/data':'rw' -v '/mnt/cache/appdata/binhex-delugevpn/':'/config':'rw' --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-delugevpn'

When I run this docker, the VPN connects (verified via docker log) and I can access it from my PC on a different subnet. What is even more confusing for me is if I fire up the same Firefox docker and try and access the deluge web GUI, I cannot even though they are both on the very same layer 2 network. 

 

The main reason I am trying to get this figured out is I have 2-3 other dockers I'd like to route through this binhex-delugevpn docker to grab the VPN benefits. However, in order for that to work the dockers must be configured in bridge mode. As referenced above, when I am in bridge mode I am unable to access the web GUI of the various services contained within those dockers. 

 

Edited by ati
Link to comment
16 hours ago, strike said:

This sounds like a volume mapping issue or a wrong path in the downloads section in deluge. Post your docker run command and a screenshot of the downloads section in deluge.

Yes - Think so too. Changed to 777 and it started working so Ill need to test so I can change back. Thought it was something with the tun device but obviously not :)

Link to comment
6 hours ago, ati said:

Here is the setup ONE:

 

6 hours ago, ati said:

LAN_NETWORK is set to 192.168.0.0/16 to encompass everything

This is wrong. You need to set your LAN_NETWORK to 192.168.10.0,192.168.130.0

You can have multiple subnets defined, just separate them with comma.

 

6 hours ago, ati said:

Here is the setup TWO:

 

6 hours ago, ati said:

Docker is configured as br0 network

This container doesn't officially support a customs bridge network, like br0. It can work in some cases but sometimes it does not. If you want to go this route you'd better ditch the web ui and download the thin client and use that. Then you might get it to work on br0.

 

6 hours ago, ati said:

What is even more confusing for me is if I fire up the same Firefox docker and try and access the deluge web GUI, I cannot even though they are both on the very same layer 2 network. 

By default all container on a custom bridge network are blocked from the host. This is a security feature. This means they can NOT access other containers on host and normal bridge network. They must be on the same custom bridge in order to communicate.  I haven't tried it, but I think you can bypass this by setting "Host access to custom networks:"  to enabled in settings->Docker.

 

 

Link to comment
2 hours ago, strike said:

 

This is wrong. You need to set your LAN_NETWORK to 192.168.10.0,192.168.130.0

You can have multiple subnets defined, just separate them with comma.

I'll give that a go, though I don't see the difference. I have other devices on other subnets contained within that /16 network that I would like to be able to access the docker as well. 

What is the difference between 192.168.0.0/16 and 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, 192.168.110.0/24, 192.168.120.0/24, 192.168.130.0/24?

 

The br0 isn't my goal, it was just for testing to try and gather more data. I need it to run in bridge mode anyway in order to route other dockers through this one.

 

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

I have other devices on other subnets contained within that /16 network that I would like to be able to access the docker as well. 

You didn't mention that in your OP, then you must add that subnet to your LAN_NETWORK as well. The point of the LAN_NETWORK variable is to define your network, and all the subnets you listed are different networks. So if you need access from all of them they need to be listed. There is no magical "catch all type networks" you can add instead, AFAIK anyway. 

Link to comment

Not sure if I'm in the right thread; I just search best+vpn and sorted by date. I have been using PureVPN with binhex-delugevpn for some time without issue however a few months ago torrents became none existent- very slow. I'm not sure exactly when the problem started as I only noticed recently and then thought back.... I think I've done everything I'm supposed to do after the 'leak discovery' and can access SAB and Jackett running through it. I'm sure torrents were working fine afterwards. If I console in to either of the above 3 I get the correct (VPN) external address.

 

If I turn the VPN off in the Deluge my torrents download sometimes hundreds of times faster... that's the only variable. SAB has no speed issues at all. I've had a nightmare dealing with PUREVPN support (or lack thereof) and looking for something else unless someone can point me in the direction of an issue it may be on my end. So in summary;

 

Can anyone advise on something else (simple, I'm not an expert) that may be causing the problem on my end ?

If not what is the best (most compatible) VPN to go to ?

 

Thanks in advance for any help.

Link to comment
On 5/13/2021 at 8:39 AM, Remamian said:

I have an odd issue i cant seem to find a fix for. I'm not really seeding anymore, use PIA and go through IPTor. Currently have the top 10 most leeched items in deluge just sitting there with no seeding. I am getting seeding on some items from time to time but its like they stop seeding way quick.

 

Facts:

1. Downloads are perfectly fine and run at very good connection speeds

2. Torrents do show up in IPTor peers list but with 0 seed time, 0 ratio etc etc.

3. After disabling privoxy some connections would come through but still nowhere near where traffic used to be (56kbps or less for less than 1 minute each connect)

4. Connection speed available is 1000mbps up / 45mbps down

5. running these on a windows computer through deluge yields normal results (seeds properly, shows up in IPTor, seeds at good speeds of mbps instead of kbps) all on the same network.

 

Steps I've taken to remedy

1. Redownloaded PIA certs and changed to Czech

2. Changed queue settings and even went to high numbers just to see if there was any change

image.png.9fe072a75b650fddd7eba960e668c248.png

3. Also changed Bandwidth preferences... no change

image.png.2a355f67e1ae0946271f2aeaa14bed35.png

4. Restarted server, rebooted modem/router and even factory restored both and updated firmware with no change on all

5. Setup unraid as DMZ to ensure there was no port issues (no change) and setup Port Forwarding also with no change

6. Tried with and without Privoxy setting being on (I'm not currently using privoxy). Without would let some connections happen on restart but after a minute or two they would all stop seeding again.

 

 

To add, the torrents DO show peers connecting, just no bandwidth being used. 

Link to comment
19 hours ago, strike said:

You didn't mention that in your OP, then you must add that subnet to your LAN_NETWORK as well. The point of the LAN_NETWORK variable is to define your network, and all the subnets you listed are different networks. So if you need access from all of them they need to be listed. There is no magical "catch all type networks" you can add instead, AFAIK anyway. 

Well I mean that is how subnet masking works. You can summarize (catch all) if you set it up correctly. But whether this docker can support that or not I don't know. 

 

I changed my LAN_NETWORK to "192.168.10.0/24,192.168.130.0/24" and still no luck.

 

The reason I didn't mention the other networks is I don't feel that it matters. I need to get one working first. No use troubleshooting 7 things at once. 

 

I logged into the docker and verified my networks were in the IP tables:

 

sh-5.1# iptables --list-rules
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -s ***.***.***.***/32 -i eth0 -j ACCEPT
-A INPUT -s ***.***.***.***/32 -i eth0 -j ACCEPT
-A INPUT -s ***.***.***.***/32 -i eth0 -j ACCEPT
-A INPUT -s ***.***.***.***/32 -i eth0 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8112 -j ACCEPT
-A INPUT -s 192.168.10.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
-A INPUT -s 192.168.130.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d ***.***.***.***0/32 -o eth0 -j ACCEPT
-A OUTPUT -d ***.***.***.***/32 -o eth0 -j ACCEPT
-A OUTPUT -d ***.***.***.***/32 -o eth0 -j ACCEPT
-A OUTPUT -d ***.***.***.***/32 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8112 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.10.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.130.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

 

 

I am not sure what else to try. This is rather frustrating as I don't have this issue with any other container, so it must be in the IP tables somewhere. I am just not overly familiar with how they're implemented here.

I am a little lost that port 58846 is specifically called out as allowed from the remote subnets, while 8112 isn't and that is the port the GUI for Deluge runs on. 

 

Link to comment
14 hours ago, wgstarks said:

Private Internet Access (PIA). Not saying they’re any better than other companies but they are better supported in this docker container and associated documentation.

Thanks for the reply. Really wondering if it is a config issue thought as SAB (running through Deluge) gets expected speeds. Could it have something to do with port forwarding ? I was really hoping for suggestions re: config issues.

 

Link to comment

This is really starting to do my head in.

 

I have DelugeVPN setup and everything is working fine except for the torrents themselves.

 

All containers (SAB and Jacket) running through Deluge have the correct external IP and are accessible from the webui so I'm pretty sure I have done everything required from the Feb IP tightening; and pretty sure the torrents were working when this was done.

 

At first I suspected my VPN provider (PureVPN) and there outdated OPENVPN files, however, downloading from SAB I get the 4-5MB/s that I would expect from my ISP (I live in Australia), so the VPN is not causing a bottleneck.

 

Deluge torrents either don't download at all (no peers, just no activity at all) or it is extremely slow. Switch the vpn off and I can get the speeds I would expect.

 

Things I've tried:

 

Wiped Deluge, SAB and Jacket (including appdata files) and started again.

Installed Binhex qbittorrentvpn - same behaviour.

Tried running qbittorrent (without vpn) through deluge (mimicking SAB) - same behaviour.

 

PureVPN on windows or Kali work fine and I get expected speeds using speedtest.net

 

I'm at the point of setting up a Kali VM just for the torrent side of things, but that is presenting a whole different set of issues.

 

Any help is greatly appreciated.

 

image.thumb.png.53022fa8e3579a2f848120c39ae7c92b.png

image.thumb.png.5069e8d7866add56b05601c90a46f521.png

image.png.6b94dc7d55452dd0b5c911effc421dba.png

 

Logs

 

\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > <
|___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2021-05-19 23:01:41.006192 [info] Host is running unRAID
2021-05-19 23:01:41.028731 [info] System information Linux 7cb5697ec646 5.10.28-Unraid #1 SMP Wed Apr 7 08:23:18 PDT 2021 x86_64 GNU/Linux
2021-05-19 23:01:41.056890 [info] OS_ARCH defined as 'x86-64'
2021-05-19 23:01:41.083374 [info] PUID defined as '99'
2021-05-19 23:01:41.115182 [info] PGID defined as '100'
2021-05-19 23:01:41.152044 [info] UMASK defined as '000'
2021-05-19 23:01:41.177190 [info] Permissions already set for volume mappings
2021-05-19 23:01:41.204992 [info] Deleting files in /tmp (non recursive)...
2021-05-19 23:01:41.237807 [info] VPN_ENABLED defined as 'yes'
2021-05-19 23:01:41.266135 [info] VPN_CLIENT defined as 'openvpn'
2021-05-19 23:01:41.294095 [info] VPN_PROV defined as 'custom'
2021-05-19 23:01:41.337099 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/jp2-ovpn.ovpn
2021-05-19 23:01:41.399559 [info] VPN remote server(s) defined as 'jp2-ovpn.pointtoserver.com,'
2021-05-19 23:01:41.421527 [info] VPN remote port(s) defined as '80,'
2021-05-19 23:01:41.444061 [info] VPN remote protcol(s) defined as 'tcp-client,'
2021-05-19 23:01:41.471618 [info] VPN_DEVICE_TYPE defined as 'tun0'
2021-05-19 23:01:41.498277 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2021-05-19 23:01:41.525234 [info] LAN_NETWORK defined as '192.168.2.0/24'
2021-05-19 23:01:41.553266 [info] NAME_SERVERS defined as '209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1'
2021-05-19 23:01:41.581384 [info] VPN_USER defined as 'XXX'
2021-05-19 23:01:41.609447 [info] VPN_PASS defined as 'XXX'
2021-05-19 23:01:41.635789 [info] ENABLE_PRIVOXY defined as 'yes'
2021-05-19 23:01:41.668736 [warn] ADDITIONAL_PORTS DEPRECATED, please rename env var to 'VPN_INPUT_PORTS'
2021-05-19 23:01:41.692031 [info] ADDITIONAL_PORTS defined as '9117,8080'
2021-05-19 23:01:41.718169 [info] VPN_OUTPUT_PORTS not defined (via -e VPN_OUTPUT_PORTS), skipping allow for custom outgoing ports
2021-05-19 23:01:41.745219 [info] DELUGE_DAEMON_LOG_LEVEL defined as 'info'
2021-05-19 23:01:41.772022 [info] DELUGE_WEB_LOG_LEVEL defined as 'info'
2021-05-19 23:01:41.796412 [info] Starting Supervisor...
2021-05-19 23:01:41,930 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2021-05-19 23:01:41,930 INFO Set uid to user 0 succeeded
2021-05-19 23:01:41,931 INFO supervisord started with pid 7
2021-05-19 23:01:42,934 INFO spawned: 'shutdown-script' with pid 177
2021-05-19 23:01:42,936 INFO spawned: 'start-script' with pid 178
2021-05-19 23:01:42,939 INFO spawned: 'watchdog-script' with pid 179
2021-05-19 23:01:42,939 INFO reaped unknown pid 8 (exit status 0)
2021-05-19 23:01:42,943 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2021-05-19 23:01:42,943 INFO success: shutdown-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2021-05-19 23:01:42,943 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2021-05-19 23:01:42,943 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2021-05-19 23:01:43,018 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.222 to /etc/resolv.conf

2021-05-19 23:01:43,022 DEBG 'start-script' stdout output:
[info] Adding 84.200.69.80 to /etc/resolv.conf

2021-05-19 23:01:43,027 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.174 to /etc/resolv.conf

2021-05-19 23:01:43,031 DEBG 'start-script' stdout output:
[info] Adding 1.1.1.1 to /etc/resolv.conf

2021-05-19 23:01:43,036 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.218 to /etc/resolv.conf

2021-05-19 23:01:43,041 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.177 to /etc/resolv.conf

2021-05-19 23:01:43,045 DEBG 'start-script' stdout output:
[info] Adding 84.200.70.40 to /etc/resolv.conf

2021-05-19 23:01:43,050 DEBG 'start-script' stdout output:
[info] Adding 1.0.0.1 to /etc/resolv.conf

2021-05-19 23:01:43,437 DEBG 'start-script' stdout output:
[info] Default route for container is 172.17.0.1

2021-05-19 23:01:43,453 DEBG 'start-script' stdout output:
[info] Docker network defined as 172.17.0.0/16

2021-05-19 23:01:43,458 DEBG 'start-script' stdout output:
[info] Adding 192.168.2.0/24 as route via docker eth0

2021-05-19 23:01:43,459 DEBG 'start-script' stdout output:
[info] ip route defined as follows...

2021-05-19 23:01:43,459 DEBG 'start-script' stdout output:
--------------------

2021-05-19 23:01:43,460 DEBG 'start-script' stdout output:
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
192.168.2.0/24 via 172.17.0.1 dev eth0

2021-05-19 23:01:43,461 DEBG 'start-script' stdout output:
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.17.0.0 dev eth0 table local proto kernel scope link src 172.17.0.2
local 172.17.0.2 dev eth0 table local proto kernel scope host src 172.17.0.2
broadcast 172.17.255.255 dev eth0 table local proto kernel scope link src 172.17.0.2
--------------------

2021-05-19 23:01:43,464 DEBG 'start-script' stdout output:
iptable_mangle 16384 2
ip_tables 28672 5 iptable_filter,iptable_nat,iptable_mangle
x_tables 28672 14 ip6table_filter,xt_conntrack,iptable_filter,xt_tcpudp,xt_addrtype,xt_CHECKSUM,xt_nat,ip6_tables,ipt_REJECT,ip_tables,ip6table_mangle,xt_MASQUERADE,iptable_mangle,xt_mark

2021-05-19 23:01:43,465 DEBG 'start-script' stdout output:
[info] iptable_mangle support detected, adding fwmark for tables

2021-05-19 23:01:43,544 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2021-05-19 23:01:43,546 DEBG 'start-script' stdout output:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -s 185.242.4.59/32 -i eth0 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8112 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9117 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 9117 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8080 -j ACCEPT
-A INPUT -s 192.168.2.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
-A INPUT -s 192.168.2.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 8118 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d 185.242.4.59/32 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8112 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9117 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 9117 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8080 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8080 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.2.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.2.0/24 -o eth0 -p tcp -m tcp --sport 8118 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

2021-05-19 23:01:43,547 DEBG 'start-script' stdout output:
--------------------

2021-05-19 23:01:43,547 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2021-05-19 23:01:43,555 DEBG 'start-script' stdout output:
2021-05-19 23:01:43 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.

2021-05-19 23:01:43,555 DEBG 'start-script' stdout output:
2021-05-19 23:01:43 WARNING: file 'credentials.conf' is group or others accessible
2021-05-19 23:01:43 OpenVPN 2.5.1 [git:makepkg/f186691b32e68362+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 24 2021
2021-05-19 23:01:43 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10

2021-05-19 23:01:43,555 DEBG 'start-script' stdout output:
2021-05-19 23:01:43 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2021-05-19 23:01:43,556 DEBG 'start-script' stdout output:
2021-05-19 23:01:43 TCP/UDP: Preserving recently used remote address: [AF_INET]185.242.4.59:80
2021-05-19 23:01:43 Attempting to establish TCP connection with [AF_INET]185.242.4.59:80 [nonblock]

2021-05-19 23:01:43,711 DEBG 'start-script' stdout output:
2021-05-19 23:01:43 TCP connection established with [AF_INET]185.242.4.59:80
2021-05-19 23:01:43 TCP_CLIENT link local: (not bound)
2021-05-19 23:01:43 TCP_CLIENT link remote: [AF_INET]185.242.4.59:80

2021-05-19 23:01:44,970 DEBG 'start-script' stdout output:
2021-05-19 23:01:44 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1559', remote='link-mtu 1552'
2021-05-19 23:01:44 WARNING: 'auth' is used inconsistently, local='auth SHA1', remote='auth [null-digest]'
2021-05-19 23:01:44 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

2021-05-19 23:01:44,971 DEBG 'start-script' stdout output:
2021-05-19 23:01:44 [Secure-Server] Peer Connection Initiated with [AF_INET]185.242.4.59:80

2021-05-19 23:01:46,412 DEBG 'start-script' stdout output:
2021-05-19 23:01:46 TUN/TAP device tun0 opened
2021-05-19 23:01:46 net_iface_mtu_set: mtu 1500 for tun0
2021-05-19 23:01:46 net_iface_up: set tun0 up

2021-05-19 23:01:46,413 DEBG 'start-script' stdout output:
2021-05-19 23:01:46 net_addr_v4_add: 172.94.56.68/28 dev tun0
2021-05-19 23:01:46 /root/openvpnup.sh tun0 1500 1554 172.94.56.68 255.255.255.240 init

2021-05-19 23:01:46,416 DEBG 'start-script' stdout output:
2021-05-19 23:01:46 Initialization Sequence Completed

2021-05-19 23:01:47,596 DEBG 'start-script' stdout output:
[info] Attempting to get external IP using 'http://checkip.amazonaws.com'...

2021-05-19 23:01:49,276 DEBG 'start-script' stdout output:
[info] Successfully retrieved external IP address 172.94.56.68

2021-05-19 23:01:49,277 DEBG 'start-script' stdout output:
[info] Application does not require port forwarding or VPN provider is != pia, skipping incoming port assignment

2021-05-19 23:01:49,330 DEBG 'watchdog-script' stdout output:
[info] Deluge listening interface IP 0.0.0.0 and VPN provider IP 172.94.56.68 different, marking for reconfigure

2021-05-19 23:01:49,334 DEBG 'watchdog-script' stdout output:
[info] Deluge not running

2021-05-19 23:01:49,338 DEBG 'watchdog-script' stdout output:
[info] Deluge Web UI not running

2021-05-19 23:01:49,342 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2021-05-19 23:01:49,342 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Deluge...
[info] Removing deluge pid file (if it exists)...

2021-05-19 23:01:49,581 DEBG 'watchdog-script' stdout output:
[info] Deluge key 'listen_interface' currently has a value of '172.94.56.70'
[info] Deluge key 'listen_interface' will have a new value '172.94.56.68'
[info] Writing changes to Deluge config file '/config/core.conf'...

2021-05-19 23:01:49,276 DEBG 'start-script' stdout output:
[info] Successfully retrieved external IP address 172.94.56.68

2021-05-19 23:01:49,277 DEBG 'start-script' stdout output:
[info] Application does not require port forwarding or VPN provider is != pia, skipping incoming port assignment

2021-05-19 23:01:49,330 DEBG 'watchdog-script' stdout output:
[info] Deluge listening interface IP 0.0.0.0 and VPN provider IP 172.94.56.68 different, marking for reconfigure

2021-05-19 23:01:49,334 DEBG 'watchdog-script' stdout output:
[info] Deluge not running

2021-05-19 23:01:49,338 DEBG 'watchdog-script' stdout output:
[info] Deluge Web UI not running

2021-05-19 23:01:49,342 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2021-05-19 23:01:49,342 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Deluge...
[info] Removing deluge pid file (if it exists)...

2021-05-19 23:01:49,581 DEBG 'watchdog-script' stdout output:
[info] Deluge key 'listen_interface' currently has a value of '172.94.56.70'
[info] Deluge key 'listen_interface' will have a new value '172.94.56.68'
[info] Writing changes to Deluge config file '/config/core.conf'...

2021-05-19 23:01:49,748 DEBG 'watchdog-script' stdout output:
[info] Deluge key 'outgoing_interface' currently has a value of 'tun0'
[info] Deluge key 'outgoing_interface' will have a new value 'tun0'
[info] Writing changes to Deluge config file '/config/core.conf'...

2021-05-19 23:01:49,892 DEBG 'watchdog-script' stdout output:
[info] Deluge key 'default_daemon' currently has a value of 'e02ae3c7d0e949b1960dbce1e6a90c17'
[info] Deluge key 'default_daemon' will have a new value 'e02ae3c7d0e949b1960dbce1e6a90c17'
[info] Writing changes to Deluge config file '/config/web.conf'...

2021-05-19 23:01:50,166 DEBG 'watchdog-script' stdout output:
[info] Deluge process started
[info] Waiting for Deluge process to start listening on port 58846...

2021-05-19 23:01:50,395 DEBG 'watchdog-script' stdout output:
[info] Deluge process listening on port 58846

2021-05-19 23:01:52,738 DEBG 'watchdog-script' stdout output:
[info] No torrents with state 'Error' found

2021-05-19 23:01:52,739 DEBG 'watchdog-script' stdout output:
[info] Starting Deluge Web UI...

2021-05-19 23:01:52,739 DEBG 'watchdog-script' stdout output:
[info] Deluge Web UI started

2021-05-19 23:01:52,741 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2021-05-19 23:01:53,748 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2021-05-19 23:01:53,758 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

Edited by Philby1975
Link to comment
1 hour ago, Philby1975 said:

This is really starting to do my head in.

 

I have DelugeVPN setup and everything is working fine except for the torrents themselves.

 

All containers (SAB and Jacket) running through Deluge have the correct external IP and are accessible from the webui so I'm pretty sure I have done everything required from the Feb IP tightening; and pretty sure the torrents were working when this was done.

 

At first I suspected my VPN provider (PureVPN) and there outdated OPENVPN files, however, downloading from SAB I get the 4-5MB/s that I would expect from my ISP (I live in Australia), so the VPN is not causing a bottleneck.

 

Deluge torrents either don't download at all (no peers, just no activity at all) or it is extremely slow. Switch the vpn off and I can get the speeds I would expect.

 

Things I've tried:

 

Wiped Deluge, SAB and Jacket (including appdata files) and started again.

Installed Binhex qbittorrentvpn - same behaviour.

Tried running qbittorrent (without vpn) through deluge (mimicking SAB) - same behaviour.

 

PureVPN on windows or Kali work fine and I get expected speeds using speedtest.net

 

I'm at the point of setting up a Kali VM just for the torrent side of things, but that is presenting a whole different set of issues.

 

Any help is greatly appreciated.

First of all, you need to change your password asap, as it's in the log you posted.

Second, set the STRICT_PORT_FORWADING to no, this setting only applies to PIA users.

 

You need to have an open incoming port to get good speed. Have you port forwarded a port? It's unclear to me if purevpn offers port forwarding or not. In a quick google search, their website talks about port forwarding and what it is, but I can't see anything about if they offer port forwarding or not. I saw something about you need to download their app maybe? 

 

Are you on a private tracker? If so most of them require an open incoming port. And if you don't have it they won't let you download or it will be very slow. Try to download a well-seeded torrent on a public tracker, like a ubuntu ISO or something. Then you should at least be able to download, but the speed will be much slower than with an open incoming port. If you can download it on a public tracker you know it's definitely a port forwarding issue that's causing you to not be able to download on your private tracker.

 

And there's no point in testing the speed on speedtest.net, that only works for web browsing and web downloads. The speed you get on torrents has nothing to do with your web browsing/web download speed as many factors are taken into account with torrenting. The only thing speedtest.net will tell you is that you MAYBE can get that speed, if all the conditions are right.

Link to comment
34 minutes ago, strike said:

First of all, you need to change your password asap, as it's in the log you posted.

Have edited and blocked it out. I'm guessing the worst anyone can do is use my VPN to download some stuff so this isn't urgent ??

 

Will sort it out in the morning and try the other stuff you suggested. Thanks so much for your response Strike.

Link to comment

I seem to have lost access to the docker GUI and not sure how to resolve it.

 

Everything was working OK, but I recently got improved broadband so I was tweaking my preferences in the web GUI to reflect my better download/upload speeds.

I reloaded the page but now the web GUI won't load, and I'm not sure what to do to get it back. I tried restarting the docker and rebooted unraid to see if that resolved it but no dice.

 

The settings I changed in preferences were:

Network extras - just enabled DHT and Peer exchange

Bandwidth - changed max download and upload speeds; changed max hal-open connections

Queue - changed total active, total active downloading and total active seeding, enabled do not count slow torrents

 

That's it. I can't see how changing any of those would break it to the point I can't access the web GUI, so I can only assume it's just a coincidence and something else is afoot.

 

Can anyone help me get the web GUI back? TIA

 

EDIT: Thanks to Idaho121 below I know this is now a VPN issue associated with PIA not working

Edited by be4con
SOLVED
Link to comment

Everything was working fine until a few days ago. Then, Deluge stopped auto-loading/deleting torrent files from the relevant folder. Then, after I restarted to see if that would fix it, I can't get into the WebUI and I'm getting the following errors when loading:

 

2021-05-19 14:24:15 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-128-cbc' to --data-ciphers or change --cipher 'aes-128-cbc' to --data-ciphers-fallback 'aes-128-cbc' to silence this warning.

 

[warn] Unable to successfully download PIA json to generate token from URL 'https://privateinternetaccess.com/gtoken/generateToken'
[info] 10 retries left
[info] Retrying in 10 secs...

 

I downloaded new files from PIA and have tried a few different of their endpoints that are on the list and that others who have had this issue noted as working.

 

Any thoughts on what else to try?

 

Thanks!

Link to comment
3 minutes ago, Idaho121 said:

Everything was working fine until a few days ago. Then, Deluge stopped auto-loading/deleting torrent files from the relevant folder. Then, after I restarted to see if that would fix it, I can't get into the WebUI and I'm getting the following errors when loading:

 

2021-05-19 14:24:15 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-128-cbc' to --data-ciphers or change --cipher 'aes-128-cbc' to --data-ciphers-fallback 'aes-128-cbc' to silence this warning.

 

[warn] Unable to successfully download PIA json to generate token from URL 'https://privateinternetaccess.com/gtoken/generateToken'
[info] 10 retries left
[info] Retrying in 10 secs...

 

I downloaded new files from PIA and have tried a few different of their endpoints that are on the list and that others who have had this issue noted as working.

 

Any thoughts on what else to try?

 

Thanks!

Thanks! I just checked my log and I have the same error. Turned off the VPN and my web GUI is back - so mine was a PIA issue.

It looks like PIA is borked in the docker at the moment then

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.