[Support] binhex - DelugeVPN


8747 posts in this topic Last Reply

Recommended Posts

29 minutes ago, binhex said:

i need more details, please screenshot your sonarr and radarr settings for a start, a few questions for you to answer too:-

 

1. are you routing any containers through a vpn container, if so which ones?

2. have you defined LAN_NETWORK for your vpn container, if so what is it and what is your servers ip address?

3. are you using custom bridge, staitc ip addresses or maclvlan for any of your containers? if so which ones and what are the values of each?.

I posted screenshots of my setup a few posts up. Please let me know if you need more screenshots

 

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

2. Yes, my unraid server IP is 10.100.1.3, and my LAN_NETWORK is defined as 10.100.1.0/24.

image.thumb.png.5cca5fbe90f3f864f6bcfe4a673a9cc9.png

3. Yes, I have a couple containers set with static IPs (pihole and guacamole) that I can no longer access when I point a physical device to the deluge proxy. Containers using my "proxynet" vlan work fine. When I try to connect to the Unraid web gui using a physical device pointed to the proxy IP/port, it gives me a privoxy error.

 

I will try to go through it again and get more screenshots of all of the errors, but tempted to just wait.

Edited by carnivorebrah
Link to post
  • Replies 8.7k
  • 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

8 minutes ago, binhex said:

i need more details, please screenshot your sonarr and radarr settings for a start, a few questions for you to answer too:-

 

1. are you routing any containers through a vpn container, if so which ones?

2. have you defined LAN_NETWORK for your vpn container, if so what is it and what is your servers ip address?

3. are you using custom bridge, staitc ip addresses or maclvlan for any of your containers? if so which ones and what are the values of each?.

1. only using privoxy, nothing going through a container.

2. 192.168.10.0/24 server 192.168.10.10

3. Deluge,Radarr,Sonarr all set to bridge

 

I'm not very knowledgeable on Unriad so just used spaceinvaders vids to setup a few years ago :)

 

Sonarr:

image.png.5d3b09b37899294e255e41f8a768676d.pngimage.png.709e493743ebd57a3d720dc4b66ebcd4.pngimage.png.685c8b7acc3eb9bb5ded6f91ef7d258a.png

Radarr:

image.png.2d45335500f13523719c092402bc6683.pngimage.thumb.png.2fede2183285ca727276857735b1d656.pngimage.png.884dcf280efd85666019540151d88d5d.png

Link to post

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.

Edited by MammothJerk
Link to post
8 hours ago, carnivorebrah said:

I tried those steps, but they didn't work for me. See screenshots in a few posts above.

 

Also, when I point any physical device to the DelugeVPN proxy, I cannot connect to the Unraid web UI on that device.

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.

Edited by storagehound
Link to post
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
Link to post
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.

Link to post
9 hours ago, gordonempire said:

To roll back, I changed the repository from:

binhex/arch-delugevpn

To:

binhex/arch-delugevpn:2.0.4.dev38_g23a48dd01-3-01

 

2 minutes ago, strahd_zarovich said:

 

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

 

See above to roll back.

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

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

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 post
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).

 

Link to post

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

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 post
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 post
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 post
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

Link to post

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

So I am not sure how would fix this.  I want Jackett, Sonarr, Radarr and Lidarr to use my proxy in delugevpn.  I am trying to fix where to add the ports for these dockers.  I see when I edit binhex-delugevpn just option for ADDITIONAL_PORTS but only a True/False field.

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.