[Support] binhex - DelugeVPN


Recommended Posts

12 minutes ago, nekromantik said:

i tried and same issue so updated original post to remove that line as it happens on both settings

 

If sonarr and radarr also are on a custom bridge network that's why. They all need to be on the normal bridge. All containers using a custom bridge network are isolated from the host. 

Link to comment
3 minutes ago, strike said:

If sonarr and radarr also are on a custom bridge network that's why. They all need to be on the normal bridge. All containers using a custom bridge network are isolated from the host. 

I tried and still same issue, Its not that.

To rule out the custom bridge I downloaded another Deluge container and set up in custom bridge and it worked. Sonarr and Raddar can connect.

So this issue is only on the binhex ones but I prefer binhex as he includes VPN built in.

this is not a issue with host this is container to container. I can access the UI fine. Bridge or custom bridge both. Its just contaner to container that does not work. All containers can connect to 8118 on this but not on 8112.

Edited by nekromantik
Link to comment
4 minutes ago, nekromantik said:

I tried and still same issue, Its not that.

To rule out the custom bridge I downloaded another Deluge container and set up in custom bridge and it worked. Sonarr and Raddar can connect.

So this issue is only on the binhex ones but I prefer binhex as he includes VPN built in.

I'm sure the other deluge container worked with custom bridge but that doesn't mean this container should too. There are strict iptables rules in place in this container to prevent leakage, which may block the connection. Post your docker run command for delugevpn and radarr and a screenshot of the deluge settings in radarr. Have you confirmed you have a working vpn tunnel? What error do you get trying to connect to deluge?

Link to comment
21 hours ago, strike said:

Yeah, this container doesn't support that.

Thanks Strike. All is working well now. I was using a different version of DelugeVPN that did support it previously, running the binhex one now and missed seeing that it needed to be in bridge. All good though! It's been awhile since I've had to troubleshoot anything, so it was good for me :)

Link to comment
11 minutes ago, strike said:

I'm sure the other deluge container worked with custom bridge but that doesn't mean this container should too. There are strict iptables rules in place in this container to prevent leakage, which may block the connection. Post your docker run command for delugevpn and radarr and a screenshot of the deluge settings in radarr. Have you confirmed you have a working vpn tunnel? What error do you get trying to connect to deluge?

Not sure why iptables would block the webUI port as thats not the port thats used for downloading torrents.

Yes the VPN is running fine.

I did not use docker run as I just used unRaid templates. attached the images

Error is it just times out when connecting to Deluge

deluge1.jpg

deluge2.jpg

radarr.jpg

radarr2.jpg

Edited by nekromantik
Link to comment
14 minutes ago, nekromantik said:

Not sure why iptables would block the webUI port as thats not the port thats used for downloading torrents.

Yes the VPN is running fine.

I did not use docker run as I just used unRaid templates. attached the images

Well, you are still on a custom bridge network, which I told you isn't supported by this container. Change to normal bridge on all the containers which need to talk to each other. Then change the IP in radarr/sonarr. You also have issues with your volume mappings which doesn't match so you'll also need to correct that for the containers to work together. I'm referring to your downloads mapping. 

Edited by strike
Link to comment
13 minutes ago, nekromantik said:

Not sure why iptables would block the webUI port as thats not the port thats used for downloading torrents.

Yes the VPN is running fine.

I did not use docker run as I just used unRaid templates. attached the images

Error is it just times out when connecting to Deluge

deluge1.jpg

deluge2.jpg

radarr.jpg

radarr2.jpg

Hey Nekromantik, this was exactly the issue I had when I switched the the binhex DelugeVPN docker to solve the PIA issue. You need to have it and Radarr/Sonarr all in bridge mode, not using their own IPs. Once I made that change everything was off to the races again.

Link to comment
18 hours ago, j2los said:

One of my trackers has blocked port 6890. I can't seem to override the default port. Is that hardcoded into this app? I see when I launch the container I get a 'watchdog-script' output saying it sets the port to 6890. 

Not sure if my question got lost or it's just stupid. Where can I alter this 'watchdog-script'? 

Link to comment

Because its been asked a few times - Yes i am working on WireGuard support now for PIA, its going ok but there is a fair bit to integrate it with the existing code so it may take a little while to code, but hopefully should be done fairly 'soon' (trademark limtech 🙂).

 

WireGuard users using other VPN providers (non PIA) - Question for you, is your wireguard config file static, or is there any dynamically generated parts to it?, please detail what is dynamic (if anything) and your VPN provider name please, im trying to make any code i do VPN provider agnostic as much as possible.

  • Like 3
Link to comment
5 minutes ago, whitewraith said:

I am still unable to get deluge to connect using pia and the nex-gen openvpn files. Is there another change I have to make?  I thought it was delete the old gen files and replace with the nex-gen cert files amd open vpn location file.

did you update your docker image?

Link to comment
9 minutes ago, wgstarks said:

Guess I'll see if PIA will issue refunds.

I get it, but before you go through that hassle, maybe try one of the other binhex vpn enabled torrent clients to see if you can salvage the situation. The beauty of containers is that you can set up multiple versions to test without tearing down what you already have. I guess it boils down to how you want to spend your time.

Link to comment
1 hour ago, dukiethecorgi said:

PIA announces that the legacy servers will shut down at the end of October

 

Now that the next gen server support is in the latest, I guess it's time for me to update

I get they are moving over to next gen but all their update on their helpdesk site stated they were having problems with port forwarding on legacy servers and where "working to fix the issue". I think its now fair to say they had no intention to fix the issue. PIA is always trying to claim transparency but a move like this really doesn't give me any confidence. I'm sure port forwarding matters to a very small percentage of their customer base but its still a feature of their service that should work.

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