[Support] binhex - DelugeVPN


8421 posts in this topic Last Reply

Recommended Posts

I was wondering if anyone else had/has the same issue as i am. After installing and running this docker, I can no longer access any of my dockers that dont use bridge network mode which is quite a bit of an issue for my setup and i would like to revert back to my previously working setup.

 

 

Any help would be greatly appreciated as I am not very familiar with setting up or using IPTables for unraid.  

 

Below is the output for 

iptables -L -v -n

 

Chain INPUT (policy ACCEPT 20812 packets, 5493K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  28M   18G LIBVIRT_INP  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 25238 packets, 17M bytes)
 pkts bytes target     prot opt in     out     source               destination         
1888M 2261G LIBVIRT_FWX  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
1888M 2261G LIBVIRT_FWI  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
1888M 2261G LIBVIRT_FWO  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
1888M 2261G DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
1888M 2261G DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
1084M 1363G ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
 7700  402K DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0           
 591M   88G ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
   14  1472 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 18896 packets, 5692K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  27M   79G LIBVIRT_OUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   40  2080 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.2           tcp dpt:8000
  364 19136 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.3           tcp dpt:7878
  654 34496 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.4           tcp dpt:8989
  244 12736 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.5           tcp dpt:6789
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.6           tcp dpt:9117

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 591M   88G DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0           
1888M 2261G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      docker0  0.0.0.0/0            0.0.0.0/0           
 591M   88G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination         
1888M 2261G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_FWI (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain LIBVIRT_FWO (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0           
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain LIBVIRT_FWX (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_INP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67

Chain LIBVIRT_OUT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68
    0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:68

 

 

 

Link to post
  • Replies 8.4k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

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

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

1 hour ago, binhex said:

IMPORTANT:- As part of the tightening up if you run multiple containers through a single vpn container then please ensure you define all web ui ports (if more than 1 port then use comma to separate) for all routed containers in 'ADDITIONAL_PORTS' env var for the vpn container.

 

Thank you for your continued work on this docker!

 

If I am understanding correctly, I will need to add the port for the WebUI of the other dockers that are using my Deluge docker VPN (Privoxy?) into the 'ADDITIONAL_PORTS' variable, correct?

 

So if I am running your Jackett (9117), Radarr (7878), and Sonarr (8989) dockers as different ports on the same IP I would add the ports these are on into the variable separated by a comma (9117,7878,8989).

Link to post
34 minutes ago, Burizado said:

 

Thank you for your continued work on this docker!

 

If I am understanding correctly, I will need to add the port for the WebUI of the other dockers that are using my Deluge docker VPN (Privoxy?) into the 'ADDITIONAL_PORTS' variable, correct?

 

So if I am running your Jackett (9117), Radarr (7878), and Sonarr (8989) dockers as different ports on the same IP I would add the ports these are on into the variable separated by a comma (9117,7878,8989).

correct on all accounts

Link to post
49 minutes ago, binhex said:

correct on all accounts

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?

 

 

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

Link to post

@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 post
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 post
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 post

I tried setting up Privoxy as well thinking the '--net=container:binhex-delugevpn' argument may be the culprit but still no luck. For now I've rolled back to 2.0.4.dev38+g23a48dd01-3-01 and I'm able to sync back up with the deluge download client 😕

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

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.

Edited by JimmyGerms
Link to post
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 post
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 post
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 post
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
Link to post
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 post
7 minutes ago, diditstart said:

localhost didn't work for me.

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.

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