[Support] binhex - DelugeVPN


Recommended Posts

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.

  • Like 1
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
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.
  • Like 2
Link to comment
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.

  • Like 2
Link to comment
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 comment
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
  • Like 2
Link to comment
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 comment

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
  • Like 3
Link to comment
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 comment
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
  • Like 1
Link to comment
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
  • Like 1
Link to comment

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 comment

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

  • Thanks 1
Link to comment
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 comment
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 comment
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 comment
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 comment
On 2/25/2021 at 9:38 PM, binhex said:

can you screenshot the config in sonarr for the 'download client'

 

edit - just checked this by routing sonarr through rtorrentvpn (should be the same as delugevpn) and after setting the sonarr download client settings correctly it tests fine, see screenshot below for my config, note the host should be localhost (on the same network) and port should be the container side port for the web ui or api:-

 

image.thumb.png.24d87d7a2260cc1d8067e8dccea1da53.png

 

Im having problems with binhex-radarr connection to binhex-delugevpn for downloads. 

image.thumb.png.c03b8947c2d8fa2db4663ee3ba626f6e.png

 

binhex-sonarr with setup like this is working:

 

image.png.96765019ec8cb42626b709cffe5c6ee4.png

 

@binhex any clues where i should start checking?

Edited by orlando500
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.