[Support] binhex - DelugeVPN


Recommended Posts

If someone could please provide instructions on just this step for setting up WireGaurd for PIA I would be most appreciative.  I think I may need to do this through the counsel?

 

Quote

A21. Yes you are correct, all binhex VPN created images now support OpenVPN and WireGuard, for PIA and other VPN providers.

If you're a PIA user then please follow this procedure:-

1. Change Docker parameter from --cap-add=NET_ADMIN to --privileged=true (WireGuard requires privileged permissions).

 

I'm just not sure what file contains the parameter.  I went through many files in the config directory with nano and didn't see it anywhere.

 

Thanks,

craigr

Link to comment
27 minutes ago, craigr said:

I'm just not sure what file contains the parameter.

Check your docker run command for the container.  If set up properly, you will see it there.  You just need to set Privileged to On with the toggle switch in the container config

 

For reference here is my docker run command for DelugeVPN using wireguard for PIA:

 

docker run
  -d
  --name='DelugeVPN'
  --net='bridge'
  --privileged=true
  -e TZ="America/Denver"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="MediaNAS"
  -e HOST_CONTAINERNAME="DelugeVPN"
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'='xxxxxxxx'
  -e 'VPN_PASS'='xxxxxxxx'
  -e 'VPN_PROV'='pia'
  -e 'VPN_OPTIONS'=''
  -e 'STRICT_PORT_FORWARD'='yes'
  -e 'ENABLE_PRIVOXY'='no'
  -e 'LAN_NETWORK'='192.168.1.0/24'
  -e 'NAME_SERVERS'='192.168.1.60,209.222.18.222,8.8.8.8,209.222.18.218,8.8.4.4'
  -e 'DEBUG'='false'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -e 'VPN_CLIENT'='wireguard'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8112]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/deluge-icon.png'
  -p '8112:8112/tcp'
  -p '58846:58846/tcp'
  -p '58946:58946/tcp'
  -p '58946:58946/udp'
  -p '8118:8118/tcp'
  -v '/mnt/cache/appdata/DelugeData':'/data':'rw'
  -v '/mnt/cache/appdata/DelugeVPN':'/config':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-delugevpn:latest'

 

Link to comment

NEVERMIND. Fixed. Bazarr doesn't allow any special ways of excluding IPs for privoxy. You have to list each IP separately. No wildcards, no CIDR. I'm an idiot and can't read. 

 

 

On 9/23/2022 at 10:33 AM, strike said:

The last couple days privoxy is timing out, any reason why that might happen? The tunnel is up and everything is working except medusa and radarr is not finding anything because of privoxy timing out. This is the error I get in Medusa as an example. 

 HTTPConnectionPool(host='192.168.2.218', port=8118): Read timed out. (read timeout=30)

If I disable proxy in medusa and radarr they are able to reach the indexer and grab torrents and send them to deluge just fine. There is no error in the supervisord log either that I can see. 

 

 


I'm having this same issue. Bazarr has stopped working because it can't connect to Sonarr or Radarr even though I've told it to exclude those IPs. When I test Bazarr's communication to Sonarr or Radarr it times out on port 8118 which is Privoxy. 
If I turn off Privoxy in Bazarr it works fine. I like having all my arr traffic going through my VPN but it just doesn't seem to want to work for Bazarr.

Are there more ways to test Privoxy? 

Edited by sol
Link to comment
  • 2 weeks later...
  • 2 weeks later...

@binhex hate to tag you directly but I am still struggling to access the Deluge webUI remotely.  Is the VPN setup for split-tunnel so the webUI can operate on my local IP and the Deluge daemon can operate on the VPN IP?  Seems like not - is there a way to set this up?

Also, as I have asked and @Dschnell89 - is there a way to configure the Deluge GTK client?  I have tried to set this up while on my LAN and have failed.  The webUI works fine on the LAN - ideally I'd like to be able to access both remotely, but some remote access

(whether via the client or webUI) is really needed!

 

Thanks!!

Link to comment

Been battling deluge all morning.

 

My Deluge Web UI was prompting me for a password as is usual, and wouldn't accept my usual password.

 

Some how deluges web ui password had defaulted back to 'deluge'. However, when i tried to reset the password back to my previous peronsal password in the web ui, deluge would hang and crash and need a reboot to become responsive.

 

Seemed that my web.conf file was rammed full of stale sessions as the web.conf file had bloated up to 40MB in size and i think deluge was crasing due to it. Since deleting 99% of the stale sessions in my web.conf deluge loads up a lot quicker from a cold restart, is more responsive and also now allows me to save my password again in the web ui.

 

Leaving it here in case anyone else has this issue!

 

@binhex Should the stale sessions not be removed from the web.conf at some time?

Edited by thestraycat
Link to comment

I am back to having my webserver fail again. I can still get to the GUI, but it appears the internal access to what is going on keeps dying. My old tricks of just restarting the container aren't working, nor has clearing stale sessions from web.conf.

 

In checking the supervisor.log, I see this every time I lose access to the webserver:

2022-11-24 07:55:44,545 DEBG 'watchdog-script' stderr output:
Unhandled error in Deferred:

2022-11-24 07:55:44,548 DEBG 'watchdog-script' stderr output:

Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/twisted/internet/base.py", line 1318, in run
    self.mainLoop()
  File "/usr/lib/python3.10/site-packages/twisted/internet/base.py", line 1328, in mainLoop
    reactorBaseSelf.runUntilCurrent()
  File "/usr/lib/python3.10/site-packages/twisted/internet/base.py", line 994, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/lib/python3.10/site-packages/twisted/internet/task.py", line 251, in __call__
    d = maybeDeferred(self.f, *self.a, **self.kw)
--- <exception caught here> ---
  File "/usr/lib/python3.10/site-packages/twisted/internet/defer.py", line 205, in maybeDeferred
    result = f(*args, **kwargs)
  File "/usr/lib/python3.10/site-packages/deluge/core/alertmanager.py", line 60, in update
    self.handle_alerts()
  File "/usr/lib/python3.10/site-packages/deluge/core/alertmanager.py", line 128, in handle_alerts
    **{
  File "/usr/lib/python3.10/site-packages/deluge/core/alertmanager.py", line 129, in <dictcomp>
    attr: getattr(alert, attr)
builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 0: invalid continuation byte

 

The log shows the watchdog-script is still processing and it appears Deluge is still actively working, I just cannot access it.  What else can I check to find out what is killing the webserver?

Link to comment
33 minutes ago, MaxTrax said:

I am back to having my webserver fail again. I can still get to the GUI, but it appears the internal access to what is going on keeps dying. My old tricks of just restarting the container aren't working, nor has clearing stale sessions from web.conf.

 

In checking the supervisor.log, I see this every time I lose access to the webserver:

2022-11-24 07:55:44,545 DEBG 'watchdog-script' stderr output:
Unhandled error in Deferred:

2022-11-24 07:55:44,548 DEBG 'watchdog-script' stderr output:

Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/twisted/internet/base.py", line 1318, in run
    self.mainLoop()
  File "/usr/lib/python3.10/site-packages/twisted/internet/base.py", line 1328, in mainLoop
    reactorBaseSelf.runUntilCurrent()
  File "/usr/lib/python3.10/site-packages/twisted/internet/base.py", line 994, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/lib/python3.10/site-packages/twisted/internet/task.py", line 251, in __call__
    d = maybeDeferred(self.f, *self.a, **self.kw)
--- <exception caught here> ---
  File "/usr/lib/python3.10/site-packages/twisted/internet/defer.py", line 205, in maybeDeferred
    result = f(*args, **kwargs)
  File "/usr/lib/python3.10/site-packages/deluge/core/alertmanager.py", line 60, in update
    self.handle_alerts()
  File "/usr/lib/python3.10/site-packages/deluge/core/alertmanager.py", line 128, in handle_alerts
    **{
  File "/usr/lib/python3.10/site-packages/deluge/core/alertmanager.py", line 129, in <dictcomp>
    attr: getattr(alert, attr)
builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 0: invalid continuation byte

 

The log shows the watchdog-script is still processing and it appears Deluge is still actively working, I just cannot access it.  What else can I check to find out what is killing the webserver?

looks like a match:- https://dev.deluge-torrent.org/ticket/3427

 

sadly no resolution for it, so i dont know what to suggest other than try renaming your core.conf file and restart the container to regenerate it, maybe its a non utf-8 character in your config file.

 

@wipzcream looks like you have the exact same error.

Link to comment

I have a small problem with the binhex-delugevpn container. I followed this tutorial:

to "route" the binhex-prowlarr container traffic through the binhex-delugevpn container as this was suggested in some forums. But I'm not able to open the binhex-prowlarr webinterface anymore. even when I enter the ip and port manually.

when I use the console in the binhex-prowlarr container I can see that the vpn is working ( i tested that with command curl ifconfig.io) within the container. and it gives back the ip of the vpn just like when i use the command inside the binhex-deluge container.

I tried to start the containers in different orders since this was suggested by some user. 1st the deluge, then the prowlarr. but i also tried it the other way around. did not work either.

I suspect, that there might be a firewall inside the delugevpn that prevents me from connecting on port 9696.

But since I'm a linux novice I have no idea how to fix that.

Can anyone help me out ?

EDIT
 

sh-5.1# iptables --list
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  172.17.0.0/16        172.17.0.0/16       
ACCEPT     all  --  95.168.167.236       anywhere            
ACCEPT     all  --  95.168.167.236       anywhere            
ACCEPT     all  --  95.168.167.236       anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8112
ACCEPT     udp  --  anywhere             anywhere             udp dpt:8112
ACCEPT     tcp  --  192.168.1.0/24       172.17.0.0/16        tcp dpt:58846
ACCEPT     tcp  --  192.168.1.0/24       172.17.0.0/16        tcp dpt:privoxy
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  172.17.0.0/16        172.17.0.0/16       
ACCEPT     all  --  anywhere             95.168.167.236      
ACCEPT     all  --  anywhere             95.168.167.236      
ACCEPT     all  --  anywhere             95.168.167.236      
ACCEPT     tcp  --  anywhere             anywhere             tcp spt:8112
ACCEPT     udp  --  anywhere             anywhere             udp spt:8112
ACCEPT     tcp  --  172.17.0.0/16        192.168.1.0/24       tcp spt:58846
ACCEPT     tcp  --  172.17.0.0/16        192.168.1.0/24       tcp spt:privoxy
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
sh-5.1# iptables -A INPUT -

I think it does not work since I have the port 9696 nowhere in the IPTABLES of the delugevpn-container.


But I have no idea how to add the rule. Anyone got a clue ?

 

Edited by matuopm
Link to comment

Hi @binhex, thanks for all your amazing apps! I use quite a few! :)

 

I've been trying mostly successfully to setup a private tracker and have got stuck at the last bit, making delugevpn load the cookie script on tunnel up! The script works ok if I call it on cmd line, but if I add it to VPN_OPTIONS then the VPN fails to start, this is the suggested command: --script-security 2 --up /config/tun_up.sh

I'm guessing it's overriding your script? How do I achive this please?

Cheers,

Tim

Link to comment

Hi. Not sure if I am posting in the right spot but I've been having issues with binhex-delugevpn docker and slow download speeds ever since I transitioned to a new Ubiquiti router/network switch setup in my house. I thought I enabled all the required port forwarding rules but it just isn't performing. I tested downloading two identical torrents one on my laptop directly and one using delugevpn on my UNRAID (both connected to same VPN location server) and deluge had trouble connecting to the torrent even while my laptop using transmission downloaded at over 20MB/s within 30 seconds of starting torrent.  I used to get 40-50MB/s+ in download speeds and now I never get above a combined 4-5MB/s or it just won't connect period to those seeding (new releases with thousands of seeders in RARBG website search, not files with 1 or 2 seeders).

 

I'm not sure what gives but hoping others can help point me in right direction. I tried it-config plugin but upload speeds are way low.  I have a gigabit internet connection and laptop is on Wi-Fi while server is hardwired.  I don't know if this speedtest docker is testing my laptop I'm accessing it from or the actual server but posted a screenshot of that too. I read some posts about kinked cables reverting to 100mbs speeds but if that was the case shouldn't I not be able to register this internet speed in a test or play 4K Remux videos on direct play even locally in Plex?

 

Any ideas?

Screenshot 2022-12-05 at 5.26.25 PM.png

Screenshot 2022-12-05 at 5.27.59 PM.png

Screenshot 2022-12-05 at 5.32.54 PM.png

Screenshot 2022-12-05 at 5.40.33 PM.png

Screenshot 2022-12-05 at 5.43.12 PM.png

Link to comment
On 11/23/2022 at 8:34 AM, wipzcream said:

Dear binhex 

 

I can not access the webUI but few day ago, it work normally. It can not access after I attached many torrent file. the screen file show nothing and I attached again and restart Delugevpn after that  I can not access the WebUi until now 

 

please kindly check a log file as I attached 

Screenshot 2565-11-23 at 11.34.31.png

supervisord.log 5.18 kB · 2 downloads

 

On 11/27/2022 at 8:08 PM, vvolfpack said:

Much like others on this thread recently, my Web UI isn't loading anymore, but upon checking my log file, I'm seeing that privoxy is connecting and so is my ovpn file from PIA. I'm sure I'm missing something here. The only difference is that I upgraded my mobo, which didn't impact anything in my other containers 

supervisord.log 9.89 MB · 6 downloads

 

hello,

 

-stop the docker

-open up terminal and run

/sbin/modprobe iptable_mangle

-start container

-wait a bit then access the webGUI.

Edited by Tolete
  • Upvote 1
Link to comment

Sorry to bother, I tried searching through forums for both delugevpn and qbittorrenvpn.  Looks like some people have similar issues, but didn't find a solution.  For both delugevpn and qbittorrentvpn, I can spin up the containers with no problem.  I have my Webui pointed to port 7070, so I made sure to modify the docker compose to open 7070 and point webui to 7070, for both (deluge and qbt).  I've got wireguard set up, and it appears to connect fine.  I can ping the outside from within the container, so that's working.  

 

My issue is that I can't, for the life of me, get the Webui to connect, I keep getting a "took too long" timeout error.  Sonarr and Radarr both connect fine when testing port 7070.  I have qbt working through lscr.io/linuxserver/qbittorrent container, port 7070, no problem connecting to webui, but I'd prefer to use your built-in wireguard PIA connection.

 

I'm not terribly tech savvy, but I can follow instructions.  Any idea what's going on here?

Link to comment

Hey all.
I found about 15 threads on this topic but no solutions. I'm using all @binhex containers. Deluge, sonarr, radarr.
The issue is that when a torrent completed, deluge pauses it. radarr/sonarr both import the completed torrent. But they do not delete the torrent from cache, and they do not delete the torrent/extra crap that comes with the file from deluge.
I've confirmed that they can download the file.
I confirmed that deluge stops the torrent.
I've confirmed that sonarr/radarr both have the tickbox to remove the completed torrent.
I am not seeing any errors in any logs.

I have recently rebuilt the server. I've moved to a new server with more drives etc, and migrated my old everything, including restoring my dockers.
Prior to this, sonarr and radarr were deleting the files from cache upon ingestion, but they still weren't deleting the torrent and extra files.
Now I appear to have gone back a step and they're not even deleting the file on ingestion.
Please can I get some help with this, I must have read every thread on this topic and looked at every setting. (I've even tried the label addon in deluge and setting lables in the connection settings in radarr/sonarr. That didn't work, and caused errors on restart of deluge as deluge seems to disable the label addon on restart-neither here nor there really)

Spent days on this. Please someone help :(

Link to comment
10 hours ago, Meatballs said:

Hi, hello! 

I just got Deluge-openvpn to run, and everything seems fine.  Just worrying about the ports. I've set a manual upload port to 58946 in deluge web gui.  Do I also need to portforward this in my router? Is there anything else I have to do? 

No, so depending on the VPN you're using (presumably pia) you need to go into your pia account and forward a port from there. They will give you a port to use, and you plug that port into deluge.
Then you can add this magnet link as a torrent to deluge:
magnet:?xt=urn:btih:4d60844af7e42602086266fcde02971a4fea29cf&dn=checkmyiptorrent%20Tracking%20Link&tr=http%3a%2f%2f143.110.208.40%2f
It'll create a torrent that in the status tab under tracker status, will give you an error with the IP of your VPN connection.
Then you can use something like:
https://portchecker.co/
To plug in the IP from the error, and the port from pia you've put into deluge to see if it's working.
You don't need to worry about your router, because the router isn't the end point of the connection, the exit server of the vpn connection is the end point that other torrent clients will see and try to connect to.

Though depending on how you have your vpn set up, the server you connect to *may*change, when you restart the docker/server or something else maybe. So just keep an eye on that and if it does change use the port checker again, but pia should be able to keep the port forwarded regardless of external IP, just keep an eye on it periodically.

Edited by 4554551n
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.