[Support] binhex - DelugeVPN


Recommended Posts

1 hour ago, Lamkam said:

Since last image update of today, it's failing. Looks like its looping and restarting constantly. Logs do not show anything useful.

 

Havent changed any settings or anything since ages for this container, and was always working fine. Any ideas?

 

Created by...
___.   .__       .__
\_ |__ |__| ____ |  |__   ____ ___  ___
 | __ \|  |/    \|  |  \_/ __ \\  \/  /
 | \_\ \  |   |  \   Y  \  ___/ >    <
 |___  /__|___|  /___|  /\___  >__/\_ \
     \/        \/     \/     \/      \/
  https://hub.docker.com/u/binhex/
2023-02-14 18:51:34.371998 [info] System information Linux 4bd397d513e9 5.15.0-60-generic #66~20.04.1-Ubuntu SMP Wed Jan 25 09:41:30 UTC 2023 x86_64 GNU/Linux
2023-02-14 18:51:34.395934 [info] OS_ARCH defined as 'x86-64'
2023-02-14 18:51:34.416313 [info] PUID defined as '1000'
2023-02-14 18:51:34.443650 [info] PGID defined as '1000'
2023-02-14 18:51:34.479826 [info] UMASK defined as '000'
2023-02-14 18:51:34.500000 [info] Permissions already set for '/config'
2023-02-14 18:51:34.524385 [info] Deleting files in /tmp (non recursive)...
2023-02-14 18:51:34.550638 [info] VPN_ENABLED defined as 'yes'
2023-02-14 18:51:34.572721 [info] VPN_CLIENT defined as 'openvpn'
2023-02-14 18:51:34.597115 [info] VPN_PROV defined as 'airvpn'
2023-02-14 18:51:34.623935 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/AirVPN_Netherlands_UDP-443.ovpn
2023-02-14 18:51:34.676341 [info] VPN remote server(s) defined as 'nl.vpn.airdns.org,'
2023-02-14 18:51:34.693537 [info] VPN remote port(s) defined as '443,'
2023-02-14 18:51:34.711049 [info] VPN remote protcol(s) defined as 'udp,'
2023-02-14 18:51:34.736628 [info] VPN_DEVICE_TYPE defined as 'tun0'
2023-02-14 18:51:34.757510 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2023-02-14 18:51:34.901110 [debug] DNS operational, we can resolve name 'nl.vpn.airdns.org' to address '213.152.162.148'
Created by...
___.   .__       .__
\_ |__ |__| ____ |  |__   ____ ___  ___
 | __ \|  |/    \|  |  \_/ __ \\  \/  /
 | \_\ \  |   |  \   Y  \  ___/ >    <
 |___  /__|___|  /___|  /\___  >__/\_ \
     \/        \/     \/     \/      \/
  https://hub.docker.com/u/binhex/
2023-02-14 18:52:35.278009 [info] System information Linux 4bd397d513e9 5.15.0-60-generic #66~20.04.1-Ubuntu SMP Wed Jan 25 09:41:30 UTC 2023 x86_64 GNU/Linux
2023-02-14 18:52:35.302738 [info] OS_ARCH defined as 'x86-64'
2023-02-14 18:52:35.323116 [info] PUID defined as '1000'
2023-02-14 18:52:35.349231 [info] PGID defined as '1000'
2023-02-14 18:52:35.385817 [info] UMASK defined as '000'
2023-02-14 18:52:35.410273 [info] Permissions already set for '/config'
2023-02-14 18:52:35.430875 [info] Deleting files in /tmp (non recursive)...
2023-02-14 18:52:35.459583 [info] VPN_ENABLED defined as 'yes'
2023-02-14 18:52:35.485748 [info] VPN_CLIENT defined as 'openvpn'
2023-02-14 18:52:35.509858 [info] VPN_PROV defined as 'airvpn'
2023-02-14 18:52:35.535714 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/AirVPN_Netherlands_UDP-443.ovpn
2023-02-14 18:52:35.585318 [info] VPN remote server(s) defined as 'nl.vpn.airdns.org,'
2023-02-14 18:52:35.610432 [info] VPN remote port(s) defined as '443,'
2023-02-14 18:52:35.628152 [info] VPN remote protcol(s) defined as 'udp,'
2023-02-14 18:52:35.653142 [info] VPN_DEVICE_TYPE defined as 'tun0'
2023-02-14 18:52:35.673416 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2023-02-14 18:52:35.715358 [debug] DNS operational, we can resolve name 'nl.vpn.airdns.org' to address '213.152.161.68'

Last image is working fine here. Do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Link to comment
16 minutes ago, strike said:

Last image is working fine here.

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

Link to comment
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.

  • Thanks 1
Link to comment
13 hours ago, strike 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  

Link to comment
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

Link to comment
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. 

Link to comment
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.

Link to comment
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 🙂

Link to comment
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 :P 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.

Link to comment

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?

Link to comment
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

conf_sonarr.png

conf_deluge.png

conf_docker_deluge.png

overview_docker.png

 

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

Link to comment

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

Link to comment
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.

Link to comment
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# 

Link to comment
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

  • Like 1
Link to comment
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.log1211158782_SuperordPhoto.thumb.png.a6f627cd56e6503f47ddc425718558ba.png1598722830_Containerstation1.png.08aec0ce98aeba1530676f21fa57c3ef.png1357427303_ContainerstationEnvironment.png.bb82d6f26b0be5fc4eca811962509999.png1915468978_ContainerstationNetwork.png.b6faf93e8a275c5a7a81fc749b26afaf.png1856134659_ContainerstationSharedFolders.png.757a14deecda1b847b0a3bafdc3d402d.png

Link to comment

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 by timmyx
Link to comment
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.

Link to comment
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?.

Link to comment
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.

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.