I've been sick of my sluggish QNAP for some time so I've just moved over to unRAID and I'm loving it.

I used to run the delugevpn container on my QNAP and it worked flawlessly, however I've spent hours trying to get it to work in docker on unRAID.

It seems that DNS resolution fails once the vpn is connecting, and it fails to connect. (Although it resolves the VPN endpoint as I can see in the logs).

 

VPN config below, with endpoints removed.

I had to change the cipher as it was complaining about AES-128-CBC not being available as per your FAQ.

 

name servers were changed to my VPN providers in the config page in unRAID.

 

remote-random
remote <vpn1> 12200
remote <vpn1> 26000
remote <vpn1> 88
;comment the 3 options above and leave only port 53 for better firewall by-passing support
;remote <vpn1> 53
proto udp
dev tun
tls-client
persist-key
nobind
pull
redirect-gateway def1
;route-delay 3
verb 3
remote-cert-tls server
auth SHA256
auth-user-pass credentials.conf
cipher AES-128-GCM
mute-replay-warnings
key-direction 1
explicit-exit-notify 2
persist-remote-ip

 

Console logs showing the stalled state, which then just repeats.

 

2024-10-17 12:45:39,195 DEBG 'start-script' stdout output:
[debug] OpenVPN command line:- /usr/bin/openvpn --reneg-sec 0 --mute-replay-warnings --auth-nocache --setenv VPN_PROV 'custom' --setenv VPN_CLIENT 'openvpn' --setenv DEBUG 'true' --setenv VPN_DEVICE_TYPE 'tun0' --setenv VPN_ENABLED 'yes' --setenv VPN_REMOTE_SERVER 'vpnendpoint.123' --setenv APPLICATION 'deluge' --script-security 2 --writepid /root/openvpn.pid --remap-usr1 SIGHUP --log-append /dev/stdout --pull-filter ignore 'up' --pull-filter ignore 'down' --pull-filter ignore 'route-ipv6' --pull-filter ignore 'ifconfig-ipv6' --pull-filter ignore 'tun-ipv6' --pull-filter ignore 'dhcp-option DNS6' --pull-filter ignore 'persist-tun' --pull-filter ignore 'reneg-sec' --up /root/openvpnup.sh --up-delay --up-restart --keepalive 10 60 --auth-user-pass credentials.conf --cd /config/openvpn --config '/config/openvpn/vpnendpoint-aes128-udp.ovpn' --remote <vpn endpoint> 12200 udp --remote <vpn endpoint> 12200 udp --remote <vpn endpoint> 12200 udp --remote-random
[info] Starting OpenVPN (non daemonised)...

2024-10-17 12:45:39,544 DEBG 'start-script' stdout output:
2024-10-17 12:45:39 Note: Kernel support for ovpn-dco missing, disabling data channel offload.

2024-10-17 12:45:39,546 DEBG 'start-script' stdout output:
2024-10-17 12:45:39 WARNING: file 'credentials.conf' is group or others accessible
2024-10-17 12:45:39 OpenVPN 2.6.11 [git:makepkg/ddf6bf6d2a135835+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Jun 20 2024

2024-10-17 12:45:39,547 DEBG 'start-script' stdout output:
2024-10-17 12:45:39 library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10
2024-10-17 12:45:39 DCO version: N/A

2024-10-17 12:45:39,550 DEBG 'start-script' stdout output:
2024-10-17 12:45:39 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2024-10-17 12:45:39,553 DEBG 'start-script' stdout output:
2024-10-17 12:45:39 TCP/UDP: Preserving recently used remote address: [AF_INET]<vpn endpoint>:12200
2024-10-17 12:45:39 Socket Buffers: R=[212992->212992] S=[212992->212992]
2024-10-17 12:45:39 UDPv4 link local: (not bound)

2024-10-17 12:45:39,554 DEBG 'start-script' stdout output:
2024-10-17 12:45:39 UDPv4 link remote: [AF_INET]<vpn endpoint>:12200

2024-10-17 12:46:39,665 DEBG 'start-script' stdout output:
2024-10-17 12:46:39 [UNDEF] Inactivity timeout (--ping-restart), restarting

2024-10-17 12:46:39,667 DEBG 'start-script' stdout output:
2024-10-17 12:46:39 SIGHUP[soft,ping-restart] received, process restarting

2024-10-17 12:46:39,677 DEBG 'start-script' stdout output:
2024-10-17 12:46:39 Note: Kernel support for ovpn-dco missing, disabling data channel offload.

2024-10-17 12:46:39,678 DEBG 'start-script' stdout output:
2024-10-17 12:46:39 WARNING: file 'credentials.conf' is group or others accessible

 

Looking at resolv.conf I can see all my vpn providers nameservers in there.

I'm beginning to think it's an iptables issue which isn't allowing outbound DNS to them as it only shows the VPN endpoint really, no nameservers listed. Perhaps I'm barking up the wrong tree.

 

I do use pihole for DNS, but it doesn't look like the container should use it. I also don't have any outbound firewall filtering going on. DNS works when I disabled the VPN in the container too.

 

Any help would be great appreciated.

 

Cheers

 

Edited October 17, 20241 yr by neiljones
added comment about local DNS

2 hours ago, neiljones said:

[UNDEF] Inactivity timeout (--ping-restart), restarting

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

I posted an issue in General Support with the title "Space Invader One Please Help Me" I was told I should have posted it here. Tried to move it here with no luck.

On 10/9/2024 at 11:42 AM, strike said:

You need to check if your vpn provider offers port forwarding and then open up a port and put that port as the incoming port in Deluge. Torrenting without an open incoming port will always be slow. 

Yes and its setup properly, else uploading wouldn't be possible!
Its UPNP and I've been with them for a while now. It was working before, not sure whats going on nowaday.

I have been using this setup found from Space Invaders (YouTube) for years but a couple of days ago it stoped working. After some looking it seems that the issue is the Google extension that pushes the torrent files over DelugeVPN which is a container in Unraid. This has been working fine for years but stoped working and I can't find a fix. Any help would be great.

On 10/14/2024 at 2:53 PM, boianski said:

For some odd reason I can only add one torrent file at a time. When I try to bulk add more than one file and click the add button, nothing happens. But if I choose only one file, it adds it no problem. This problem has persisted for a while. The docker is up to date. The OS is latest. I've tried multiple browsers. 

 

Anyone seen this before and if so is there a fix? Thank you! 

 

I reported this back in May in this very thread. Others have noticed it also.

 

Is there any way this can get some traction? It's frustrating when you're trying to add 10+ torrents, but you can only click the add button if there is only one torrent selected. It was working fine until about mid-late May. Since then, you can't click the add button if multiple torrents are selected.

Hello all. I've been using Binhex DelugeVPN for a few years now. I monitor it periodically and make sure the vpn is on and working. However I just recently read somewhere about other download clients and vpn binding so that if the vpn is down the client will not download anything. I've tried googling this but havent found a direct answer yet. So my question is, is the vpn in binhex delugevpn binded and will it stop downloading if the vpn disconnects for any reason. I havent had any issues with the vpn side of things so I dont have any first hand experience to say one way or the other. Is there a way I can test this as well? and what would be the best way of going about testing this.

15 hours ago, PlayLoud said:

 

I reported this back in May in this very thread. Others have noticed it also.

 

Is there any way this can get some traction? It's frustrating when you're trying to add 10+ torrents, but you can only click the add button if there is only one torrent selected. It was working fine until about mid-late May. Since then, you can't click the add button if multiple torrents are selected.

Unless this issue is directly related to the way in which I am building this image (unlikely) then your best bet is to post this on the deluge bug board here. Please keep in mind I am not a member of the deluge developer team, I am simply packaging up what is produced by the application developer(s).

FYI I have replicated the issue you are seeing, def looks like a bug in deluge to me, no sign of python traceback in the log.

You?

11 hours ago, milo15618 said:

However I just recently read somewhere about other download clients and vpn binding

Binding to the virtual adapter is a qbittorrent feature, deluge does not have this but you can bind to the ip address, which i do for you automatically.

11 hours ago, milo15618 said:

is the vpn in binhex delugevpn binded and will it stop downloading if the vpn disconnects for any reason.

See above for question 1, and yes to the second part, see Q1 here.

 

5 hours ago, binhex said:

Unless this issue is directly related to the way in which I am building this image (unlikely) then your best bet is to post this on the deluge bug board here. Please keep in mind I am not a member of the deluge developer team, I am simply packaging up what is produced by the application developer(s).

FYI I have replicated the issue you are seeing, def looks like a bug in deluge to me, no sign of python traceback in the log.

You?

Thank you for replying! The post you linked wasn't me, but I'm glad to see somebody has already reported it to Deluge. I'm still learning about Dockers and how they work. I'll follow the thread you linked on the Deluge board and check out their bug board. Thank you again!

On 10/23/2024 at 3:54 AM, binhex said:

Unless this issue is directly related to the way in which I am building this image (unlikely) then your best bet is to post this on the deluge bug board here. Please keep in mind I am not a member of the deluge developer team, I am simply packaging up what is produced by the application developer(s).

FYI I have replicated the issue you are seeing, def looks like a bug in deluge to me, no sign of python traceback in the log.

You?

Somebody from Deluge replied to that post...
 

Quote

Thanks, I did some testing, and it wasen't deluge or libtorrent related, but culprit seemingly python 3.12.x specifically, which was my least hunch/test-case honestly, as works fine in GTK-UI. Can use console-UI with globbing meanwhile as quick workaround(or GTK-UI as said), and i'm gonna locate the issue and make a ticket one of these day, or is the plan atleast. Thanks for reporting good-fellas

 

On 10/17/2024 at 3:40 PM, binhex said:

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

Thanks for responding @binhex. I'm still stumped though. 

 

Most of these check fine, although I'm not sure about the outbound connections through unRaid but I don't have any firewall/network restrictions enabled, and everything else works fine without issue.

 

Any other suggestions would be greatly appreciated.

 

Cause: Out of date ovpn config file containing reference to retired VPN remote server(s).
Solution: Download the latest ovpn config file from your VPN provider, place in /config/openvpn/ and restart container.

Check: Servers are active and are used on my other systems

 

Cause: Your subscription has run out
Solution: Double check this on the vpn providers website.

Check: Still actively used

 

Cause: VPN provider has a major outage.
Solution: Contact VPN provider to confirm outage and wait for the outage to be resolved.

Check: NA

 

Cause: Hardware firewall/router is blocking outbound connections to the vpn providers servers.
Solution: Allow outbound connections for the port defined in the VPN providers ovpn file on your firewall/router.

Check: No outbound firewall, working across my other devices

 

Cause: Host machine firewall blocking the docker container from connecting to the vpn providers servers.
Solution: Allow outbound connections for the port defined in the VPN providers ovpn file on the hosts firewall.

Check: Not sure how to definitively check this from the container. I don't have any host firewall enabled, and other services are running fine from my unRaid server

 

Cause: VLAN blocking the connection for the host to the VPN providers servers.
Solution: Allow outbound connections for the port defined in the VPN providers ovpn file on your switch.

Check: NA

 

Cause: ISP is hijacking DNS lookup and redirecting you to their (spammy) landing page.
Solution: Contact ISP and disable DNS redirection, Virgin UK and SKY ISP's have a website where you can disable it.

Check: Confirmed I'm using my specified DNS servers

 

Cause: ISP is blocking outbound connections to the VPN providers servers.
Solution: Use an IP based ovpn config file instead, this wil circumvent the requirement to do a name lookup.

Check: VPN works on other devices on the same network

On 10/17/2024 at 1:01 PM, neiljones said:

name servers were changed to my VPN providers in the config page in unRAID.

I would advise against this, VPN providers sometimes block name lookup until the tunnel is established, this can lead to a catch-22 situation - cannot create tunnel as cannot resolve name, cannot resolve name as you cannot create the tunnel, instead set NAME_SERVERS to '1.1.1.1' then try again.

 

On 10/17/2024 at 1:01 PM, neiljones said:

I do use pihole for DNS,

If you are using pihole for DNS then it's likely you are blocking or redirecting name server lookup to your pihole, ensure this is not the case and name server lookup on port 53 is permitted.

1 hour ago, binhex said:

I would advise against this, VPN providers sometimes block name lookup until the tunnel is established, this can lead to a catch-22 situation - cannot create tunnel as cannot resolve name, cannot resolve name as you cannot create the tunnel, instead set NAME_SERVERS to '1.1.1.1' then try again.

 

If you are using pihole for DNS then it's likely you are blocking or redirecting name server lookup to your pihole, ensure this is not the case and name server lookup on port 53 is permitted.

Thanks for coming back to me so quickly.

 

I've changed the DNS servers to 1.1.1.1 as you suggested. No dice. I changed the unRAID DNS server to be 1.1.1.1. Still no dice.

In the console of the container I can ping google.com, and even when I change iptables to allow everything in/out, it still doesn't work. Can't think of anything on the network that would be blocking this...🤷‍♂️

 

Looking at iptables after container creation, the DNS server isn't in there:

 

[root@2711b8f0133c /]# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  172.17.0.0/16        172.17.0.0/16       
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        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     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  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  172.17.0.0/16        172.17.0.0/16       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
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     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Edited October 29, 20241 yr by savethemanual
Added iptables details

On 10/23/2024 at 3:54 AM, binhex said:

Unless this issue is directly related to the way in which I am building this image (unlikely) then your best bet is to post this on the deluge bug board here. Please keep in mind I am not a member of the deluge developer team, I am simply packaging up what is produced by the application developer(s).

FYI I have replicated the issue you are seeing, def looks like a bug in deluge to me, no sign of python traceback in the log.

You?

 

On 10/23/2024 at 9:44 AM, PlayLoud said:

Thank you for replying! The post you linked wasn't me, but I'm glad to see somebody has already reported it to Deluge. I'm still learning about Dockers and how they work. I'll follow the thread you linked on the Deluge board and check out their bug board. Thank you again!

 

On 10/26/2024 at 12:14 AM, PlayLoud said:

Somebody from Deluge replied to that post...

Quote

Thanks, I did some testing, and it wasen't deluge or libtorrent related, but culprit seemingly python 3.12.x specifically, which was my least hunch/test-case honestly, as works fine in GTK-UI. Can use console-UI with globbing meanwhile as quick workaround(or GTK-UI as said), and i'm gonna locate the issue and make a ticket one of these day, or is the plan atleast. Thanks for reporting good-fellas

 

For anybody who has been following this, I downloaded Deluge for Windows and set it up as a thin client that connects to my unRAID DelugeVPN docker. While not a "fix" for Deluge's docker issue, it is definitely a workaround.

Edited October 29, 20241 yr by PlayLoud

They added more information, but it's all Greek to me.
 

Quote

Edit: Apologies, seemingly not python312 itself anyway, something else triggering it which followed the py312 deluge install - will investigate more and follow up later, and sorry again for wrong info.

Quote

As stated in my previous post's edit, I was wrong in this issue being about python 3.12, sorry again.

Anyway, just located the issue to twisted 24.x, which already is pinned for win32 as '<23', for a couple issues there, and apparently it goes beyond win32, atleast for 24.x. I submitted a PR to extend the pin to non-win32 also, as '<24'.

You can downgrade twisted e.g. with pip, though e.g. 'pip install twisted[tls]==23.8', but if distro incorporating pep668 then need a venv or --break-system-packages flag etc.

Just wanted expand as promised some time ago, sorry for slowness getting back into.

Quote

DjLegolas is already looking into some problems with twisted, but its rather complex and will obviously only apply to develop until a stable release is published.

 

On 10/29/2024 at 1:39 PM, savethemanual said:

Thanks for coming back to me so quickly.

 

I've changed the DNS servers to 1.1.1.1 as you suggested. No dice. I changed the unRAID DNS server to be 1.1.1.1. Still no dice.

In the console of the container I can ping google.com, and even when I change iptables to allow everything in/out, it still doesn't work. Can't think of anything on the network that would be blocking this...🤷‍♂️

 

Looking at iptables after container creation, the DNS server isn't in there:

 

[root@2711b8f0133c /]# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  172.17.0.0/16        172.17.0.0/16       
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        anywhere            
ACCEPT     all  --  <vpn endpoint>        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     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  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  172.17.0.0/16        172.17.0.0/16       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
ACCEPT     all  --  anywhere             <vpn endpoint>       
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     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

 

After trying everything I could think of, I changed the VPN endpoint to another one and it worked. What a faff. The original endpoint still works on other devices, but just not within this container for some reason. Problem solved bypassed.

Thanks for your help anyway @binhex

 

On 11/1/2024 at 4:12 AM, PlayLoud said:

They added more information, but it's all Greek to me.

OK so in a nutshell the deluge dev's are saying a bump in the version a Python module called 'twisted' that deluge relies upon is causing the issue, their workaround for now is to downgrade twisted, this is sadly easier said than done when you are using a rolling distro such as arch linux. I will have a think about it and see if i can come up with a workaround for now, but the real fix is for the deluge dev's to fix the incompatibilities with the latest version of twisted with deluge. 

Hello,

I have been using delugevpn for years with no problems. 

I recently decided to harden my network security with segmentation and thus enforcing new firewall rules.

The first rules generally implemented are :

- allow established and related traffic from any source to any destination

- drop invalid state from any source to any destination

 

The second rule blocks deluge. I can't access webui from my laptop in the same subnet. No error message is displayed in debug mode in supervisor log. 

As soon as i pause this rule i recover access to deluge ui.

I don't really understand why. Deluge container is setup with custom macvlan network.

 

And also all binhex containers (not only vpn enabled containers) that i have setup with macvlan network don't display ip and port on the unraid docker page. That's not the case for containers from linuxserver.

 

I have defined the container's network under `LAN_NETWORK` but still requests to other containers on the same network go out to the nameserver defined under `NAME_SERVERS`. I cannot resolve names from other containers within the container's shell. I couldn't find what I might have misconfigured. Does anyone have an idea?

Hey Team - how can I force Deluge to prevent downloading of risky file extensions such as what is listed in this pastebin

https://pastebin.com/yQJEaH1a

Hey there,

 

I've been having slow/ intermittent downloads. I added more OpenVPN files (NordVPN UDP) to hopefully give it more options to connect to if one goes down or is slow. After a restart, it is far better but I wanted to confirm that the behaviour I am looking for is happening.  I've reviewed all the configs in the deluge parent folder (config location on setup). Is this feature to "cycle" connections built into deluge or am I missing something to configure this properly?

 

Cheers,

Hi all,

 

I have a strange problem with my delugevpn container for the webui and getting a IP  address. If I connect the container with the Bridge network (192.168.50.0/24) everything works fine. But if I use a costume network like custom: br2 -- Name  (192.168.70.0/24), The container will not get an IP address and there  is no port mapping. The vlan are configured the exact same way and het the same firewall rules. And other containers in the same vlan work fine.

 

Is there and config that I missed to configure?

 

using:

unraid 6.12.14

wiregaurd config

 

 

 

Edited November 29, 20241 yr by Basgev
extra info

On 11/27/2024 at 7:58 PM, IhasPeanut said:

I added more OpenVPN files (NordVPN UDP) to hopefully give it more options to connect to

This is not how this image works, it wont cycle through multiple openvpn config files, instead if you want to multiple remote endpoints then specify them in a single config file - Please see Q20 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Hi Guys

 

I am unable to log in to deluge - I know the password, but everytime I try to log in I get an error message saying "Login Failed - You entered an incorrect password". I am not sure if the password has somehow become corrupt or someone has managed to get in and change it - but sonarr and radarr are also saying they cant connect - so I am not sure what has gone wrong.

 

I am searching for a way of resetting the password, or removing it to allow me to reconfigure the system... can anyone advise?

 

Many thanks