[Support] binhex - DelugeVPN


8639 posts in this topic Last Reply

Recommended Posts

16 hours ago, j2los said:

Any solutions to this? I have this as well as dead connections to my indexers via Jackett. Sonarr works perfectly though.

see recommended post at the top of this screen.

Link to post
  • Replies 8.6k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

OK guys, multi remote endpoint support is now in for this image please pull down the new image (this change will be rolled out to all my vpn images shortly).   What this means is that the im

There has been an issue raised on GitHub related to tracker announce request IP leakage under certain circumstances, after careful review of iptables i have tightened up the rules to prevent this. A n

I wanted to summarize how I got Mullvad working with DelugeVPN as I had to piece together several "solutions" from different comments in this thread and there was some incorrect info; likely old.

Posted Images

39 minutes ago, frodr said:

Should radar docker WebUI and Host Port 1 be deleted?

yes, it says delete ALL ports, if nzbget is NOT part of the vpn network then see Q27 from the recommended post at the top of the screen.

Link to post

Hey, thanks for your work;

 

for a about a week now (not bothered to look at it closely), delugevpn docker in unraid would fail to start, stating dns resolution errors, it'd loop through all external ip identifiers and dns resolutions until it times out eventually and starts webgui without external connection, despite it connecting to vpn (tested) and not stating any errors during it, looking at debug logs, nothing useful again other than dns resolutions failing, I tried swapping to CF, google and internal pihole with same results. It can ping external just fine from console

 

This started happening since 6.9 rc2 update

 

any ideas? let me know if you need logs/more info.

ignore me, removed .ovpn and .conf files and it just started to work.

Edited by Mizerka
Link to post
1 hour ago, binhex said:

yes, it says delete ALL ports, if nzbget is NOT part of the vpn network then see Q27 from the recommended post at the top of the screen.

Thanks,

 

All ports in radarr deleted, and added 6789 as described in A27. Still not nzbget client running. Ran the nzbgetvpn docker default LAN_NETWORK or "localhost". 

Screenshot 2021-03-14 at 23.44.25.png

Link to post

Is anyone else seeing any issues with queued up torrents disappearing? 

 

I am noticing this happening every morning when checking my downloads.  I did some testing and it seems when Deluge restarts (this occurs everyday due to my nightly backup) it seems to loose all the torrents queued up.  Any torrents that have started at least a little download are not removed.  Only torrents that have not started downloading anything.

 

I just noticed this happening after updating Deluge.  I was using the new version with the proxy updates from a few weeks ago successfully, and only noticed this after updating late last week sometime.

 

For reference in my setup I am using 2 Radarr containers, 1 for normal content, and the other exclusively for 2160p content.  I do this to keep both versions of a single movie, but in separate directories and libraries in Plex.  I don't think the issue is with these applications as I see this occur for both Radarr instances and for Sonarr as well, and they only disappear when Deluge is restarted not Radarr, Sonarr, or Jackett.  Radarr, Sonarr, and Jackett are all setup using Deluge as the privoxy.

Link to post
22 hours ago, razaq said:

Hey im having an issue with your image. It used to work like a charm but I recently cannot connect to the daemon port anymore.

 

The webui works great, daemon port is default 58846 and remote connections are allowed. The docker container also has the port forwarded, i do not have a firewall for the local network.

 

On the host machine (local lan address 192.168.178.37)


nc -vc 192.168.178.37 58846

times out, while


nc -vc 127.0.0.1 58846

shows the port as open.

 

I start the container with


LAN_NETWORK=192.168.178.0/24

so no problem there either.

 

So it seems for some reason docker does not listen to the lan address of the machine and only on localhost.

Any ideas?

even after hours of trial and error i can not figure this out. Daemon just does not listen to LAN ip for some reason...

Link to post
11 minutes ago, razaq said:

even after hours of trial and error i can not figure this out. Daemon just does not listen to LAN ip for some reason...

is the traffic going from lan to container or is it going from container to lan?.

Link to post
5 minutes ago, binhex said:

is the traffic going from lan to container or is it going from container to lan?.

ideally both ways obviously. i mean the webui does work from local lan (192.168.178.37:8112), just the daemon port times out (192.168.178.37:58846). how can i test the answer to your question easily?

 

these are the ports that docker ps is showing:

0.0.0.0:8112->8112/tcp, 0.0.0.0:8118->8118/tcp, 0.0.0.0:58846->58846/tcp, 0.0.0.0:58946->58946/tcp, 58946/udp

Edited by razaq
Link to post
2 minutes ago, razaq said:

how can i test the answer to your question easily?

ok to put it another way, is the application inside the vpn network set to talk to an application on the lan?, or is an app on the lan set to talk to an application inside the vpn network?.

 

e.g. sonarr (on lan) > delugevpn (vpn)

or

sonarr (vpn) > nzbget (lan)

 

in basic terms what exactly are you trying to achieve?.

Link to post
10 minutes ago, binhex said:

ok to put it another way, is the application inside the vpn network set to talk to an application on the lan?, or is an app on the lan set to talk to an application inside the vpn network?.

 

e.g. sonarr (on lan) > delugevpn (vpn)

or

sonarr (vpn) > nzbget (lan)

 

in basic terms what exactly are you trying to achieve?.

all i am trying to do is connect to the daemon port from another machine in the same lan using the gtk ui as ThinClient, which has worked previously without any issues (I have already completely reinstalled the image, so that is ruled out)

 

Edited by razaq
Link to post
3 minutes ago, razaq said:

all i am trying to do is connect to the daemon port from another machine in the same lan using the gtk ui as ThinClient,

ok so lan to delugevpn, and what is your LAN_NETWORK env var defined as?.

Link to post
7 minutes ago, binhex said:

ok so lan to delugevpn, and what is your LAN_NETWORK env var defined as?.

LAN_NETWORK=192.168.178.0/24

the daemon is also set to allow remote connections. there is no firewall for the local lan and the webui works (from 192.168.178.37:8112), which should mean that the daemon is also running without issues.

 

as i said when i do a port check on the host machine for port 58846 (daemon port) using 127.0.0.1, i see that the port is open, only when using the lan address 192.168.178.37 does it time out.

 

doing the same port check for the webui port 8112 works in both cases.

Edited by razaq
Link to post
15 hours ago, frodr said:

Thanks,

 

All ports in radarr deleted, and added 6789 as described in A27. Still not nzbget client running. Ran the nzbgetvpn docker default LAN_NETWORK or "localhost". 

Screenshot 2021-03-14 at 23.44.25.png

Not being able to get nzbget client within radarr to work, I switched from nzbgetvpn to binhex-nzbget following the instruction in the FAQ. Binhex-nzbget started but I could not connect WebUI. Trying to add 6789 as additional port in binhex-deliugevpn, the Docker service once again start spinning (the Unraid time glass keeps running and dockers tab autostarts keeps going on-off. Again I have to delete the Docker image and start all over. This is quite frustrating. 

Edited by frodr
Link to post
38 minutes ago, razaq said:


LAN_NETWORK=192.168.178.0/24

the daemon is also set to allow remote connections. there is no firewall for the local lan and the webui works, which should mean that the daemon is also running without issues.

 

as i said when i do a port check on the host machine for port 58846 (daemon port) using 127.0.0.1, i see that the port is open, only when using the lan address 192.168.178.37 does it time out.

hmm this is definitely permitted, if i run the same command as you i get success, both using the unraid host ip and from another device on my lan:-

 

(mac)

nc -vc 192.168.1.10 58846
Connection to 192.168.1.10 port 58846 [tcp/*] succeeded!

 

(unraid terminal)

root@Tower:~# nc -v 192.168.1.10 58846
Tower.local [192.168.1.10] 58846 (?) open

 

this is with the latest image, are you doing this remotely or over a vpn, vlan's in place?, checked firewall logs?.

Link to post
26 minutes ago, frodr said:

Not being able to get nzbget client within radarr to work,

what is the 'network type' and 'extra parameters' set to for nzbget?.

Link to post
28 minutes ago, binhex said:

what is the 'network type' and 'extra parameters' set to for nzbget?.

nzbgetvpn: network type=bridge, extra parameters="nothing", LAN_NETWORK="my subnet" and "localhost"

 

binhex-nzbget: network type=none, extra parameters="--net=container:binhex-delugevpn"

 

Not running both binhex-nzbget and nzbgetvpn at the same time.

Edited by frodr
Link to post
42 minutes ago, binhex said:

hmm this is definitely permitted, if i run the same command as you i get success, both using the unraid host ip and from another device on my lan:-

 

(mac)

nc -vc 192.168.1.10 58846
Connection to 192.168.1.10 port 58846 [tcp/*] succeeded!

 

(unraid terminal)

root@Tower:~# nc -v 192.168.1.10 58846
Tower.local [192.168.1.10] 58846 (?) open

 

this is with the latest image, are you doing this remotely or over a vpn, vlan's in place?, checked firewall logs?.

latest image, not remotely, same phyiscal network

 

logs show no errors

delugevpn | [info] Waiting for Deluge process to start listening on port 58846...
delugevpn | 
delugevpn | 2021-03-15 16:39:12,462 DEBG 'watchdog-script' stdout output:
delugevpn | [info] Deluge process listening on port 58846

 

Link to post
7 minutes ago, frodr said:

nzbgetvpn: network type=bridge, extra parameters="nothing", LAN_NETWORK="my subnet" and "localhost"

i have NO idea what or who produced nzbgetvpn but that is not an image i have created, so you are on your own for support on that one.

 

im going to assume from your screenshot that sonarr and/or radarr are running through the network of delugevpn, correct?, if so then Q27 is applicable.:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

 

Link to post
17 minutes ago, binhex said:

i have NO idea what or who produced nzbgetvpn but that is not an image i have created, so you are on your own for support on that one.

 

im going to assume from your screenshot that sonarr and/or radarr are running through the network of delugevpn, correct?, if so then Q27 is applicable.:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

 

I understand. Settings for b-delugevpn and b-nzbget. I can not connect to WebUI b-nzbget with "server:6789", but now I can connect to nzbget client within radarr. 

Screenshot 2021-03-15 at 17.01.42.png

Screenshot 2021-03-15 at 17.02.23.png

Link to post
19 minutes ago, frodr said:

I can not connect to WebUI b-nzbget with "server:6789"

so firing up a web browser (ensure it is set NOT to use a proxy) and going to https://<your unraid servers ip address>:6789 does not allow you to connect to nzbget web ui?.

Link to post
1 hour ago, binhex said:

so firing up a web browser (ensure it is set NOT to use a proxy) and going to https://<your unraid servers ip address>:6789 does not allow you to connect to nzbget web ui?.

That's correct. No proxy, serverip:6789. The strange thing is that the browser show the nzbget logo. 

Screenshot 2021-03-15 at 18.47.02.png

Link to post
5 minutes ago, frodr said:

That's correct. No proxy, serverip:6789. The strange thing is that the browser show the nzbget logo. 

hmm so your LAN_NETWORK is defined as 10.10.50.0/24?

Link to post

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.