[Support] binhex - DelugeVPN


Recommended Posts

4 minutes ago, celborn said:

Firstly, thank you for updating the docker and helping keep the community strong.

 

Secondly, would I need to do the same for dockers that are not using the same IP address and not using the VPN?

 

 

im not 100% sure on the question, but to be clear, you only need to specify web ui ports for ADDITIONAL_PORTS for containers that you are routing through one of the vpn images i produce, if you have a container that doesnt require a vpn then you dont need to change anything for that container

  • Thanks 1
Link to comment

@binhex Updated to the latest but even with the ports added to ADDITIONAL_PORTS everything connected to the VPN times out and I get a:

Unknown exception: The operation has timed out.: 'http://[redacted]:8112/json'

Sonarr and Radarr can not connect to the DelugeVPN.

I am using "container:binhex-delugevpn" for the network setup. Would this be an issue?

 

EDIT: I'm also able to get to the Web-UIs with no issue, just cannot connect to deluge.

Edited by JimmyGerms
Link to comment
2 hours ago, binhex said:

im not 100% sure on the question, but to be clear, you only need to specify web ui ports for ADDITIONAL_PORTS for containers that you are routing through one of the vpn images i produce, if you have a container that doesnt require a vpn then you dont need to change anything for that container

I guess the question would be, is there something done when the docker performs the "[debug] Waiting for iptables chain policies to be in place..." that would cause dockers that are assigned a different IP address (while on the same 192.168.1.0/20 network) to be no longer accessible?

Link to comment
1 hour ago, JimmyGerms said:

@binhex Updated to the latest but even with the ports added to ADDITIONAL_PORTS everything connected to the VPN times out and I get a:


Unknown exception: The operation has timed out.: 'http://[redacted]:8112/json'

Sonarr and Radarr can not connect to the DelugeVPN.

I am using "container:binhex-delugevpn" for the network setup. Would this be an issue?

 

EDIT: I'm also able to get to the Web-UIs with no issue, just cannot connect to deluge.

 

I'm having the same issue, I assumed I was doing something wrong but I've added the Radarr/Sonarr ports to my Deluge/Sabnzbd containers using the ADDITIONAL_PORTS key but the download client communication tests timeout.

Link to comment
1 hour ago, JimmyGerms said:

EDIT: I'm also able to get to the Web-UIs with no issue

the web ui's? im assuming you mean of sonarr and radarr right?.

 

1 hour ago, JimmyGerms said:

Unknown exception: The operation has timed out.: 'http://[redacted]:8112/json'

this sounds like an unrelated issue to the iptables changes, please do the following:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Link to comment
37 minutes ago, celborn said:

"[debug] Waiting for iptables chain policies to be in place..."

this message is shown whilst iptables is set to deny for everything, so yes indirectly this maybe related, but this particular line of code being excuted will not be the cause as this was in place before the change.

 

38 minutes ago, celborn said:

that would cause dockers that are assigned a different IP address (while on the same 192.168.1.0/20 network) to be no longer accessible?

can you expand on this, are you using a custom bridge or macvlan, are any of them routed through another container?, do any of them use proxy's?.

40 minutes ago, celborn said:

192.168.1.0/20 network

are you sure about that cidr notation?, see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Link to comment
3 minutes ago, binhex said:

the web ui's? im assuming you mean of sonarr and radarr right?.

Yes, sorry for the confusion there. I meant the ui's for Sonarr and Radarr were still accessible. The two dockers were just throwing an issue about connecting to Deluge during "test connection". Running "curl ifconfig.io" in sonarr and radarr's docker terminals are using the same IP as Deluge but for some reason those two programs have issues linking back up to the download client.

I'll try and grab some logs later today!

Link to comment
13 minutes ago, JimmyGerms said:

Running "curl ifconfig.io" in sonarr and radarr's docker terminals are using the same IP as Deluge

i take it by this you mean radarr and sonarr are both routed through delugevpn right? and they cannot communicate with deluge, have i got this correct?

Link to comment
15 minutes ago, JimmyGerms said:

Sounds like you've got it! Sonarr and Radarr are using the IP from DelugeVPN but cannot communicate with the deluge docker itself. Rolling back to 2.0.4.dev38+g23a48dd01-3-01 I'm up and running again.

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

Link to comment
1 minute ago, JimmyGerms said:

This what you mean? I think you can guess the normal setup for the Host but I'm paranoid so...yeah haha. But I pass with this setup on the previous version.

your host is the problem, if sonarr is connected to delugevpn network then you should be setting sonarr to talk to deluge over localhost, NOT the unraid host, switch it over and it should test fine with the old image, then upgrade and it should test fine there too - see my previous post above.

Link to comment
9 minutes ago, binhex said:

can you expand on this, are you using a custom bridge or macvlan, are any of them routed through another container?, do any of them use proxy's?.

Custom: br0. And, as far as i know the containers arent routed through other containers or proxies. 

 

9 minutes ago, binhex said:

are you sure about that cidr notation?, see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

sorry it was 192.168.1.0/24

 

here is a screen shot of my Radarr docker setting for clarification.

 

image.thumb.png.0efcd440f8fef0c58f3aa0d4259bdfff.png

Link to comment
9 minutes ago, binhex said:

your host is the problem, if sonarr is connected to delugevpn network then you should be setting sonarr to talk to deluge over localhost, NOT the unraid host, switch it over and it should test fine with the old image, then upgrade and it should test fine there too - see my previous post above.

 

You have to take the "app" side ip. Something like 172.17.0.3. At least that's how I got everything working again, localhost didn't work for me.

 

 

Screen Shot 2021-02-25 at 1.06.09 PM.png

Edited by diditstart
  • Like 1
Link to comment
1 minute ago, JimmyGerms said:

Well...I feel like a fool. localhost worked for me. Could you give a quick breakdown of why that is? Networking is confusing as f to me.

you had it configured so that sonarr had to go from the delugevpn network (remember sonarr and deluge are both in the same network here) to the host, then from the host back to the container again, this is inefficient and not required, if you network bind multiple containers then they should all be set to localost in order to talk to each other, they are in essence all connected to the same virtual nic.

Link to comment
6 minutes ago, binhex said:

works for me and @JimmyGerms 🙂

 

make sure you specify the container side port number as well, NOT the host side port, as you are talking directly within the same network.

 

Is this only for the new updated Deluge setup?

 

I was trying to use 'localhost' before I updated Deluge and I get an error, but when I specify the IP 192.168.0.178 it tests good.  I understand what you are saying about it being inefficient, and would like to make it more so.  The screens show my setup in Radarr.  It doesn't show in the bottom option in the download client setup, but I don't have 'Use SSL' checked.

2021-02-25 16_19_26-Window.png

2021-02-25 16_18_37-Window.png

Link to comment
13 minutes ago, binhex said:

works for me and @JimmyGerms 🙂

 

make sure you specify the container side port number as well, NOT the host side port, as you are talking directly within the same network.

My docker networking might be a bit messed up since I've never really cleaned up that part after years of experimenting with stuff. But the docker IP's seem to work.

Link to comment
23 minutes ago, Burizado said:

Is this only for the new updated Deluge setup?

due to tightening of iptables its now a requirement to use localhost WHEN routing containers through the same network, however its really highlighting a bad configuration, as previously mentioned you should be using localhost, no point in sending outbound traffic to your host for it only to be routed back again!.

Link to comment
13 minutes ago, JimmyGerms said:

but was curious if there was a way to set the Host within the Jackett docker?

i dont really follow sorry, the way i would do it is set sonarr and radarr to talk to jackett using localhost again, this is the correct way to do it (assuming jackett, sonarr, radarr, and your download client are all using the same network).

Link to comment

Sorry, I ended up deleting that post and moved it to the proper thread. Didn't mean to bog down the thread. I can explain a bit more over there maybe? But for now I've just replaced the '192.168.1.blah' with 'localhost' after clicking on the copy buttons. Think we're back! Thank you so much for the help! I get it a bit more now.

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.