[Support] binhex - DelugeVPN


8664 posts in this topic Last Reply

Recommended Posts

Posted (edited)
On 4/29/2021 at 9:11 AM, ados said:

Sorry I don't know what your asking.

Are you wanting to know if your NGINX is secure?

Well, yes, but probably no. NGINX seems to be a trustworthy product used by many big companies. It's more that I do not trust my knowledge about security to rely on my server setup and configuration of NGINX :-$ I can see that is working, but I have no idea if it's secure.

 

I'm now using Organizr as an authenticating wall in front of nginx. Your writeup helped me understand the concept, but I'm using Swag so I had to figure some of config out by myself (because I can't use NGINX Proxy Manager as a GUI to nginx in the Swag container - right?).

 

I still think I'm missing something here because it works great accessing/blocking all my container GUIs from WAN, except for the Ombi app. I'd guess that is because the app have no way of authenticating itself to Organizr. But, does that mean I have to leave it out of Organizer authentication all together, or is there a way to let the Ombi API through and still protect the GUI?
Maybe you can point me in the right direction @ados?

Edited by tetrapod
Clarification
Link to post
  • Replies 8.7k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

There has been an issue raised on GitHub related to tracker announce request IP leakage under certain circumstances, after careful review of iptables i have tightened up the rules to prevent this. A n

OK guys, multi remote endpoint support is now in for this image please pull down the new image (this change will be rolled out to all my vpn images shortly).   What this means is that the im

I wanted to summarize how I got Mullvad working with DelugeVPN as I had to piece together several "solutions" from different comments in this thread and there was some incorrect info; likely old.

Posted Images

Posted (edited)

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?

Edited by tetrapod
Link to post

Got an odd problem.

I can login with the local IP Address:port.

But if i try to login with my WAN Address (Using a Reverse Proxy and a Subdomain) it just accepts the password loads for a second and brings up the password screen again.

I've made sure the Daemon "Allow Remote Connections" is enabled and triple checked it in core.conf.

I want to add that this had been working for years.

I tried it on several browsers, thought it was a DNS issue, tried another PC because i was too lazy to flush the DNS on my main computer.

Went to Cloudflare tried toggling proxied off, made sure the IP Address was going directly to my WAN Address, same thing.

Turned proxying back because I"m about 99.9999999999% sure that's not the issue.

I mean, the interface loads up but it just won't let me login when trying to login with my reverse proxy.

Other containers let me login like your "binhex-sabnzbdvpn" Docker. SAB works fine.

 

Any ideas or know of anything else I can try?

Link to post
On 5/3/2021 at 5:08 AM, theoracle09 said:

I'm finally getting around to updating and getting things working again after the tightening. I've followed the stickied post and spent hours in the FAQ trying to get this working, but I can not get other docker web GUIs to load. b-delugevpn settings: 

 

463653760_Screenshotfrom2021-05-0219-47-23.png.78d50af211822056a3dd2b015d0f9e81.png

 

Lan Network is correct and been verified using the tool in Q4 on FAQ. I followed SpaceInvader One's video on routing through deluge and when typing "curl ifconfig.io" in each of the container's consoles I'm getting the IP from the vpn. Radarr's configuration:

 

414696827_Screenshotfrom2021-05-0219-52-15.png.263bc0c5885f0d2718271c89e81b0ede.png

 

As you can see the extra parameters are set, the network type is set to none, and I've removed any port designations. 

 

One thing I noticed is when the container starts, there's nothing under Port Mappings in the main docker page. See below:

 

326620368_Screenshotfrom2021-05-0219-54-31.png.4295f49945323a2a301853db1ec68254.png

 

I have never used NZB, I just downloaded it to see if the web gui would load, which it does not. I'm unable to get the web gui to load on any container going through delugevpn. I've changed ovpn files to try different servers, but still no web gui. Not using privoxy in Deluge. I've also made sure deluge was restarted then the other containers restarted once deluge is up and running, still no web guis. 

 

Radarr Log Output

Deluge Log Output

 

I've checked for spaces or weird line endings in the extra parameters box on each container, it's all correct. At this point I have no idea how to get the web guis to come back Thanks for any help!

I'm using about the same setup, but I'm only routing Jacket and NZBHydra through binhex-delugevpn. Are you sure you haven't switched which ports go where for the VPN ports? My config is this:
delugeconf.JPG.9be4b9aa9576f80f9188cff58a24f05a.JPG

 

Maybe It's me who got it wrong :-$ but I don't think so. Works fine between the dockers and Jacket and NZBHydra are accessing through the deluge VPN. There is no longer a WebUI alternative when clicking the docker, but that is not to be expected

 

Link to post
Posted (edited)

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 post
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 post
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 post
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 post

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 post
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 post
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 post

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 post
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 post
Posted (edited)

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 post
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 post
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 post
Posted (edited)
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 post
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 post

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 post
1 hour ago, Philby1975 said:

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

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.

Link to post
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 post
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 post
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 post
Posted (edited)

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 post
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 post

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.