binhex

See post #3 if it's still not working then attach supervisord.log

Would you believe I've been so busy as of late that I haven't had chance, will see if I can get something added to OP, it's very nice to see any appreciation of my work either via donation or a simple thanks :-)

that's exactly right. i wouldnt waste your time to be honest, i played with deluge and socks proxy5 in the early days, in short it doesnt work as you expect, if the proxy drops then all your traffic gets routed over your internet connection, NOT good!, this is what lead me down the path of using a vpn tunnel. What i would like to do is to separate openvpn into its own container, have that running and then have another container running application X that you want to have tunnelled and simply link the two containers together, this has the really nice advantage that its only a single vpn tunnel, and means with a bit of scripting for each container you could pick and choose which apps you want tunnelled. OK so here is the kicker, unraid webui doesnt support this configuration, so there is no way of linking the containers together other than getting down and dirty with the CLI, so until thats possible we are where we are right now, maybe if i get time i will put in a feature request for this.

Hi Peter, no im not, i wasnt even aware it existed, it looks interesting, i might take a butchers at it when i get a min, not sure i will use it as im a bit of a control freak when it comes to security, kinda like to control the iptable entries manually, but def will be interesting to see what this does when run, thanks for sharing!!!.

ive just had a bash at explaining this, see post #2 FAQ Q4, i hope i have been clear enough, its quite a tricky thing to explain in a concise way but ive had a go :-), its a VERY useful feature, esp for those of us that have to suffer ISP filtering. im not 100% sure, but i would think yes, they would count as two seperate connections. they would only conflict is the port on the host side was left unmodified, but to be honest there would be no benefit having two instances of privoxy running, so i would recommend just set enable_privoxy to no. ahh right it should be 8118, can you tell me exactly where you see 8181?.

im not sure which is cheaper but i can tell you PIA are pretty darn cheap if you go for a year, i think im paying around £3 per month for unlimited usage, speeds are ok, not lightning fast but adequate for me (approx 800 KB/s to 1.3MB/s DL on a 20Mb/s line)

you beat me to it :-), im assuming you are running unraid right?, bit confused as to why you had this in your log, as this should be reported only if your kernel doesnt support iptable_mangle, im on about this message:- Now that youve fixed your issue with LAN_NETWORK can i ask you to check your supervisord.log file and tell me if it still reports the same thing?, if it does and your running unraid then there is a bug somewhere.

this is not your issue, please can you post the entire supervisord.log file, minus username and password

This sounds like a classic case of the share your using not being marked a "cache only", what this means if you dont do this is the internal unraid process called mover comes along and moves all your files in that share to the array, then when you restart the docker you have no config again, and so the cycle repeats. The way to solve this is to mark the share as "cache only", this tells the mover not to touch any files/folders contained within this share, go to unraid ui/shares/click on share/select from dopdown "use cache disk" the value "only", save and your done. ok this will depend on where couchpotato is installed and how its installed, for now im going to assume couchpotato is installed as another docker on the unraid host, if this is the case then read FAQ Q1 in post #2 of this thread and follow it carefully.

That solved it for me as well! THANKS!! hm looks like the escaping mentioned in the openvpn doc isnt standard bash escaping, for now ive removed this and building a new image right now, either change your password or sit tight and pull down the image in 30 mins.

i think ive spotted an issue, just building now, please do an update in 30 mins. If the issue persists after the update then please post your entire supervisord.log file in /config.

i think ive spotted the issue, just building now, please do an update in 30 mins

Please read post #3

IMPORTANT - Existing users read Hi all, i have made some changes to DelugeVPN which will mean if you pull down the latest image you will now need to alter the name environment variable "LAN_RANGE" to "LAN_NETWORK", you will also now need to define this as <lan network>/<cidr notation> Example CIDR notation below:- subnet mask 255.255.255.0 = CIDR /24 subnet mask 255.255.0.0 = CIDR /16 subnet mask 255.0.0 = CIDR 8 So the env var in the unRAID webui Docker section would end up looking like this:- Variable Name: Variable Value: LAN_NETWORK 192.168.1.0/24 For other configurations please calculate the CIDR using this online calculator http://www.subnet-calculator.com/cidr.php So you might be asking why ive made this change, the reason is that this vastly simplifies the iptables configuration, it also gets around the limitation that the linux kernel has to have iptable_mangle module loaded, which is not a default for most linux distros

The docker image is scripted to automatically do the port forwarding for you (PIA only), i can only assume you are connected to a gateway that doesn't support port forwarding, as not all gateways do, which gateway are you connecting to?.

Probably the % or $ or ^. i think mr-hexen is most probably right, did some research and it looks like you should escape usernames and passwords for OpenVPN auth files, so i have now built this into delugevpn to do this automatically, hopefully that will be last time we see this particular issue.

pm replied to, for anybody else use VyperVPN, here is the link to the zip containing all the ovpn config files for all endpoints:- https://www.goldenfrog.com/openvpn/VyprVPNOpenVPNFiles.zip

No i think your misreading this, 443 will be the port you connect to when establishing the tunnel, i very much doubt this will be your incoming port. To answer your questions though, once you know what the incoming port is then you would define the incoming port in the deluge webui, you dont need to alter iptables at all as all traffic is allowed inbound and outbound for the tunnel. edit - hmm just done some googling for newshosting and i cant find anything relating to incoming port, if i were you i would email them and ask then outright, do you allow incoming ports for the vpn, if so how you do find out what the port is and/or define it?. my gut feeling is that they dont support incoming ports, in which case they are pretty useless for torrents.

yeah i too have been investigating this further for you, i have tested this on my openelec appliance and i can see the same issue, so thats good, took me a while but i have a fix for this by adding in an additional route, im still investigating at this point as i want to get this as tight as possible, i cannot allow any ip leakage so this will be nailed.

It seems I spoke too soon My private tracker told me that my port 32767 is closed. How can I open that on the docker? Do I just map this port on the host and then forward that port from my router ? (don't think so, the port is closed from my VPN IP...) This is going to be down to your vpn provider, as you rightly said above changing the port forward on your router will have no affect on deluge, as this is using a vpn tunnel with port forwarding defined by the end point, i.e. the provider, so you would need to see if you can specify the incoming port for your connection. I know airvpn does give you some configuration for this, PIA doesnt allow you define a static port number, not sure about your provider. Basically you need to investigate how your provider hands out incoming ports (some providers dont allow incoming ports at all), and manually configure deluge to use this, good luck.

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file. Aaah, I've attached the log file and here is the contents of the ovpn file: ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112 I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?. edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name. Yes, trying to connect to the webui from other machines on my lan. Tried used both hostname and IP = no luck I'm not certain whether I have firewall rules defined though, how do I check? type this on your host:- iptables -L This will list out all iptable entries. root@ubuntu:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain DOCKER (1 references) target prot opt source destination ACCEPT tcp -- anywhere 172.17.0.9 tcp dpt:8112 ACCEPT tcp -- anywhere 172.17.0.9 tcp dpt:8118 ok so nothing blocking there, its very odd, have you tried another browser on your client machines?, or tried forcing a clear down of caching, what error are you seeing on the client machines?

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file. Aaah, I've attached the log file and here is the contents of the ovpn file: ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112 I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?. edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name. Yes, trying to connect to the webui from other machines on my lan. Tried used both hostname and IP = no luck I'm not certain whether I have firewall rules defined though, how do I check? type this on your host:- iptables -L This will list out all iptable entries.

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file. Aaah, I've attached the log file and here is the contents of the ovpn file: ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112 I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?. edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name.

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file. Aaah, I've attached the log file and here is the contents of the ovpn file: ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

added.