[Support] binhex - DelugeVPN

dazedv3 · April 1

On 3/12/2024 at 8:57 PM, dazedv3 said:

Hi, I'm using delugevpn to run my "arrs" and firefox through VPN.

I'm having an issue where after a day or 2 my web UI's for each docker that is running through the VPN become inaccessible and the web page just times out. As far as i'm aware the dockers are still running but I can't access them through UI to confirm this.

LOGS

docker run
-d
--name='binhex-delugevpn'
--net='bridge'
--privileged=true
-e TZ="____________"
-e HOST_OS="Unraid"
-e HOST_HOSTNAME="____________"
-e HOST_CONTAINERNAME="binhex-delugevpn"
-e 'VPN_ENABLED'='yes'
-e 'VPN_USER'='____________'
-e 'VPN_PASS'='____________'
-e 'VPN_PROV'='custom'
-e 'VPN_CLIENT'='openvpn'
-e 'VPN_OPTIONS'=''
-e 'STRICT_PORT_FORWARD'='yes'
-e 'ENABLE_PRIVOXY'='yes'
-e 'LAN_NETWORK'='192.168.55.0/24,192.168.10.0/24,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'='yes'
-e 'VPN_INPUT_PORTS'='9696,8989,7878,8686,6767,3000'
-e 'VPN_OUTPUT_PORTS'='9696,8989,7878,8686,6767,3000'
-e 'DEBUG'='false'
-e 'UMASK'='000'
-e 'PUID'='99'
-e 'PGID'='100'
-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'
-p '9696:9696/tcp'
-p '8686:8686/tcp'
-p '7878:7878/tcp'
-p '8989:8989/tcp'
-p '6767:6767/tcp'
-p '3000:3000/tcp'
-v '/mnt/user/downloads/':'/data':'rw'
-v '/mnt/user/appdata/binhex-delugevpn':'/config':'rw'
--sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-delugevpn'
6a7bb54eae1771ce1c53d4ec3e3645838e2842f54c621d4cececf08907646b88

The command finished successfully!

supervisord.log 73.33 kB · 1 download

Anyone shed some light?

Techiez237 · April 1

Hi! I see there are new releases to the container the last 20 hours but I don't see any new commits or changes anything we should be upgrading to? Thanks

chesh · April 1

1 hour ago, Techiez237 said:

Hi! I see there are new releases to the container the last 20 hours but I don't see any new commits or changes anything we should be upgrading to? Thanks

Probably to patch the XV library backdoor. But, I'd hold off on updating as the latest version isn't starting completely.

uberchuckie · April 2

11 hours ago, chesh said:

Probably to patch the XV library backdoor. But, I'd hold off on updating as the latest version isn't starting completely.

I see the same thing. The container image upgraded about eight hours ago.

The last two lines in the log file is

[info] Deluge process started
[info] Waiting for Deluge process to start listening on port 58846...

Adding DEBUG=true enabled debug logging but didn't add any more logs after the above.

Rolling back to the 2.1.1-4-05 tag "fixes" it.

xz in the image with that tag is version 5.4.5 (which does not contain the backdoor).

Edited April 2 by uberchuckie

binhex · April 2

I see the same thing. The container image upgraded about eight hours ago.

The last two lines in the log file is
[info] Deluge process started[info] Waiting for Deluge process to start listening on port 58846...
Adding DEBUG=true enabled debug logging but didn't add any more logs after the above.

Rolling back to the 2.1.1-4-05 tag "fixes" it.

xz in the image with that tag is version 5.4.5 (which does not contain the backdoor).

I'm currently on holiday, I shall take a look when I get back on Saturday

Sent from my 22021211RG using Tapatalk

uberchuckie · April 2

I'm currently on holiday, I shall take a look when I get back on Saturday

Sent from my 22021211RG using Tapatalk

Thanks. No rush. Rolling back works around the problem.

Sent from my iPhone using Tapatalk

wambo · April 4

For a while already I keep getting connection timeouts when trying to access the deluge webui - or webuis of containers that I route through this container (their network is this container, and their webui ports have been added to this container)

After some restarting each container, checking logs, pinging from inside / checking the port from outside with telnet it sometimes works again - but I have no clue why, and no clue why it doesn't from the beginning...

In the logs I can see that the Deluge Webui has started - still: "ERR_CONNECTION_TIMED_OUT"
And since the other webuis are also unreachable (but the containers work) - I think it's some network problem inside this container.

While fiddling around to fix, I also updated the container (30min ago), and I do not get the error in the posts above:

2024-04-04 20:54:56,211 DEBG 'watchdog-script' stdout output:
[info] Deluge process started
[info] Waiting for Deluge process to start listening on port 58846...

2024-04-04 20:55:05,365 DEBG 'watchdog-script' stdout output:
[info] Deluge process listening on port 58846

And this is with the latest tag, image from 4 days ago - same as 2.1.1-4-09

Edit2:
I seem to have the same issue as Dazedv3 a fest posts above, but it's also the deluge webui that is inaccessible (and also after container restart...)

animeking1987 · April 5

I recently started using the delugevpn and my torrents wont start downloading at all. When I look at my logs i view this. did i miss something? image.png.98d96b0a2b99d5420ba261f8b1182be6.png

Edited April 5 by animeking1987

uberchuckie · April 6

On 4/2/2024 at 6:16 AM, binhex said:

I'm currently on holiday, I shall take a look when I get back on Saturday

Sent from my 22021211RG using Tapatalk

I took a quick look at it. The process fails with:

09:12:04 [INFO    ][deluge.core.rpcserver         :1622] Starting DelugeRPC server :58846
09:12:04 [ERROR   ][deluge.core.daemon_entry      :1622] Unable to start deluged: [('SSL routines', '', 'ee key too small')]
09:12:04 [INFO    ][deluge.core.daemon_entry      :1622] Exiting...

My guess the problem is with the deluge daemon cert key pair: https://github.com/binhex/arch-delugevpn/blob/master/config/nobody/webui/web.conf

The cert from my setup is from 2017 and it expired in 2021. It's also RSA 1024 bit.

-rwxrwxr-x 1 nobody users 623 Oct 15  2017 daemon.cert
-rwxrwxr-x 1 nobody users 916 Oct 15  2017 daemon.pkey

openssl x509 -text -noout -in daemon.cert
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 0 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: CN = Deluge Daemon
        Validity
            Not Before: Jan  3 19:47:27 2016 GMT
            Not After : Jan  1 19:47:27 2021 GMT
        Subject: CN = Deluge Daemon
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:c5:96:5b:59:37:49:f0:ad:a0:0b:8c:9d:28:52:
                    ca:d5:19:1c:57:dd:7f:40:53:d0:99:9b:94:b3:c3:
                    4f:4e:bc:c4:cd:29:26:5f:da:70:21:ab:e3:e2:a6:
                    0d:d9:63:ad:1a:6d:14:fd:5b:0b:ec:5f:a5:03:c0:
                    ca:e0:79:a2:7c:c4:64:cf:78:61:00:c5:17:ca:1a:
                    8a:0c:89:ca:7a:b6:67:c6:73:2c:f6:cf:71:6a:f3:
                    98:7d:3f:55:95:35:62:48:00:92:64:76:e5:0f:fb:
                    52:f9:a3:69:93:87:e2:ac:13:4f:73:fd:09:b5:57:
                    e9:a3:cb:5d:ab:d6:bc:da:bd
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
    Signature Value:
        90:e7:c4:00:4d:98:04:75:6f:46:1a:13:bb:f6:19:52:97:6a:
        52:87:86:23:2c:5c:d0:de:a7:94:5a:10:94:a0:86:d4:d7:58:
        73:dc:d2:4d:92:b1:26:2c:bc:67:1f:db:61:f9:0d:69:8d:db:
        78:4a:8c:67:4e:d5:78:a2:fc:28:25:06:0b:dd:68:33:18:f2:
        1c:f8:31:f0:c7:35:44:f8:7e:d0:4b:9d:be:b1:76:9a:40:ee:
        02:d2:17:5d:ce:c2:23:b1:28:0b:74:57:72:57:87:8e:ee:34:
        3a:d3:ab:e6:1d:82:d6:b9:3f:f2:15:d4:26:47:c9:86:99:6c:
        69:ae

Since it's on the /config volume mount. I think regenerating the certificate should fix it?

I tried creating a new cert with the existing private key:

openssl x509 -in daemon.cert -signkey daemon.pkey -x509toreq -out daemon.csr
openssl x509 -signkey daemon.pkey -in daemon.csr -req -days 3652 -out new.cert

Overwriting the old cert with the new one didn't fix it. It's the same error.

Maybe I need to use RSA 2048 or larger key size? The "ee key too small" error suggests that's the case?

Generating a new key and CSR, then creating a new certificate:


openssl req -newkey rsa:2048 -nodes -keyout new.pkey -out new.csr
openssl x509 -signkey new.pkey -in new.csr -req -days 3652 -out new.cert

I used CN=Deluge Daemon like the existing certificate but I don't know if certificate verification is on since the old one expired years ago and things were still working.

Again, overwriting the existing daemon.cert and daemon.pkey...

That fixed it! It looks like something in the latest build is preventing private keys with RSA 1024 bit key size to be used. This is probably a good thing since it's not considered to be secure anymore.

Edited April 6 by uberchuckie

binhex · April 6

7 hours ago, uberchuckie said:

The cert from my setup is from 2017 and it expired in 2021. It's also RSA 1024 bit.

The cert is auto generated as part of the startup process, i have just run from fresh and i can see the cert has a creation date of today and expires in 3 years, you could try stopping the container, then delete the /config/ssl folder and start the container, this should force a new cert to be created.

uberchuckie · April 6

14 minutes ago, binhex said:

The cert is auto generated as part of the startup process, i have just run from fresh and i can see the cert has a creation date of today and expires in 3 years, you could try stopping the container, then delete the /config/ssl folder and start the container, this should force a new cert to be created.

OK. That worked too.

openssl x509 -text -noout -in daemon.cert
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 0 (0x0)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Deluge Daemon
        Validity
            Not Before: Apr  6 21:15:29 2024 GMT
            Not After : Apr  6 21:15:29 2027 GMT
        Subject: CN = Deluge Daemon
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)

chesh · April 7

Renaming the SSL folder and restarting worked for me as well. Thanks for the tip BinHex

bmartino1 · April 8

Binhex vpn.

There may be a log or memory leak that shows. can a client running this go to /Tools/Diagnostics

Tools > Diagnositc and download there log the in the zip file go to

system/ps.txt

then do a search for their password to confirm this memory leak?

I couldn't reporduce.

Michael_P · April 8

6 minutes ago, bmartino1 said:

Binhex vpn.

There may be a log or memory leak that shows. can a client running this go to /Tools/Diagnostics

Tools > Diagnositc and download there log the in the zip file go to

system/ps.txt

then do a search for their password to confirm this memory leak?

I couldn't reporduce.

Here's on in this thread - system/ps.txt shows their user name and password in plain text

binhex · April 8

29 minutes ago, bmartino1 said:

then do a search for their password to confirm this memory leak?

Yes, it looks like the diagnostics tool is grabbing the entire process name including all env vars defined for the container, the env vars will specify (amongst a lot of other things) the username and password for the vpn provider, i assume this would be true for any env vars for any container, not just this one.

obfuscation of credentials is actually quite difficult to do in a robust manner, line wraps or other unexpected conditions can cause the credential to leak even if obfuscation is used.

Michael_P · April 8

4 minutes ago, binhex said:

this would be true for any env vars for any container, not just this one

Right, which is why I created a bug report instead of each docker container's support thread

bmartino1 · April 8

53 minutes ago, binhex said:

Yes, it looks like the diagnostics tool is grabbing the entire process name including all env vars defined for the container, the env vars will specify (amongst a lot of other things) the username and password for the vpn provider, i assume this would be true for any env vars for any container, not just this one.

obfuscation of credentials is actually quite difficult to do in a robust manner, line wraps or other unexpected conditions can cause the credential to leak even if obfuscation is used.

but its not. Example pihole docker. there is a env and docker run but doesn't show up in the ps log nor give out the password..... my guess is that this is happening as for some reason it is also calling a unraid bin function to be exposed.

animeking1987 · April 9

any update on my issue?

FreeMan · April 10

On 4/2/2024 at 6:16 AM, binhex said:

I'm currently on holiday, I shall take a look when I get back on Saturday

Sent from my 22021211RG using Tapatalk

Is there a build now that doesn't have this issue? I've rolled back to the 2.1.1-4-05 tag, so I'm not getting update notifications...

binhex · April 10

19 minutes ago, FreeMan said:

Is there a build now that doesn't have this issue? I've rolled back to the 2.1.1-4-05 tag, so I'm not getting update notifications...

@uberchuckie issue was resolved, if you have the same issue then do the following:- https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=1400857

knights_of_pine · April 11

text  error  warn  system  array  login  

-A INPUT -i lo -j ACCEPT
-A INPUT -i wg0 -j ACCEPT
-A OUTPUT -d 198.54.133.130/32 -o eth0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d 198.54.133.130/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 9696 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 9696 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 7878 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 7878 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8989 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8989 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9897 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 9897 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8686 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8686 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 6767 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 6767 -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 -o eth0 -p tcp -m tcp --sport 3000 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 3000 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8191 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8191 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8787 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8787 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8788 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8788 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 5076 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 5076 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 5801 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 5801 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.0.0/16 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.0.0/16 -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

2024-04-10 21:10:26,971 DEBG 'start-script' stdout output:
--------------------

2024-04-10 21:10:26,973 DEBG 'start-script' stdout output:
[info] Configuring WireGuard...

2024-04-10 21:10:26,982 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'up'...

2024-04-10 21:10:26,990 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2024-04-10 21:10:26,994 DEBG 'start-script' stderr output:
[#] ip link add wg0 type wireguard

2024-04-10 21:10:26,996 DEBG 'start-script' stderr output:
[#] wg setconf wg0 /dev/fd/63

2024-04-10 21:10:26,996 DEBG 'start-script' stderr output:
[#] ip -4 address add 10.69.141.95/32 dev wg0

2024-04-10 21:10:27,000 DEBG 'start-script' stderr output:
[#] ip link set mtu 1420 up dev wg0

2024-04-10 21:10:27,002 DEBG 'start-script' stderr output:
[#] resolvconf -a wg0 -m 0 -x

2024-04-10 21:10:27,010 DEBG 'start-script' stderr output:
could not detect a useable init system

2024-04-10 21:10:27,033 DEBG 'start-script' stderr output:
[#] wg set wg0 fwmark 51820

2024-04-10 21:10:27,034 DEBG 'start-script' stderr output:
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820

2024-04-10 21:10:27,035 DEBG 'start-script' stderr output:
[#] ip -4 rule add not fwmark 51820 table 51820

2024-04-10 21:10:27,036 DEBG 'start-script' stderr output:
[#] ip -4 rule add table main suppress_prefixlength 0

2024-04-10 21:10:27,038 DEBG 'start-script' stderr output:
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1

2024-04-10 21:10:27,040 DEBG 'start-script' stderr output:
[#] iptables-restore -n

2024-04-10 21:10:27,041 DEBG 'start-script' stderr output:
[#] '/root/wireguardup.sh'

log above. my docker will not start? no gui. did not change anything. not sure why? tried stopping, restarting, etc. tried new wg0.conf. any help?

Edited April 11 by knights_of_pine
more info

stormense · April 11

On 4/7/2024 at 9:51 PM, chesh said:

Renaming the SSL folder and restarting worked for me as well. Thanks for the tip BinHex

Not here, no new ssl generated. Unraid:

/mnt/user/appdata/binhex-delugevpn/ no new ssl folder

But downloaded a new ovpn file from Air VPN and then it worked with the old sll folder I backed up .

Edited April 11 by stormense

binhex · April 11

4 hours ago, knights_of_pine said:

log above. my docker will not start?

that log is useless, please do the following:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

mirhunter · April 12

Hello, I had delugevpn working and then pulled the latest container image.

I am using pia with wireguard. I have set

net.ipv4.conf.all.src_valid_mark = 1

end enabled "Privileged mode".

the error I am getting is:

2024-04-11 23:36:55,570 DEBG 'start-script' stderr output:
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1

2024-04-11 23:36:55,572 DEBG 'start-script' stderr output:
sysctl: 
2024-04-11 23:36:55,572 DEBG 'start-script' stderr output:
permission denied on key "net.ipv4.conf.all.src_valid_mark"

not sure where to go from here...

binhex · April 12

4 hours ago, mirhunter said:

I am using pia with wireguard. I have set

you sure about that? so in advanced view for the container in 'extra parameters' you have the following defined?:-

--sysctl="net.ipv4.conf.all.src_valid_mark=1"

[Support] binhex - DelugeVPN

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Ryanoc3ros

Dad_Rage

binhex

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation