strike

And you are using an endpoint that supports port forwarding? From what I read on the torguard faq they only support port forwarding on certain locations. I don't know much about docker on windows, maybe something is blocking the port? How does the windows firewall or a third party firewall play with docker? On second thought the firewall shouldn't matter in this case anyway

I don't know which vpn provider you have, but low speed is a typical issue if your vpn provider does not support port forwarding. Torrenting requires an open incoming port to get decent speed. So be sure you have a open port and set that in deluge, or switch vpn provider if they don't support port forwarding. If you have done that and still have issues you should stop the container, turn on the debug flag, delete the supervisord.log file in /config, start the container and let it run a few min. then post the entire supervisord.log file here. Be sure to redact any username/password in the log before you do.

This container already has iptables rules set up so you don't need to worry about that.

I remembered now that you probably have to set up the deluge authentication file in order to connect with the thin client. I think I seen that mentioned before. You should then follow this form the faq. It's referring to couchpotato but I think it applies in your case to I messed with this once a long time ago when I used CP and I remember I had to add a new line on top with my user:pass:10 in order to get it to work, so try that if you don't have any success

No, I mean on the remote router, port 58846 needs to be forwarded to your server. I assume you (or someone where your server is located) has forwarded ports on the remote router before. Because in order to get the jwilder nginx container to work port 443 needs to be forwarded to your server, and your container is obviously working so someone must have done it. Also I hope you have set up authentication for your services behind the reverse proxy, or else anybody can mess with them. Specially now when you have published your domain name and all. You might want to get on that asap if you don't have authentication set up.

I've never seen that warning before so I don't have a clue if it's something to worry about or not. Hmm.. and the port is forwarded? Probably should post a new supervisord.log file again, I'm not sure I'll be able to help anymore as I've never tried to connect with the deluge thin client, but a new log is always good

Then this is the delugevpn container IP not 10.x.x.x "IPAddress": "172.17.0.3", Then execute the command from the log in my last post, you probably have to stop the container, run the command and start the container. Check the log if the warning is gone

Check the log, I think it's in the faq too IIRC 018-02-23 00:35:21,376 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 2018-02-23 00:35:21,376 DEBG 'start-script' stdout output: [info] unRAID/Ubuntu users: Please attempt to load the module by executing the following on your host: '/sbin/modprobe iptable_mangle' I don't know what distro you're on so maybe the command could be different, google will probably help you then is this the same ip listed under IPAddress (look at the bottom) if you run docker inspect <ContainerNameOrId>

Ah I see.. :) Then I believe you have to forward port 58846 I think you also need the iptable-mangle-something module loaded on the host (see the delugevpn faq, there will be a message in the log if this is not loaded) Without that you can't connect remotely. You mention radarr (radarr.saitoh183.com), are you running that as a docker too? If so just do what you did with radarr, looks like you did exactly what I mean. It's the same thing You also mention the IP 10.x.x.x is this your machine's IP or are you referring to the docker network? I have never tried docker outside unraid but I believe you don't access the docker with the dockerIP:8112 but the "local machine IP":8112 locally that is. Between your home pc and the remote server yeah.

Should work (if you use this already on the remote server then you must have ports forwarded or else it wouldn't work. You at least need port 443 forwarded to get this to work) Yeah, if you can't install a openvpn client on the thin client then this is your best option Yes, you would install a OpenVPN-AS server on the remote machine and then use any openvpn client to connect securely to the server. This is not instead of delugevpn, it's just so you can access the remote network securely and be able to access delugevpn from your browser. But if you cant install a openvpn client on your thin client, then this won't work. (If so then the reverse proxy is your best bet) I don't know what kind of access you have on that thin client. But as I said all options require port forwarding on the remote side so check this first.

You'll either have to 1: Forward 8112 on the remote router, then you can connect to sub.domain.com:8112 but so will everybody else so that's not really secure 2: Install a docker like openvpn , setup that so you can connect to the whole remote network securely (best option) You will then access deluge via the 10.x.x.x IP 3. setup a reverse proxy with maybe the let's encrypt docker so you get a ssl certificate on your domain, and setup password authentication with htpasswd. You then access deluge via sub.domain.com/deluge or just sub.domain.com your choice. This can be setup for most dockers (second best option) All of them require forwarding ports on the remote router.

The built-in antivirus in OSX is quarantining the.ovpn file. Exlude the file in your antivirus app and you should be good

Hmm, then I have no clue, better wait for the expert @binhex

You should be able to run both containers and use the same vpn provider, I've seen several people say they run both. I wouldn't recommend using the proxy with the non-vpn deluge container due to the fact there is no iptables rules in place to stop deluge from using your normal connection when the tunnel drops and then your IP could leak.

I also spotted this in your log when reading it a second time and it might be why you have connection issues. On the airvpn forums there are several posts mentioning NOT to use tun-mtu directive but instead use the "mssfix"

There is none in the unraid community but there is one on dockerhub you could try that. Just enable CA to search dockerhub and you should find it. Here is the duckhub link: https://hub.docker.com/r/andymeful/privoxy-openvpn/

I don't understand your question. OpenVPN AS and DelugeVPN are used for completely different purposes. OpenVPN AS is for connecting a vpn tunnel between a remote location to your home network, so you can access your network securely. DelugeVPN is torent client with built-in vpn for creating a vpn tunnel from your home network to a (usually paid) vpn subscription for hiding you real IP adress. Which are you trying to accomplish? Edit: I think I understand now after reading your post again. You just want to use the privoxy feature to be able to route an app through the vpn tunnel? Then no, I don't think there is a "lighter way". The easiest way is to use one of binhex's vpn containers to do that.

From what I can see from your config /downloads isn't mapped to anything. So how can deluge move anything from /downloads when it isn't mapped in your config? Edit: or it's: completed for headphones in your config? I can't see the container mapping so I don't know

Don't think so. Just run both vpn containers, but enable privoxy one just one of them

I think this is the issue. But please post the entire supervisord.log file with debug enabled. Be sure to remove your vpn user/pass

If your router's IP is 192.168.1.1 your Lan_network should be 192.168.1.0/24

@repentharlequin Your LAN_Network is wrong, think it should be 192.168.0.0/24

I think you need to post a new log after you've let the container run for a few min. From the log you posted the container was running just a few seconds.

Please enable debug logging by setting the debug variable to true, delete the supervisord.log file, restart the container and let it run for a few min. then post a new log. BUT I strongly suggest you try another VPN provider (AirVPN or PIA are good ones) as you'll get really low speed due to the fact that NordVPN does not support port forwarding.

Have you tried to change the host port to 80 in the docker template like I suggested earlier? In your screenshot it still says 81. I get that it's on its own IP and you have port forwarded 80->80 on that IP but that won't do you any good if the host port in the docker template is still 81. Unless the container ignores that completely when it's on its own IP?