5 minutes ago, binhex said:

its working here for me too, but im seeing a few people posting on my github repo about problems with the new image, so there looks to be something going on, no idea what yet, and as i mentioned i cannot replicate it yet. i suspect iptable module issue at present, link to issue:-

https://github.com/binhex/arch-delugevpn/issues/352

Good to know, I'll be watching this issue. If they all have airvpn I might know what the solution is. @Lamkam is using airvpn I can see from the little log snippet. I'll ask on the github issue if they can confirm which provider they're using.

13 hours ago, strike said:

https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=1223362

 

Ah so not only did I miss it, the question was only asked in the last month   So from the thread it seems like I cannot have a custom IP unless I forgo the web client and use a thin client instead.  Not a big issue, it just upsets my ocd as I like to have each of my docker instances on a separate IP so I can assign an internal DNS entry for them to look prettier  

Good to know, I'll be watching this issue. If they all have airvpn I might know what the solution is. @Lamkam is using airvpn I can see from the little log snippet. I'll ask on the github issue if they can confirm which provider they're using.

Issue now resolved, it was kernel module related as suspected.

Sent from my 22021211RG using Tapatalk

1 hour ago, headnoodle said:

Ah so not only did I miss it, the question was only asked in the last month   So from the thread it seems like I cannot have a custom IP unless I forgo the web client and use a thin client instead.  Not a big issue, it just upsets my ocd as I like to have each of my docker instances on a separate IP so I can assign an internal DNS entry for them to look prettier  

Yeah, I like to have most of my containers on a separate IP as well, for security reasons for the most part. As they are then isolated from the host. So I'm using the thin client for deluge. The only thing I miss that I can't get from the thin client, is to set up a reverse proxy. 

23 minutes ago, binhex said:

Issue now resolved, it was kernel module related as suspected.

Sent from my 22021211RG using Tapatalk
 

Nice work 😊

On 2/14/2023 at 10:07 AM, binhex said:

got bored of the ncp-disable and keysize fallout, new image has been pushed that automatically removes these options, if you see any user struggling ask them to update their image first, the same will be pushed out to the other vpn images shortly.

now pushed out to the other *vpn's hopefully that should reduce the support a bit.

21 hours ago, strike said:

Yeah, I like to have most of my containers on a separate IP as well, for security reasons for the most part. As they are then isolated from the host.

keep in mind also, even if somebody was able to get onto the container (a feat in itself) they would not be running as root and therefore would not be able to change iptables and would have a VERY restrictive view of your lan (defined via VPN_OUTPUT_PORTS), connecting to SMB/NFS would most definitely not be possible - just thought i would send you the warm and fuzzies so you sleep better at night 🙂

48 minutes ago, binhex said:

keep in mind also, even if somebody was able to get onto the container (a feat in itself) they would not be running as root and therefore would not be able to change iptables and would have a VERY restrictive view of your lan (defined via VPN_OUTPUT_PORTS), connecting to SMB/NFS would most definitely not be possible - just thought i would send you the warm and fuzzies so you sleep better at night 🙂

Haha  I do feel a bit warmer and fuzzier now that you mention it. But this is the container I trust the most so I wasn't really worried about that. If it weren't for all my other containers  running on br0 with a separate IP I would run this container in bridge so I could reverse proxy it. But I can live with just the thin client, it works well.

Hi All - Firstly apologies if this has been answered before but a search hasn't returned anything (indeed - across all of the web).

I've got a QNAP TS-253D, running QTS 5.0.1.2277 and have previously managed to install Binhex DelugeVPN sucessfully. Indeed, it was working fine until my NAS had a fit and reset itself two days' ago.  I had to restore the whole thing and am trying to get deluge to work again, but struggling.

Here's the script I've used:

 

docker run -d \
    --cap-add=NET_ADMIN \
    -p 8112:8112 \
    -p 8118:8118 \
    -p 58846:58846 \
    -p 58946:58946 \
    --name=arch-delugevpn-noiptable \
    -v /share/Data/Multimedia/:/data \
    -v /share/Deluge_Config/:/config \
    -v /etc/localtime:/etc/localtime:ro \
    -e VPN_ENABLED=yes \
    -e VPN_USER=HIDDEN \
    -e VPN_PASS=HIDDEN \
    -e VPN_PROV=custom \
    -e VPN_CLIENT=openvpn \
    -e STRICT_PORT_FORWARD=yes \
    -e ENABLE_PRIVOXY=no \
    -e LAN_NETWORK=192.168.1.0/24 \
    -e NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 \
    -e DELUGE_DAEMON_LOG_LEVEL=info \
    -e DELUGE_WEB_LOG_LEVEL=info \
    -e DELUGE_ENABLE_WEBUI_PASSWORD=no \
    -e VPN_INPUT_PORTS=1234 \
    -e VPN_OUTPUT_PORTS=5678 \
    -e DEBUG=false \
    -e UMASK=000 \
    -e PUID=0 \
    -e PGID=0 \
binhex/arch-delugevpn

 

It fails with the following:

 

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

2023-02-16 14:25:39.694292 [info] System information Linux b34df69e29cd 5.10.60-qnap #1 SMP Thu Jan 12 04:39:10 CST 2023 x86_64 GNU/Linux
2023-02-16 14:25:39.758800 [info] OS_ARCH defined as 'x86-64'
2023-02-16 14:25:39.868760 [info] PUID defined as '0'
2023-02-16 14:25:40.315795 [info] PGID defined as '0'
2023-02-16 14:25:40.654673 [info] UMASK defined as '000'
2023-02-16 14:25:40.708448 [info] Setting permissions recursively on '/config'...
2023-02-16 14:25:40.810840 [info] Deleting files in /tmp (non recursive)...
2023-02-16 14:25:40.878506 [info] VPN_ENABLED defined as 'yes'
2023-02-16 14:25:40.931985 [info] VPN_CLIENT defined as 'openvpn'
2023-02-16 14:25:40.987334 [info] VPN_PROV defined as 'custom'
2023-02-16 14:25:41.060807 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/uk-man.prod.surfshark.comsurfshark_openvpn_udp.ovpn
2023-02-16 14:25:41.295337 [info] VPN remote server(s) defined as '91.90.121.221,'
2023-02-16 14:25:41.335567 [info] VPN remote port(s) defined as '1194,'
2023-02-16 14:25:41.377641 [info] VPN remote protcol(s) defined as 'udp,'
2023-02-16 14:25:41.423962 [info] VPN_DEVICE_TYPE defined as 'tun0'
2023-02-16 14:25:41.469512 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
91.90.121.221
2023-02-16 14:25:41.552339 [crit] iptables kernel module 'ip_tables' not available, exiting script...

 

Does anyone know how I fix the ip_tables not being available please?

Echoing the ip_tables issue on the :latest branch. Switching back to 2.1.1-3-02 allowed the container to boot.

This appeared in the last day or so, likely as a result of the IPV6 issue that was fixed.

On 1/1/2023 at 1:20 PM, ategan said:

Hello, I have some problems with the configuration.

 

I use ProtonVPN with DelugeVPN. The VPN tunnel goes up well, I recover an ip well.

 

However, I cannot connect Sonarr or Radarr to DelugeVPN.

 

I tried to tweak the VPN_INPUT_PORTS and VPN_OUTPUT_PORTS but nothing worked...

All docker images are on the same Vlan (520).
I can access DelugeVPN's web interface.

 

I specify: Only DelugeVPN is mounted on the VPN, Sonarr and Raddar are on my local network (Vlan 520) and therefore not affected by the VPN.

 

I think I'm close to succeeding, but I'm missing a piece of configuration that I haven't found yet (Unraid Forum, Github, Reddit..).

I don't know if I should use Privoxy? I don't see the use of it in my case.

 

Here are some screenshots of my current conf.

 

Thank you in advance for your help.

 

Thank you Binhex for your work!

sorry for my English

 

Hello, I live the exact same situation with Deluge, Sonarr and Radarr.  Did you manage to get it working?

4 hours ago, kae said:

Echoing the ip_tables issue on the :latest branch. Switching back to 2.1.1-3-02 allowed the container to boot.

This appeared in the last day or so, likely as a result of the IPV6 issue that was fixed.

You're an absolute saviour.  Thanks!

You're an absolute saviour.  Thanks!

Now you've rolled back please execute iptables -S inside of the container and paste the output please

Sent from my 22021211RG using Tapatalk

Hi All,

 

I started experiencing issues a while back where internet was dropping out and reconnecting every 30 mins or so. I run a virgin media superhub 3 in modem only mode into a PFSense box and out to my network. It is a separate box to UnRaid. I was convinced the issue was PFSense related since I only made the switch recently, but having been all over the forums and trying loads of different fixes the problem still remains.

 

Then the other day I took my Dockers offline for some maintenance and I noticed the issue wasn’t happening...! So then I turned them all off and on until I pinpointed binhex deluge vpn as the issue. I dont want to switch it off and i dont want to move to something else because it’s an awesome solution.

 

Currently on 2.1.1-3-01 as the latest update seemed to break the docker entirely.

 

Anyone got any idea's what might be causing this?

 

TIA

1 hour ago, dukeminster said:

I run a virgin media superhub 3 in modem only mode

i would suspect this is your issue, basically its cheap underpowered hardware, best thing you can do is dial down the number of connections in deluge and ensure you limit upload and download speeds to a max of 80% of your line speed.

On 2/17/2023 at 4:07 AM, binhex said:

Now you've rolled back please execute iptables -S inside of the container and paste the output please

Sent from my 22021211RG using Tapatalk
 

Here's the output from 2.1.1-3-02 (Docker on Windows)

sh-5.1# iptables -S
-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 181.214.206.231/32 -i eth0 -j ACCEPT
-A INPUT -s 191.96.168.215/32 -i eth0 -j ACCEPT
-A INPUT -s 191.96.168.218/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.1.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
-A INPUT -s 192.168.1.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 wg0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d 181.214.206.231/32 -o eth0 -j ACCEPT
-A OUTPUT -d 191.96.168.215/32 -o eth0 -j ACCEPT
-A OUTPUT -d 191.96.168.218/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.1.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.1.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 wg0 -j ACCEPT
sh-5.1# 

Here's the output from 2.1.1-3-02 (Docker on Windows)

sh-5.1# iptables -S
-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 181.214.206.231/32 -i eth0 -j ACCEPT
-A INPUT -s 191.96.168.215/32 -i eth0 -j ACCEPT
-A INPUT -s 191.96.168.218/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.1.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
-A INPUT -s 192.168.1.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 wg0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d 181.214.206.231/32 -o eth0 -j ACCEPT
-A OUTPUT -d 191.96.168.215/32 -o eth0 -j ACCEPT
-A OUTPUT -d 191.96.168.218/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.1.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.1.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 wg0 -j ACCEPT
sh-5.1# 

You are a bit late to the party, problem is solved, pull down latest

Sent from my 22021211RG using Tapatalk

Hello people:)

 

I've got a problem. I cant make sonarr go through the delugevpn..  (Privoxy)??

I can see that it's been a problem before.. But i cant find the solution .. Please help:)

 

regards

On 2/18/2023 at 6:13 PM, binhex said:

You are a bit late to the party, problem is solved, pull down latest

Sent from my 22021211RG using Tapatalk
 

 

(Apols if this posts twice but I just submitted and it didn't appear - same thing happened last time I posed - strange)

Sorry for being late, have been away.

Just re-installed with the latest image and all seems fine, thanks.

However, I went into Settings in Container Station (as said previously I'm running this on a QNAP TS-253D), selected Auto Start, the Container restarted and failed to come back up as it says it's missing the OpenVPN config file.  I think it must've come back up (or re-installed?) somewhere else as the file is definately there and also the Supervisord.log file stops when the container shut down.

I've included the initial Supervisord.log, the cut n paste of the log from the screen of the new instance and some screenshots of the Container Station Settings.

Any ideas what might be wrong - as I said before - I've had this running fine for ages before my NAS crashed and I had to re-initialise it!

 

supervisord.log

I just updated from 6.9.2 to 6.11.5 and deluge stopped working. it shows the green icon indicating the container is up but I can't access the ui. I saw a lot of previous comments about pia and dns stuff, but I changed nothing on the deluge setup and I run the exact same torguard vpn config on my binhex-qbittorrentvpn (which is working fine!)

 

using binhex/arch-delugevpn

https://pastebin.com/czqdCXq7

 

is the problem related to this info? if yes, how can I solve/run this?

[info] unRAID/Ubuntu users: Please attempt to load the module by executing the following on your host: '/sbin/modprobe iptable_mangle'

 

thanks!

Edited February 20, 20233 yr by timmyx

21 minutes ago, timmyx said:

is the problem related to this info

nope, you got permissions issues, its a known unraid bug:-
 

cat: /config/hostlist.conf: Permission denied

stop the container and delete /config/perms.txt then start the container, it will take longer to start but should then start correctly.

1 hour ago, mike_walker said:

Any ideas what might be wrong - as I said before - I've had this running fine for ages before my NAS crashed and I had to re-initialise it!

whats the ip address of the machine running the web browser you are attempting to connect to the deluge web ui?.

7 minutes ago, binhex said:

whats the ip address of the machine running the web browser you are attempting to connect to the deluge web ui?.

I'm accessing from my pc which is 192.168.1.126.  I'm logging onto the NAS hosting the container and that is 192.168.1.1.  The deluge webUI isn't up though cos it won't start (because of the missing OpenVPN config file.

3 minutes ago, mike_walker said:

The deluge webUI isn't up though cos it won't start (because of the missing OpenVPN config file.

you attached log said otherwise, you need to get your openvpn config file from your vpn provider in that case.

3 minutes ago, binhex said:

you attached log said otherwise, you need to get your openvpn config file from your vpn provider in that case.

 

Sorry, I think there's a mis-understanding. I installed and it worked (as the config file is in the/config/openvpn folder that was created) but then when I restarted the container it couldn't find the config file - I think it's re-started somewhere else (which is missing the config file) but don't know where.