[Support] binhex - DelugeVPN


8752 posts in this topic Last Reply

Recommended Posts

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 post
  • Replies 8.8k
  • 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

Just saw the notes on the IP leak, fixes, and required config changes.

 

I've gotta say, I was expecting to wrestle with it for a bit, but it was quick and easy to get things changed and get everything back working.

 

Thanks for all your efforts @binhex!

Link to post

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.

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

 

Link to post
1 hour ago, storagehound said:

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

 

This is the exact reason I was asking. :D

 

Reading that back it sounded kinda snarky. Not intended. I wasn't going to mention the Privoxy starting and stopping initially, but forgot that I did include it.

Edited by gordonempire
My own absent-mindedness.
Link to post
1 hour ago, gordonempire said:

This is the exact reason I was asking. :D

 

Reading that back it sounded kinda snarky. Not intended. I wasn't going to mention the Privoxy starting and stopping initially, but forgot that I did include it.

Personally, I didn't think it was snarky.  I thought it was a good question.

Link to post

Since the last update I have turned privoxy off, but delugevpn still won't load now using mullvad. I am getting this error in the logs:

 

Was working fine before the last update

delugevpnerror.PNG

Link to post
4 hours ago, storagehound said:

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

 

I see the same in my logs and I am setup to use the privoxy in Deluge, with Radarr/Sonarr/Jackett all setup to use it.  I am assuming they are using it but I don't know of a way to test if they are actually using it.  I think Jackett is the only container that truely is going outside my network as Radarr and Sonarr I think just connect within my network.

Link to post
14 hours ago, carnivorebrah said:

 

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

 

 

Thank you all for alll the help. This post helped me fix my issue. I had to add the adresses/full subnet to the ignored line as the checkbox failed to do its job... Quick fix that just required some deep digging to sort out. What a pain in the pooper lol

 

Thanks everyone for being such a wonderful source of info! ❤️

Edited by Liquidbings
Link to post
4 hours ago, Antibios said:

Suddenly my client is reporting wrong info to my trackers and getting me blacklisted.  They all support deluge 2.0.X so it is reporting something else after the last update.  Any help is appreciated

Me too :(

tracker sent a failure message "Error 002"

Link to post

For folks having issues - I was as well - do read the FAQ carefully. I tend to skim or rush these things and pay the price. I had set this up ages ago and things have changed - at least it looks that way to me anyways. I used the original SPace Inavder video ages ago and then over the years added wireguard, new PIA servers, etc.
 

  • Per the FAQ, I had to remove the ports from the containers runing into DelugeVPN (new for me)
  • Expose the ports on DelugeVPN (I did have this)
  • Add the "ADDITIONAL_PORTS" variable (new for me)


After struggling with it last night and downgrading to proove I could get it to work, coffee and slowing down and reading the FAQ very closely sorted me. 🙂

I have a simple setup as I just run NZBGet and Hydra2 though the VPN so your mileage may vary....

Edited by TexasDave
Link to post
On 2/25/2021 at 5:04 PM, NGDM said:

I'm running your latest docker image on my Synology D916+ and am now receiving following error message in the supervisord.log:


FATAL: kernel too old

 

I'm not using Wireguard or anything. Possible something you added in this latest one isn't compatible with our older kernel?

 

Edit: returned to 2.0.4.dev38_g23a48dd01-3-01 and all is good again. Let me know if I can test anything.

 

I have the same issue. Guess we need to wait until Synology finally updates their DSM..

 

Link to post
3 hours ago, Wetterchen said:

Me too :(

tracker sent a failure message "Error 002"

 

So i have new information here. 

The support from the tracker said the Client send a false peer_id.

Normaly the code beginning with "-DE..." 

But now its beginning with "--DE".. thats wrong and the Tracker blocked me. 

Its happend with the release of the latest version. 

 

I rolled back to binhex/arch-delugevpn:2.0.4.dev38_g23a48dd01-3-01 and all working fine again. 

Edited by Wetterchen
Link to post
10 hours ago, Antibios said:

Suddenly my client is reporting wrong info to my trackers and getting me blacklisted.  They all support deluge 2.0.X so it is reporting something else after the last update.  Any help is appreciated

I'm also having this problem on trackers which support Deluge 2.0.x. They report "Your client version is not whitelisted."

 

I suspect that https://github.com/binhex/arch-delugevpn/commit/08b611e5058bb5f84b6d4f4adf5eed864fa86c6c is the reason why.

Edited by webvictim
Add Github commit
Link to post

Hello, 

I've been trolling this forum and googling my brains out (YT included) for 3 days now and i can't seem to find out how to get devulgevpn working with my VPN. 

Disclaimer - 6 days into my unraid trial and same for Docker...I've managed to get rid of my Buffalo NAS, moved my plexserver and my PiVPN to Unraid. 

I'm struggling to figure out how to point DevulgeVPN through my openVPN server (container on UnRaid now). I created the OpenVPN-as server then tested it with my laptop to make sure it works. (it does)

I then a setup my UnRaid IP:1194 in the DelugeVPN server name field. (NAME_SERVERS) Dropped the .ovpn file into the appdata ovpn folder.  Can someone point my in the right direction?

 

OpenVPN-as config:

image.png.7b7e70d8312c92c622883d6c1028db2e.png

 

DelugeCPN Config:

image.png.db8eee79da0c9a89507c266e63906a58.png

image.png.da895bcfeedcd5cc17f6482df65cbf81.png

image.png.075c61b102318a4acb060d3663a71cd8.png

 

Running: UnRaid 6.8.3

Edited by Jayg37
Link to post

I am sorry to say that I am i am in the same boot and I am very confused.

like many other people I have the suite of of dockers form Binhex and where I have linked them together to for VPN access

 

I have my Sonnar, Radarr and Jackett all pointing to my DelugeVPN

 

I have read the instructors and I have added the following information into deluge.

image.thumb.png.4325e317fb9e28b57856dfadf332319d.png

 

Container running VPN

Left click icon and 'Edit' container and toggle advanced view (top right).

Click on 'Add another Path, Port, Variable, Label or Device' and add in a 'config type' of 'port'.

Enter in Web UI port for 'container port' and any non conflicting port number for 'Host Port' (host port must not be used by another container).

Edit 'ADDITIONAL_PORTS' env var and put Web UI port number in value, if multiple ports required then use a comma to separate.

Click on 'Apply'."   didn't need to do this as this ADDITIONAL_PORTS was all ready there and all I did was add the port's

 

as a test I then when into Jackett and change the IP address to Localhost and I got the following error

image.png.985d02346ad3dedc5a848cd5a58f4df7.png

which happens on all of my indexers

and here is my settings for jackett

image.png.48f6f9d8d69e1e5d6129424f82a4d372.png

 

so I would like to know is where are we all going wrong ?

 

PS. I am also using Jdownloader and this is working fine, as this also points to delugeVPN

 

 

 

 

image.png

Edited by chris_netsmart
Link to post
55 minutes ago, Jayg37 said:

Hello, 

I've been trolling this forum and googling my brains out (YT included) for 3 days now and i can't seem to find out how to get devulgevpn working with my VPN

I think you misunderstand. This docker is for use with vpn providers such as Private Internet Access. You don’t need to run it through a self hosted vpn. You just need an account with a supported provider.

Link to post
1 hour ago, webvictim said:

I'm also having this problem on trackers which support Deluge 2.0.x. They report "Your client version is not whitelisted."

 

I suspect that https://github.com/binhex/arch-delugevpn/commit/08b611e5058bb5f84b6d4f4adf5eed864fa86c6c is the reason why.


Is it possible to roll back the docker image install on my setup? I tried removing the current install and re-installing a different docker from another repo and the whitelist message is still happening but I'm betting they're in the same downstream

Link to post
21 minutes ago, Antibios said:


Is it possible to roll back the docker image install on my setup? I tried removing the current install and re-installing a different docker from another repo and the whitelist message is still happening but I'm betting they're in the same downstream

Yes. Just add a dash and the release number after the name in the repository field in the container settings. Releases can be found here- https://github.com/binhex/arch-delugevpn/releases

 

FYI- I don’t believe that there have been any changes to the app recently, just the container.

Link to post
7 hours ago, Wetterchen said:

 

So i have new information here. 

The support from the tracker said the Client send a false peer_id.

Normaly the code beginning with "-DE..." 

But now its beginning with "--DE".. thats wrong and the Tracker blocked me. 

Its happend with the release of the latest version. 

 

I rolled back to binhex/arch-delugevpn:2.0.4.dev38_g23a48dd01-3-01 and all working fine again. 

 

4 hours ago, webvictim said:

I'm also having this problem on trackers which support Deluge 2.0.x. They report "Your client version is not whitelisted."

 

I suspect that https://github.com/binhex/arch-delugevpn/commit/08b611e5058bb5f84b6d4f4adf5eed864fa86c6c is the reason why.

 

Thanks guys. With this info I used the ltConfig plugin to change peer_fingerprint to -DE204D- and the tracker was happy again with the new docker version. -DE203s- works also. Btw, the error I was receiving from my tracker was "Error: Anonymous client". Couldn't figure it out without your help.

Link to post
27 minutes ago, no1home said:

 

 

Thanks guys. With this info I used the ltConfig plugin to change peer_fingerprint to -DE204D- and the tracker was happy again with the new docker version. -DE203s- works also. Btw, the error I was receiving from my tracker was "Error: Anonymous client". Couldn't figure it out without your help.

thanks for the info, fixed and new image now building with correct peer_id

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