54 minutes ago, PeterB said:

Well, have you placed a .ovpn file in /config/openvpn/?

You download the .ovpn files from your vpn provider and place the appropriate one in that location.

yup - i had netherlands in there - just found out it was bunk and fixed it by moving to toronto 🙂 woot.

Hello,

 

I recently had an IP leak incident. I'm just trying to figure out how it happened so it doesn't happen again. Did you implement a leak prevention mechanism that shuts off torrents if the VPN goes down? If so is there a way I can test it?

 

Thanks

Hello,
 
I recently had an IP leak incident. I'm just trying to figure out how it happened so it doesn't happen again. Did you implement a leak prevention mechanism that shuts off torrents if the VPN goes down? If so is there a way I can test it?
 
Thanks

Documentation link in op, see VPN faq its answered in there.

Sent from my EML-L29 using Tapatalk

8 minutes ago, binhex said:

Documentation link in op, see VPN faq its answered in there.

Sent from my EML-L29 using Tapatalk
 

Ok that's what I thought. Well I'm here to say it's not working. This morning I shutdown my containers to perform a backup. When I switched the containers back on it appears that for a very brief time deluge was up and accessing the internet without the VPN. I know it's not supposed to but it appears it did. Any idea how that could have happened?

18 minutes ago, David Woods said:

Any idea how that could have happened?

that should not be possible, there is a blocking script in place that prevents deluge from running until a valid ip is shown against the tunnel adapter, unless this happens deluge cannot start.

 

if you have the supervisord.log file for the period then please attach it here. or pm me it.

41 minutes ago, David Woods said:

Ok that's what I thought. Well I'm here to say it's not working. This morning I shutdown my containers to perform a backup. When I switched the containers back on it appears that for a very brief time deluge was up and accessing the internet without the VPN. I know it's not supposed to but it appears it did. Any idea how that could have happened?

I'm sorry, I'm not trying to be an ass, but sounds like BS to me. How do you know it's not working? Since you asked how you could check for IP leakage I'm guessing you don't have the knowledge to do so yourself? So what changed between your first and second post? Did you read up on how to use wireshark or something and actually test it? And I find it very unlikely that between your docker backup this morning and the supposed leakage you got some letter from your ISP delivered to you by express mail (or a drone maybe). Because how else would you know it was an IP leak when you don't know how to test it? If my assumption is wrong I apologize, but your story sounds like total BS to me. If not,  you surely have some proof of your theory?  

hmm ok so a bit more of a stare at the code, im going to put in an additional blocking check, this will verify the default chain policy of 'block' is set for all chains before going on to perform a check for the vpn tunnel running, and finally only then allowing the app to start. its a belts and braces approach, the current order of startup means iptables must be configured first before the tunnel is established, and the app wont start until the tunnel is established so i am still confused as to how this has happened.

i will be working on this asap and hope to have something ready to release tonight.

 

i have done extensive packet analysis when the iptables are in place and im confident they are solid, so this is the only thing i can currently come up with as an additional check, the only real way of knowing for sure would be if you had captured all packets going in and out of your host, which im pretty sure you haven't right?.

7 minutes ago, binhex said:

so i am still confused as to how this has happened.

So you're saying there actually was a leak?  LOL, then I actually have to apologize  The whole story didn't add up to me, but ok.. 

So you're saying there actually was a leak?  LOL, then I actually have to apologize [emoji14] The whole story didn't add up to me, but ok.. 

Not that I'm aware of, no and I can't see how it could happen but I'm going to put in more checks just incase.  

Edit I guess what I'm trying to say is at this point I have to believe the user's post that they had an IP lesk, but I cannot see how the leak could of happened but I'm willing to put additional checks in.

 

 

 

 

1 hour ago, strike said:

I'm sorry, I'm not trying to be an ass, but sounds like BS to me. How do you know it's not working? Since you asked how you could check for IP leakage I'm guessing you don't have the knowledge to do so yourself? So what changed between your first and second post? Did you read up on how to use wireshark or something and actually test it? And I find it very unlikely that between your docker backup this morning and the supposed leakage you got some letter from your ISP delivered to you by express mail (or a drone maybe). Because how else would you know it was an IP leak when you don't know how to test it? If my assumption is wrong I apologize, but your story sounds like total BS to me. If not,  you surely have some proof of your theory?  

Unfortunately true. Apparently, Canada's notice and notice system is so streamlined that they can send out emails within minutes/hours. I was suspicious too but  I validated the email was indeed from my ISP, the IP they had was mine and the time lined up exactly with the end of my backup.

Unfortunately true. Apparently, Canada's notice and notice system is so streamlined that they can send out emails within minutes/hours. I was suspicious too but  I validated the email was indeed from my ISP, the IP they had was mine and the time lined up exactly with the end of my backup.

Do you use sonarr/radarr etc? If so have you configured these to use a proxy?

Sent from my EML-L29 using Tapatalk

 

 

 

2

2 hours ago, binhex said:

that should not be possible, there is a blocking script in place that prevents deluge from running until a valid ip is shown against the tunnel adapter, unless this happens deluge cannot start.

 

if you have the supervisord.log file for the period then please attach it here. or pm me it.

 

So I pilled my supervisord.log and was reading it over for this morning and it looked... odd. It looked like the full startup script didn't run. So I went back to my scripts and realized that I didn't fully shut down the container. Instead, I just paused and unpaused it, and it was when I unpaused it that the leak happened. I'll send you a private message with my logs from last night and this morning so you can have a look.

4 minutes ago, binhex said:

Do you use sonarr/radarr etc? If so have you configured these to use a proxy?

Sent from my EML-L29 using Tapatalk
 

Yes I do, and No they aren't using a proxy, but the notice email clearly said that the protocol was bittorrent and deluge is the only bittorrent client I have running.

45 minutes ago, David Woods said:

So I went back to my scripts and realized that I didn't fully shut down the container. Instead, I just paused and unpaused it, and it was when I unpaused it that the leak happened.

This could be the cause i have done no testing around pause/resume of a container, i have no idea what order the processes will resume in, and it is potentially possible that the deluge process may resume before iptables rules are re-written. The problem is i dont really see an easy way to do any checks for this to prevent it from occurring, so it maybe either really difficult or just plain impossible, i will have to have a think about it.

 

i can do some digging into this and try and replicate the issue, but obviously for now this would be my top culprit and therefore i would not recommend pausing and resuming of this particular container, instead perform a docker stop and start to ensure proper startup order is performed.

Edited June 15, 20197 yr by binhex

24 minutes ago, binhex said:

This could be the cause i have done no testing around pause/resume of a container, i have no idea what order the processes will resume in, and it is potentially possible that the deluge process may resume before iptables rules are re-written. The problem is i dont really see an easy way to do any checks for this to prevent it from occurring, so it maybe either really difficult or just plain impossible, i will have to have a think about it.

 

i can do some digging into this and try and replicate the issue, but obviously for now this would be my top culprit and therefore i would not recommend pausing and resuming of this particular container, instead perform a docker stop and start to ensure proper startup order is performed.

Will do. Thanks very much!

Hey, just wondering if upgrading the container to Deluge 2.0.3 was on the horizon. Thanks for all the hard work!

34 minutes ago, LrrrAc said:

Hey, just wondering if upgrading the container to Deluge 2.0.3 was on the horizon. Thanks for all the hard work!

 

On 6/13/2019 at 4:20 PM, binhex said:

As soon as it's updated on arch repo it will be automatically built.

Sent from my EML-L29 using Tapatalk
 

 

Just updated this and now will not start.  Here is error seeing:

 

2019-06-18 16:25:33,320 DEBG 'start-script' stderr output:
insmod: ERROR: could not load module /lib/modules/iptable_mangle.ko: No such file or directory

2019-06-18 16:25:33,320 DEBG 'start-script' stdout output:
[warn] Unable to load iptable_mangle module, you will not be able to connect to the applications Web UI or Privoxy outside of your LAN
[info] unRAID/Ubuntu users: Please attempt to load the module by executing the following on your host: '/sbin/modprobe iptable_mangle'
[info] Synology users: Please attempt to load the module by executing the following on your host: 'insmod /lib/modules/iptable_mangle.ko'

2019-06-18 16:25:33,331 DEBG 'start-script' stdout output:
[info] Docker network defined as 172.17.0.0/16

Seeing this error in the log since upgrading to the deluge 2.0 version:

 

2019-06-19 00:33:39,400 DEBG 'watchdog-script' stderr output:
/home/nobody/deluge.sh: /home/nobody/config_deluge.py: /usr/bin/python2: bad interpreter: No such file or directory

 

I changed the shebang on line 1 to "#!/usr/bin/python3" and modified the print statements to be python3 compatible and all is working.

54 minutes ago, no1home said:

Seeing this error in the log since upgrading to the deluge 2.0 version:

 

How?  I'm told that I'm on latest and deluge is still at 1.3.15

20 minutes ago, PeterB said:

How?  I'm told that I'm on latest and deluge is still at 1.3.15

Try "Check for Updates" on the Docker page.

14 minutes ago, no1home said:

Try "Check for Updates" on the Docker page.

Okay, got it now - was being stupid!

Seeing this error in the log since upgrading to the deluge 2.0 version:
 
2019-06-19 00:33:39,400 DEBG 'watchdog-script' stderr output:
/home/nobody/deluge.sh: /home/nobody/config_deluge.py: /usr/bin/python2: bad interpreter: No such file or directory
 
I changed the shebang on line 1 to "#!/usr/bin/python3" and modified the print statements to be python3 compatible and all is working.

Thanks for this I will sort it shortly

Sent from my EML-L29 using Tapatalk

Didn't realise v2.0 was ready for prime time, good job deluge devs!

 

Hopefully a smooth transition as I understand it was a complete rewrite, have a few plugins and custom settings.

Might just freeze auto updates for a bit while I get on top of some other maintenance first.

I've just inadvertently moved to 2.0, is there any way to move back to the previous version? My 1.5k-ish torrents have all vanished! Also , 2.0 isn't whitelisted all all private sites

 

Edited June 19, 20197 yr by loz678