[Support] binhex - DelugeVPN


Recommended Posts

24 minutes ago, storagehound said:

Carnovorbrah,
I totally missed your post.  I must have been pretty fried at that point.  In fact, if I'd noticed, I'm sure it would have helped me get mine up sooner.   The only thing different with mine is I didn't use the proxy on Jackett since I had decided to route my three containers through Deluge-VPN.  I'm going to triple check my connections...I think I don't need the proxy setting in some of those other areas.

 

Well, I didn't add '--net=container:<name of vpn container>' to my containers. I missed that, but I see a reply stating that is not needed if you set the "localhost" IP in the web GUI of the container instead. So, I'm not sure what's going on.

 

The part that is really killing me, is the physical device pointed through the proxy IP/port part. If I do that, I cannot access the Unraid web GUI, nor any of my dockers running in bridge or custom IP on that device. I can only access dockers running on my "proxynet" VLAN using the fully qualified public domain name, which is going out and back in using DNS resolution and Swag (i'm guessing).

 

EDIT: Just to clarify, I point my physical laptop, desktop and mobile phone through DelugeVPN proxy, but the above issue is what happens when I do it with the latest update. Here's my proxy settings on my desktop PC:

image.png.c89d58a3f23a9b5234a14aa8b7b77f00.png

Edited by carnivorebrah
  • Like 1
Link to comment
21 minutes ago, MammothJerk said:

1. I'm only using the delugevpn privoxy for sonarr.

2. 192.168.1.0/24 and my server address is 192.168.1.105

3. sonarr and delugevpn are both running bridged.

 

delugevpn settings:

bvA9mjK.gif

 

Sonarr settings

cpB7swl.png

 

With the latest delugevpn container sonarr can only connect to deluge download client if the host is set to 172.17.0.9. localhost or 192.168.1.105 does NOT work.

Same story with the proxy under general > proxy.

 

downgrading to the previous container i have no issues.

 

How do you downgrade? I am having the same issue as you.

  • Like 1
Link to comment
32 minutes ago, carnivorebrah said:

Yes, I am routing Radarr, Sonarr and Jackett through DelugeVPN using the web GUI settings for each docker to point to the deluge container IP/port (10.100.1.3:8118). I tried using "localhost" too, but it wouldn't connect.

the port you specified above is for privoxy, so are you routing the containers through delugevpn or are you using privoxy running in delugevpn?.

  • Thanks 1
Link to comment
1 minute ago, binhex said:

the port you specified above is for privoxy, so are you routing the containers through delugevpn or are you using privoxy running in delugevpn?.

 

I think I am using privoxy running in delugevpn, because I'm not routing the containers using '--net=container:<name of vpn container>'. I think?

 

I honestly don't know if I'm answering your question correctly though.

 

Anytime I want to "point" or "route" something through DelugeVPN, I enter the IP 10.100.1.3 and port 8118 on that physical device's or the docker container web UI's proxy settings. At least, that is how I've always done it.

Link to comment

Hi everyone

 

Is it correct that using 'localhost:<port number>' in an IP address in a WebUI for a Docker container will only work if you are connecting to another Docker container if (a) both containers are being routed through the DelugeVPN docker container; or (b) both containers are not being routed through the DelugeVPN (or any other) Docker container?

 

Also, if one container is being routed through the DelugeVPN docker container........and another is using the privoxy functionality of the DelugeVPN container...then will localhost work here.....and, if not, does that mean you won't be able to connect the two together (as I understand you now need to use 'localhost' rather than an IP address as a result of the changes to the new container?)

 

Thanks in advance.

 

 

Link to comment
34 minutes ago, carnivorebrah said:

Anytime I want to "point" or "route" something through DelugeVPN, I enter the IP 10.100.1.3 and port 8118 on that physical device's or the docker container web UI's proxy settings. At least, that is how I've always done it.

ok thats fine, so you are using privoxy in this case and NOT network binding multiple containers.

 

so good news, at long last i am able to replicate one of the issues here, so if i set sonarr to point at privoxy running in delugevpn and then add in deluge as a donwload client in sonarr and click on the test button it fails.

 

the reason it fails is that the proxy settings in sonarr are by default set to route everything via the proxy, this causes a problem when attempting to connect to deluge, as the connection will go as follows:-
 

sonarr container outbound to privoxy > outbound to lan network (ip is unraid host on lan range) > re-routed back to delugevpn container > and then finally connect to deluge, and then traverse all the way back again to reach sonarr.

 

in short the solution to this is to set sonarr not to use the proxy for local network addresses, this does indeed fix the issue, this is done in sonarr by doing the following, note the 'ignore addresses' field, the below is a single ip, but if you want you can do your whole network using wildcards, e.g. 192.168.1.*

 

image.thumb.png.de23bb0950370ed69e534481841b2c67.png

 

The alternative to this approach is simpler, you create a jackett container, you set jackett to use privoxy and then you set sonarr etc to use jackett, this negates the requirement of setting a proxy on sonarr, radarr or any other indexer, as jackett is doing routing for you via privoxy (how i have mine setup).

 

  • Thanks 7
Link to comment

Ok so I was reading through and was having the same issues so decided to roll back Deluge-vpn.  When I attempted to do so I got this screen.  It removed Deluge-vpn and will not let me reinstall.

 

 

EDIT: So stopped and re-enable docker allowed me to reinstall.  Now just to reset up.

 

deluge.png

Edited by Gragorg
Solved
Link to comment
21 minutes ago, binhex said:

ok thats fine, so you are using privoxy in this case and NOT network binding multiple containers.

 

so good news, at long last i am able to replicate one of the issues here, so if i set sonarr to point at privoxy running in delugevpn and then add in deluge as a donwload client in sonarr and click on the test button it fails.

 

the reason it fails is that the proxy settings in sonarr are by default set to route everything via the proxy, this causes a problem when attempting to connect to deluge, as the connection will go as follows:-
 

sonarr container outbound to privoxy > outbound to lan network (ip is unraid host on lan range) > re-routed back to delugevpn container > and then finally connect to deluge, and then traverse all the way back again to reach sonarr.

 

in short the solution to this is to set sonarr not to use the proxy for local network addresses, this does indeed fix the issue, this is done in sonarr by doing the following, note the 'ignore addresses' field, the below is a single ip, but if you want you can do your whole network using wildcards, e.g. 192.168.1.*

 

image.thumb.png.de23bb0950370ed69e534481841b2c67.png

 

The alternative to this approach is simpler, you create a jackett container, you set jackett to use privoxy and then you set sonarr etc to use jackett, this negates the requirement of setting a proxy on sonarr, radarr or any other indexer, as jackett is doing routing for you via privoxy (how i have mine setup).

 

 

Okay, looks like adding my network "10.100.1.*" to "Ignored Addresses" in both Sonarr and Radarr fixed the connections issues between them, Jackett and DelugeVPN. It looks like just checking the box "Bypass Proxy for Local Addresses" will not work on its own. Thank you so much.

 

This is also true for any physical devices I use, aka laptop, desktop, mobile device:

image.png.9beea1e021ef40b9197ef438afec35af.png

 

You have to specify the IP addresses or entire subnet that you want to bypass the proxy for. Checking the box alone doesn't work.

 

All issues resolved! Thank you!!!

 

 

Edited by carnivorebrah
  • Like 3
Link to comment
2 hours ago, binhex said:

ok thats fine, so you are using privoxy in this case and NOT network binding multiple containers.

 

so good news, at long last i am able to replicate one of the issues here, so if i set sonarr to point at privoxy running in delugevpn and then add in deluge as a donwload client in sonarr and click on the test button it fails.

 

the reason it fails is that the proxy settings in sonarr are by default set to route everything via the proxy, this causes a problem when attempting to connect to deluge, as the connection will go as follows:-
 

sonarr container outbound to privoxy > outbound to lan network (ip is unraid host on lan range) > re-routed back to delugevpn container > and then finally connect to deluge, and then traverse all the way back again to reach sonarr.

 

in short the solution to this is to set sonarr not to use the proxy for local network addresses, this does indeed fix the issue, this is done in sonarr by doing the following, note the 'ignore addresses' field, the below is a single ip, but if you want you can do your whole network using wildcards, e.g. 192.168.1.*

 

image.thumb.png.de23bb0950370ed69e534481841b2c67.png

 

The alternative to this approach is simpler, you create a jackett container, you set jackett to use privoxy and then you set sonarr etc to use jackett, this negates the requirement of setting a proxy on sonarr, radarr or any other indexer, as jackett is doing routing for you via privoxy (how i have mine setup).

 

Using jackett via privoxy is not a good idea since it does not pass dns requests through privoxy. It is "leaking" those request to your regular dns servers.

Jackett even has a warning about using proxy.

Link to comment
9 minutes ago, mihu said:

Using jackett via privoxy is not a good idea since it does not pass dns requests through privoxy. It is "leaking" those request to your regular dns servers.

Jackett even has a warning about using proxy.

sure, but if you point it at a nameserver that doesn't log then the issue doesn't really matter right?, but you are correct, routing jackett through a vpn container is a better solution if dns is of concern to you.

Link to comment

It seems like the the "Bypass Proxy for Local Addresses" fix does not work if you're routing the sonarr/radarr container(s) through DelugeVPN's container. (failing to connect to client/jackett indexers)  Any possible workaround for this?

 

I'm routing the containers of sonarr/radarr through the deluge to prevent any leakage.  Not sure if enabling a proxy is as secure.

Link to comment
8 minutes ago, Valpo said:

It seems like the the "Bypass Proxy for Local Addresses" fix does not work if you're routing the sonarr/radarr container(s) through DelugeVPN's container.

correct, it wont, that solution is when you are using a proxy, you need Q25:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

assuming your issue is with access to jacket web ui?

Link to comment
5 minutes ago, binhex said:

assuming your issue is with access to jacket web ui?

I have Jackett, Radarr, and Sonarr containers routed through Deluge.  All are actually accessible via web ui and reach the internet. (getting a VPN IP)  It just seems like this update broke the LAN communication of containers are routed though the Delgue container.  Which means reverting the sub-containers to a bridge connection and proxying is the only option, outside of rolling back the deluge update?

 

Btw, thank you bihnex for the updates, replies, and support.  Much appreciated my friend. 

Link to comment
4 minutes ago, Valpo said:

All are actually accessible via web ui and reach the internet. (getting a VPN IP)  It just seems like this update broke the LAN communication of containers are routed though the Delgue container. 

in that case please see Q25 (updated), i forgot to mention the section regards setting host to 'localhost':- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

  • Thanks 1
Link to comment

Here is my dilemma.  Up until the latest update I was running Radarr and Sonarr through DelugeVPN without issue.  Both Radarr and Sonarr were able to communicate with my Plexserver (Host Network) and NZBGet (Bridge Network).  After this recent update things broke.

 

I was able to fix things enough that I could communicate with the WebUI for for both Radarr and Sonarr.  However, I still can't communicate from Radarr/Sonarr to my Plexserver or NZBGet.  I have zero desire to run either of these through the VPN.  How can I maintain communication between all the containers running through deluge and the ones that don't?

Edited by abisai169
  • Like 1
Link to comment
1 hour ago, abisai169 said:

Here is my dilemma.  Up until the latest update I was running Radarr and Sonarr through DelugeVPN without issue.  Both Radarr and Sonarr were able to communicate with my Plexserver (Host Network) and NZBGet (Bridge Network).  After this recent update things broke.

 

I was able to fix things enough that I could communicate with the WebUI for for both Radarr and Sonarr.  However, I still can't communicate from Radarr/Sonarr to my Plexserver or NZBGet.  I have zero desire to run either of these through the VPN.  How can I maintain communication between all the containers running through deluge and the ones that don't?

 

This is the reason I decided not to run my Radarr/Sonarr/Jackett directly through my DelugeVPN container and continue to use the privoxy within the applications.  You can still do this you just need to add your network to the 'Ignored Addresses' parameter in the Proxy section of the app.  There are details some posts above that I found helpful, but I can post screens if needed.

 

Another reason I am not running them directly through the VPN container is I saw an issue when running 2 versions of Radarr with this setup.  I think because the internal port on my 2nd Radarr is still 7878 in the application settings even though the WEBUI container port is 7879.

 

Overall I would like to run the containers without the potential leaks described that pushed this update/fix but as long as I can stay on an updated version and still have everything working I am happy.  I say that until a potential leak causes a major issue of course. 😄

Edited by Burizado
Link to comment
On 2/27/2021 at 6:18 AM, abisai169 said:

Here is my dilemma.  Up until the latest update I was running Radarr and Sonarr through DelugeVPN without issue.  Both Radarr and Sonarr were able to communicate with my Plexserver (Host Network) and NZBGet (Bridge Network).  After this recent update things broke.

 

I was able to fix things enough that I could communicate with the WebUI for for both Radarr and Sonarr.  However, I still can't communicate from Radarr/Sonarr to my Plexserver or NZBGet.  I have zero desire to run either of these through the VPN.  How can I maintain communication between all the containers running through deluge and the ones that don't?

 

I have the same problem, where everything works as expected (after adding ADDITIONAL PORTS and adjusting application settings to use localhost) except being able to connect to bridge containers from any of the container with network binding to delugeVPN.

 

Jackett, Radarr and Sonarr are all bound to the DelugeVPN network.

Proxy/Privoxy is not used by any application.

NzbGet is using the normal bridge network.

I can access all application UIs and the VPN tunnel is up. Each application can communicate with the internet.

In Sonarr and Radarr:

  • I can connect to all configured indexers, both Jackett (localhost) and nzbgeek directly (public dns name)
  • I can connect to delugeVPN as a download client (using localhost)
  • I CAN NOT connect to NzbGet as a download client using <unraidIP>:6790. Connection times out.
  • I CAN connect to NzbGet using it's docker bridge IP (172.x.x.x:6790)

It's my understanding that the docker bridge IP is dynamic and may change on container restart, so I don't really want to use that.

 

@binhex it seems like the new iptable tightening is preventing delugeVPN (and other containers sharing it's network) from communicating with containers running on bridge network on the same host?

Here's a curl output from the DelugeVPN console to the same NzbGet container using unraid host IP (192.168.11.111) and docker network IP (172.17.0.3)
 

sh-5.1# curl -v 192.168.11.111:6789
*   Trying 192.168.11.111:6789...
* connect to 192.168.11.111 port 6789 failed: Connection timed out
* Failed to connect to 192.168.11.111 port 6789: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to 192.168.11.111 port 6789: Connection timed out
sh-5.1# curl -v 172.17.0.3:6789
*   Trying 172.17.0.3:6789...
* Connected to 172.17.0.3 (172.17.0.3) port 6789 (#0)
> GET / HTTP/1.1
> Host: 172.17.0.3:6789
> User-Agent: curl/7.75.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Basic realm="NZBGet"
< Connection: close
< Content-Type: text/plain
< Content-Length: 0
< Server: nzbget-21.0
< 
* Closing connection 0
sh-5.1# 

 

Edit: retested after resetting nzbget port numbers back to defaults. Raised issue on github: https://github.com/binhex/arch-delugevpn/issues/258

Edited by Jorgen
Link to comment
19 minutes ago, gordonempire said:

If other containers are being passed into the DelugeVPN using the "--net=container:<name of vpn container>" option, does Privoxy need to be used? I'm thinking it doesn't but I just want to be sure. I seem to have everything working but the logs are showing that Privoxy stops and keeps being started.

Looking at my logs I am seeing this as well.

2021-02-26 18:45:14,261 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2021-02-26 18:45:15,272 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2021-02-26 18:45:15,278 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

2021-02-26 18:45:45,335 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

 

  • Like 1
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.