[Support] binhex - DelugeVPN


8723 posts in this topic Last Reply

Recommended Posts

14 minutes ago, Jorgen said:

Yes, you need to get Jackett working first.

I don't use jacket via Proxy, so I'm just guessing here, but could you try using the IP of unraid, instead of "tower" for Proxy URL?

Unfortunately that does not change anything. Using the IP of my Unraid server in lieu of "tower" still yields the same error message when I try to test my indexers in Jackett.

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

18 minutes ago, ryanclark21 said:

 

Here is the supervisord.log with the user/pass redacted. Although I'm unable to access the WebGUI, I know it's running in the background as one of the sites it's connected to shows that I'm still seeding. I will note that prior to the most recent update, I was able to access the WebGUI with the same settings.

 

 

2021-03-03 15:14:18.957400 [info] LAN_NETWORK defined as '192.168.1.0/24'

 

Yeah that looks like a successful start and all settings seems to be ok. Are you sure the LAN_NETWORK range is correct?
If it is, maybe it's a problem on the web browser end, try disabling ad blockers, clear the cache and/or try accessing deluge from a private window or different browser?

Link to post
32 minutes ago, Jorgen said:

Yeah that looks like a successful start and all settings seems to be ok. Are you sure the LAN_NETWORK range is correct?
If it is, maybe it's a problem on the web browser end, try disabling ad blockers, clear the cache and/or try accessing deluge from a private window or different browser?

Genius suggestion! Everything is working as it should be (with the previous version). Somewhere along the line in trying to figure out how to revert to the previous version, the LAN_NETWORK range must have reset to the docker default. Thank you for putting and end to hours of searching for answers. Cheers.

Link to post
Unfortunately that does not change anything. Using the IP of my Unraid server in lieu of "tower" still yields the same error message when I try to test my indexers in Jackett.

Looking back at other posts about Jackett and proxy, I think the easiest would be to not use it via proxy and instead bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
It will have its own quirks to work through though, read the other FAQ entries around network binding.


Sent from my iPhone using Tapatalk
Link to post
2 hours ago, Jorgen said:

There's a fix coming for this, see https://github.com/binhex/arch-delugevpn/issues/258

Although, if you want to run NzbGet through a VPN tunnel, an alternative is to use the normal binhex NzbGet container and bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Yeah, binding nzbget to DelugeVPN was going to be the next thing I tried.

 

@Rollingsound514: I also suggest replacing tower with your IP address. The only other thing that’s different with Jackett is there doesn’t appear to be a setting for ignoring your local IP addresses. I had the same issue as you gave with Jackett with Radarr/Sonarr/Lidarr until I added my local IP range to the ignore list in the proxy settings of these dockers.  Ultimately, I think we’re in the same boat and should bind these dockers to DelugeVPN.

Link to post
46 minutes ago, Jorgen said:


Looking back at other posts about Jackett and proxy, I think the easiest would be to not use it via proxy and instead bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
It will have its own quirks to work through though, read the other FAQ entries around network binding.


Sent from my iPhone using Tapatalk

So I tried that earlier, but I tried again just to confirm.

1.png.9eb933d286e338992597c085c38db318.png

There's the start of Q24 from the FAQ...

 

2.thumb.png.c4d972ff02991fb70596236c178f2cdc.png

Here's what I changed my Jackett container to:

  1. Added the extra parameter as dictated. I assume "binhex-delugevpn" is the VPN container name? If not, I don't know what is.
  2. Switched Network type to none
  3. Removed what used to be the first environment variable. It was the port setting, which was previously 9117. 

Unfortunately, this results in a failed Docker restart. "The command failed." And then my docker page shows an orphan image where binhex-jackett used to be. So something isn't right. 

 

Thanks for the help so far. I'm eager to go down the path of binding Jackett to the VPN container. However, it seems awfully strange that Jackett literally has a setting for this (which would allow me to tell Jackett to just use privoxy), and we're unable to do that anymore...

Link to post
13 minutes ago, RollinDolan said:

So I tried that earlier, but I tried again just to confirm.

1.png.9eb933d286e338992597c085c38db318.png

There's the start of Q24 from the FAQ...

 

2.thumb.png.c4d972ff02991fb70596236c178f2cdc.png

Here's what I changed my Jackett container to:

  1. Added the extra parameter as dictated. I assume "binhex-delugevpn" is the VPN container name? If not, I don't know what is.
  2. Switched Network type to none
  3. Removed what used to be the first environment variable. It was the port setting, which was previously 9117. 

Unfortunately, this results in a failed Docker restart. "The command failed." And then my docker page shows an orphan image where binhex-jackett used to be. So something isn't right. 

 

Thanks for the help so far. I'm eager to go down the path of binding Jackett to the VPN container. However, it seems awfully strange that Jackett literally has a setting for this (which would allow me to tell Jackett to just use privoxy), and we're unable to do that anymore...

That looks exactly like my setup which works. The only thing I can think of is there might be invisible characters or spaces in the Extra Parameters. Remove the orphaned image, reinstall Jackett from previous apps in CA and edit the Extra Parameters field by typing in the "--net..." line manually instead of copy/paste.

After it's downloaded and unpacked, copy the full run command and paste it here if the container still fails to start.

 

Which version of unraid are you on?

Link to post
33 minutes ago, RollinDolan said:

As another point that privoxy should "just work", it looks like binhex stated we shouldn't need to do all this setup if we just want to use privoxy as usual.

 

Here's the post. Maybe I'm misunderstanding.

 

Now, what should we do? That I don't know. 

Well, it does work for Sonarr and Radarr, I think Binhex assumed Jackett would work the same, but it's obviously a special case from all the  posts here.

I don't know what to do about it either, apart from moving Jackett into the VPN network, maybe Binhex can weigh in at some point to clarify if there are other options.

 

Edit: wgstarks has the solution, see posts below

Edited by Jorgen
Link to post
1 minute ago, Jorgen said:

Well, it does work for Sonarr and Radarr, I think Binhex assumed Jackett would work the same, but it's obviously a special case from all the  posts here.

I don't know what to do about it either, apart from moving Jackett into the VPN network, maybe Binhex can weigh in at some point to clarify if there are other options.

It works for me using the IP of the docker network. docker0 in my case.

Link to post
46 minutes ago, betaman said:

Ok, so I pulled the latest docker image for DelugeVPN and manually added “VPN_OUTPUT_PORTS” env variable. I set value to port of NZBgetVPN (6789) but still can’t connect to it inside of the *arr containers?

 

AB3B934B-292F-4477-A2C3-862410CEF927.jpeg

Sorry mate, I re-read you initial post and I think I misunderstood your setup.

I thought you were binding the *arr apps to the delugeVPN network, but you are actually just using the proxy, right?

In that case I pointed you in the wrong direction and can't really help as I don't know how NzbGetVPN works.

Link to post
29 minutes ago, RollinDolan said:

So I tried that earlier, but I tried again just to confirm.

1.png.9eb933d286e338992597c085c38db318.png

There's the start of Q24 from the FAQ...

 

2.thumb.png.c4d972ff02991fb70596236c178f2cdc.png

Here's what I changed my Jackett container to:

  1. Added the extra parameter as dictated. I assume "binhex-delugevpn" is the VPN container name? If not, I don't know what is.
  2. Switched Network type to none
  3. Removed what used to be the first environment variable. It was the port setting, which was previously 9117. 

Unfortunately, this results in a failed Docker restart. "The command failed." And then my docker page shows an orphan image where binhex-jackett used to be. So something isn't right. 

 

Thanks for the help so far. I'm eager to go down the path of binding Jackett to the VPN container. However, it seems awfully strange that Jackett literally has a setting for this (which would allow me to tell Jackett to just use privoxy), and we're unable to do that anymore...


The SpaceInvader video did not delete the port variable.  I'm not sure if that makes a difference.  I know it is contrary to what the instructions specify.

Link to post
2 minutes ago, wgstarks said:

It works for me using the IP of the docker network. docker0 in my case.

Ah, interesting. Could you share a screenshot of the Jacket proxy settings?

Is that a 172.x.x.x IP?

Link to post
1 minute ago, Jorgen said:

Ah, interesting. Could you share a screenshot of the Jacket proxy settings?

Is that a 172.x.x.x IP?

6F43EBF9-519D-48F7-B6CD-5E4893A11C59.thumb.png.6322395647108a11ecf791667e0657dd.png
 

Sorry, I can’t remember the terminal command to lookup the IP.

Link to post
2 minutes ago, wgstarks said:

6F43EBF9-519D-48F7-B6CD-5E4893A11C59.thumb.png.6322395647108a11ecf791667e0657dd.png
 

Sorry, I can’t remember the terminal command to lookup the IP.

 

No terminal command required, it's shown on the docker page in unraid:

image.png.2987c414eac4454728e812e831eeaba0.png

 

One thing to keep in mind if you go down this route (pun intended) is that the docker IP is dynamcially assigned and could change on restart of containers or the unraid server. If things always start in the same order it probably won't, but just be aware of it if things suddenly stops working again.

 

Link to post
18 minutes ago, Jorgen said:

Well, it does work for Sonarr and Radarr, I think Binhex assumed Jackett would work the same, but it's obviously a special case from all the  posts here.

I don't know what to do about it either, apart from moving Jackett into the VPN network, maybe Binhex can weigh in at some point to clarify if there are other options.

Sorry, I should have been more specific. By "just work", I meant that binhex's post looked like I should not need to route anything through the VPN container. I did not previously route anything through the VPN container - instead, I just told Jackett to use privoxy as its proxy.

 

The "working solution" for Sonarr and Radarr is routing them through the VPN container. I already have a working method to that (using Jackett in Sonarr and Radarr).

 

Note - Jackett through privoxy in lieu of everything-through-container seems to be binhex's preferred method. Yet we can't get guidance on it.

 

To answer your above question - I'm on Unraid 6.9.0

 

I also tried wgstarks' method: I used ifconfig to get the local IP of my docker container (I wasn't sure if you meant the deluge docker or the jackett docker, so I tried both...) and it didn't work. Same errors after saving the new IP through the Jackett gui. It was a very similar looking 172.xxx address.

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

Sorry, I should have been more specific. By "just work", I meant that binhex's post looked like I should not need to route anything through the VPN container. I did not previously route anything through the VPN container - instead, I just told Jackett to use privoxy as its proxy.

 

The "working solution" for Sonarr and Radarr is routing them through the VPN container. I already have a working method to that (using Jackett in Sonarr and Radarr).

 

Note - Jackett through privoxy in lieu of everything-through-container seems to be binhex's preferred method. Yet we can't get guidance on it.

 

To answer your above question - I'm on Unraid 6.9.0

 

I also tried wgstarks' method: I used ifconfig to get the local IP of my docker container (I wasn't sure if you meant the deluge docker or the jackett docker, so I tried both...) and it didn't work. Same errors after saving the new IP through the Jackett gui. It was a very similar looking 172.xxx address.

In Jackett proxy config you should use the 172.17.x.x IP of the DelugeVPN container. I think this also assumes that both Jackett and DelugeVPN containers are using the same docker network, which is bridge by default:

 

Screen Shot 2021-03-04 at 2.17.36 pm.png

Link to post
19 minutes ago, Jorgen said:

Sorry mate, I re-read you initial post and I think I misunderstood your setup.

I thought you were binding the *arr apps to the delugeVPN network, but you are actually just using the proxy, right?

In that case I pointed you in the wrong direction and can't really help as I don't know how NzbGetVPN works.

No worries. Yeah I’m just using Privoxy thru DelugeVPN. In theory, NZBgetVPN should behave just like DelugeVPN except that binnex doesn’t manage a version of it...

Link to post
26 minutes ago, Jorgen said:

In Jackett proxy config you should use the 172.17.x.x IP of the DelugeVPN container. I think this also assumes that both Jackett and DelugeVPN containers are using the same docker network, which is bridge by default:

 

Screen Shot 2021-03-04 at 2.17.36 pm.png

Right, thanks. I tried that - no dice.

 

However, I'm now noticing that my deluge docker logs are showing "Sending 'down' command to WireGuard due to dns failure"

I didn't change my wireguard configs. I didn't change any of my PrivateInternetAccess config. I didn't change anything related to DNS / name servers.

 

This worked yesterday. Sigh... guess I'll figure out what else got broken from the update.

Link to post
9 minutes ago, RollinDolan said:

Right, thanks. I tried that - no dice.

 

However, I'm now noticing that my deluge docker logs are showing "Sending 'down' command to WireGuard due to dns failure"

I didn't change my wireguard configs. I didn't change any of my PrivateInternetAccess config. I didn't change anything related to DNS / name servers.

 

This worked yesterday. Sigh... guess I'll figure out what else got broken from the update.

ok, there was a bug in the container updates yesterday in regards to wireguard. Try forcing an update now and see if it fixes it, binhex pushed a fix a few hours ago.

Link to post
4 hours ago, Jorgen said:

ok, there was a bug in the container updates yesterday in regards to wireguard. Try forcing an update now and see if it fixes it, binhex pushed a fix a few hours ago.

Updated the container and it is now working, thanks Jorgen.

Link to post

Would someone be able to help me install 3rd party plugins? Or are they just still broken as I have read previously?

 

I have the latest unRAID and container. Installing from the plugin menu is broken, never had that working. So I tried dropping the egg in to the plugin folder (specifically LabelPlus and AutoRemovePlus), both py2.6 and py2.7 versions. They weren't recognized by the plugin menu, even after a restart. Clicking install creates a [File ObjectList] file in the plugin folder which does nothing. 

 

So I did some reading, and figured the python versions were out of sync, and I read that someone recompiled it from the plugin source, so I did that and now I have new egg files with py3.9. Getting closer, these can now be recognized in the plugin menu. When I try to check them, they tick, and then I click apply and/or OK, but nothing happens, and I go immediately back into the menu and they are unticked. Won't stay put. I tried adding them to the conf manually, but this does nothing.

 

Any other ideas? Thanks in advance.

Link to post
1 hour ago, xMaverickx said:

Any other ideas? Thanks in advance.

Have you tried adding the new egg directly to the plugins folder? You also may need to remove -pyX.X from the file name.

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.