20 hours ago, strike said:

In your downloads settings in deluge change the download to path to /data

I also recommend having a complete an incomplete folders. So consider changing the download to path to /data/Incomplete and check the move completed to and add the path /data/Complete. Feel free to use any folder names you want, mine was just an example but /data is a must have since in your template have mapped /data to /media/Plex/Inprogress 

If I'm understanding this correctly it should look like this? However, this didn't seem to solve it. 

 

Edited January 17, 20215 yr by ifruit

3 hours ago, powderwt said:

seems to still be happening, even though ive updated both endpoints to several new ones, and a new .ovpn file

supervisord_01_17_2021_Censored.log 2.47 MB · 2 downloads

Are you sure you've downloaded a new .ovpn file from your vpn provider? In your log I see mention of

VPN remote server(s) defined as 'unraidunity.duckdns.org,'

and:

OpenVPN config file (ovpn extension) is located at /config/openvpn/client.ovpn

 

I don't use mullvad, but usually a provider calls their ovpn file something based on the region of that endpoint. Like before you had CA.mullvad.ovpn or something which tells me you're trying to connect to Canada. But now your ovpn file is just called client.ovpn and the fact that you have named the remote line a duckdns domain tells me something might be off.

 

See also Q17 here: what the repeating messages in your log means: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

4 minutes ago, ifruit said:

If I'm understanding this correctly it should look like this?

 

Yes, but set the download to path to /data/Incomplete then you should be good and your downloads should start fine.

15 minutes ago, strike said:

Yes, but set the download to path to /data/Incomplete then you should be good and your downloads should start fine.

Okay so I think I'm almost finally there, I rewatched spaceinvaderone's video on this and followed it word for word with setting up the new share for downloads and all that. I'm thinking that my issue may be that my PIA OVPN file I chose doesn't support port forwarding? Because after restarting the whole container from scratch and setting up the share it looks like this. I titled my download folders incomplete  and completed

4 minutes ago, ifruit said:

my issue may be that my PIA OVPN file I chose doesn't support port forwarding?

Yes, you should absolutely change to a endpoint that supports port forwarding

4 minutes ago, strike said:

Yes, you should absolutely change to a endpoint that supports port forwarding

So I went ahead and did that found one for PIA that supported it (CA VANCOUVER) and added it to my openvpn file for deluge.

 

However, it still connects initially and then the peers drop off. I feel like it has to be something to do with my paths and mapping right? Because even when its starts initially no folder is created within the incomplete folder.

 

Here is my updated file mappings after redoing them. 

Your mappings looks fine now. And you have restarted the container right? Have you tried a well seeded torrent like ubuntu or something?

6 minutes ago, strike said:

Your mappings looks fine now. And you have restarted the container right? Have you tried a well seeded torrent like ubuntu or something?

I'll go ahead and give that a shot. Thanks for working with me on this!

2 hours ago, strike said:

Are you sure you've downloaded a new .ovpn file from your vpn provider? In your log I see mention of

VPN remote server(s) defined as 'unraidunity.duckdns.org,'

and:

OpenVPN config file (ovpn extension) is located at /config/openvpn/client.ovpn

 

I don't use mullvad, but usually a provider calls their ovpn file something based on the region of that endpoint. Like before you had CA.mullvad.ovpn or something which tells me you're trying to connect to Canada. But now your ovpn file is just called client.ovpn and the fact that you have named the remote line a duckdns domain tells me something might be off.

 

See also Q17 here: what the repeating messages in your log means: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Correct, I tried downloading packages for: netherlands, CA_montreal, CA_toronto, and a couple others to no avail.

 

The client.ovpn file is an ovpn file I managed to find in my backups that I had saved and decided to give it a go since it was known working with that prior.

On 1/16/2021 at 12:53 AM, strike said:

@thestraycat Please post the full supervisord.log file in your next post (redact username/pw etc). And please also post your docker run command and a screenshot of the deluge downloads settings.

 

@strike Thanks buddy. Fixed it. 

 

 

This having so many posts has made it hard to find if anyone has answered this before.

 

Great container @binhex, and great support from @SpaceInvaderOne

 

I followed the guides to get this setup and passing other containers through this one, no problem, working great.. apart from external access.

 

I used to be able to access the other containers externally. So lets say I have open port 3579 and it was going to a local container. That was working fine. When I route it through this container, I can access it locally using [IP]:[port], however if I try and access from outside my network.. nothing.. dead.

 

I assume looking at the routes there is something wrong here. You appear to be adding a route that sends traffic from our network (LAN_NETWORK) back out over ETH0, other sources (apart from dockers network) are sent out over tun0.

 

My guess (but I can't tell, as I can't see the package manager you are using to install tcpdump) is that traffic is getting to my destination container, but routing back out over the tun0 for some reason.

 

My other guess is that privoxy is actually getting the request with the DNS on it, and not understanding how to route it correctly as it doesn't know its local (DNS Edge device ip pinning)

 

Are you able to help either discover the route that is needed to be added to the table, or other another idea, like using another container to proxy access to the hidden containers now? I know there are other options, like connecting to my home network via VPN, but, at least for me, I have a couple of these now (Work etc) and switch them all the time is not as convenient.

 

Hoping someone with a little more networking knowledge than me can help.

8 minutes ago, mrforsythexter said:

When I route it through this container, I can access it locally using [IP]:[port], however if I try and access from outside my network.. nothing.. dead.

 

possibly related to iptable_mangle not being loaded, see Q2:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

On 1/17/2021 at 5:31 PM, strike said:

Your mappings looks fine now. And you have restarted the container right? Have you tried a well seeded torrent like ubuntu or something?

Finally got around to giving it a shot and still no luck. Any other ideas?

8 hours ago, ifruit said:

Finally got around to giving it a shot and still no luck. Any other ideas?

Actually I finally got it solved, I deleted the whole folder in appdata for deluge and started over and that solved it. 

On 1/19/2021 at 10:19 AM, binhex said:

 

possibly related to iptable_mangle not being loaded, see Q2:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

hi @binhex would have loved that to be the answer, I have checked its loaded using

 

lsmod | grep iptable_mangle
iptable_mangle         16384  2
ip_tables              24576  5 iptable_filter,iptable_nat,iptable_mangl

 

and completed a reboot, however this is still not working for other containers which have been passed through yours. (added the port to yours, change other container to network none and added extra param --net=container:binhex-delugevpn)

 

I can see that container is using your network (PIA), but can't then get to the webgui of this other container.

 

any more Idea's?

1 hour ago, mrforsythexter said:

I can see that container is using your network (PIA), but can't then get to the webgui of this other container.

 

but you CAN access the web ui of the other container when inside your lan?

Hello All!

 

I'm new to unraid and apologize in advance for any stupid questions.  I searched the forum but have not found anything for the issue i'm encountering.

 

I have installed this succesffully and believe i configured everythign properly, but my vpn will not connect.  I'm using IPVanish, and downloaded and copied over the .ovpn file.

 

I'm receiving the following error message when the docker is starting.  Not sure what other information to provide so please let me know if there is anything else I can provide to help!

 

2021-01-20 19:06:33,125 DEBG 'start-script' stdout output:
[debug] OpenVPN command line:- /usr/bin/openvpn --reneg-sec 0 --mute-replay-warnings --auth-nocache --setenv VPN_PROV 'custom' --setenv VPN_CLIENT 'openvpn' --setenv DEBUG 'true' --setenv VPN_DEVICE_TYPE 'tun0' --setenv VPN_ENABLED 'yes' --setenv VPN_REMOTE_SERVER 'nyc-a69.ipvanish.com' --setenv APPLICATION 'deluge' --script-security 2 --writepid /root/openvpn.pid --remap-usr1 SIGHUP --log-append /dev/stdout --pull-filter ignore 'up' --pull-filter ignore 'down' --pull-filter ignore 'route-ipv6' --pull-filter ignore 'ifconfig-ipv6' --pull-filter ignore 'tun-ipv6' --pull-filter ignore 'dhcp-option DNS6' --pull-filter ignore 'persist-tun' --pull-filter ignore 'reneg-sec' --up /root/openvpnup.sh --up-delay --up-restart --keepalive 10 60 --auth-user-pass credentials.conf ipvanish-US-New-York-nyc-a69.ipvanish.com --cd /config/openvpn --config '/config/openvpn/ipvanish-US-New-York-nyc-a69.ovpn' --remote 64.145.79.176 443 udp --remote-random
[info] Starting OpenVPN (non daemonised)...

2021-01-20 19:06:33,128 DEBG 'start-script' stdout output:
Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: auth-user-pass (2.5.0)
Use --help for more information.

 

 

Thank you!

 

I can not get above 1.2MB down using DelugeVPN in a container. I am connecting through NordVPN and I have tried more than 10 different servers, some p2p some not, some UDP and some TCP. I have another computer in the room that I can download the same torrents on qBittorent to the share at over 40MB (I have Gb/s fiber).

 

I used these instructions for the install:

1) Grab the ovpn files from Nord by filling out your country and P2P from here: https://nordvpn.com/servers/tools/ I clicked my region, advanced and then p2p, and then OpenVPN TCP
2) Go to the docker containers and make sure you add binhex-delugevpn
3) I changed my "Host Path 2:" variable to a new share (done with spaceinvaderOnes tutorial mentioned in thread) which maps to: /mnt/user/Downloads/
4) Make sure VPN_Enabled is yes
5) Enter your NordVPN user and pass for Key's 2 and 3 (VPN_USER, VPN_PASS)
6) Set VPN_PROV to Custom
7) Edit your LAN network to reflect your personal network (mine is 192.168.2.x so I changed LAN_NETWORK value to: 192.168.2.0/24
8) Click Apply to create the docker
9) Navigate to your Appdata/binhex-delugevpn/openvpn/
10) Drop in the ovpn file from step 1
11) restart the delugeVPN docker and sign in, default pass is: deluge
12) Check that your IP is protected! in the bottom righthand corner it will show your Public facing IP, you can check the NORDVPN IP by doing a ping on the server address obtained from step1 to see about what it should be.

 

It is all being written to a share on the cache drive that is a SSD, so no bottleneck there.

 

Any ideas?

 

 

 

12 hours ago, stelks said:

I can not get above 1.2MB down using DelugeVPN in a container. I am connecting through NordVPN and I have tried more than 10 different servers, some p2p some not, some UDP and some TCP. I have another computer in the room that I can download the same torrents on qBittorent to the share at over 40MB (I have Gb/s fiber).

 

I used these instructions for the install:

1) Grab the ovpn files from Nord by filling out your country and P2P from here: https://nordvpn.com/servers/tools/ I clicked my region, advanced and then p2p, and then OpenVPN TCP
2) Go to the docker containers and make sure you add binhex-delugevpn
3) I changed my "Host Path 2:" variable to a new share (done with spaceinvaderOnes tutorial mentioned in thread) which maps to: /mnt/user/Downloads/
4) Make sure VPN_Enabled is yes
5) Enter your NordVPN user and pass for Key's 2 and 3 (VPN_USER, VPN_PASS)
6) Set VPN_PROV to Custom
7) Edit your LAN network to reflect your personal network (mine is 192.168.2.x so I changed LAN_NETWORK value to: 192.168.2.0/24
8) Click Apply to create the docker
9) Navigate to your Appdata/binhex-delugevpn/openvpn/
10) Drop in the ovpn file from step 1
11) restart the delugeVPN docker and sign in, default pass is: deluge
12) Check that your IP is protected! in the bottom righthand corner it will show your Public facing IP, you can check the NORDVPN IP by doing a ping on the server address obtained from step1 to see about what it should be.

 

It is all being written to a share on the cache drive that is a SSD, so no bottleneck there.

 

Any ideas?

 

 

 

see Q6:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Anyone else seeing TLS handshake failures?  I see the following in my log every minute or so, and can no longer connect to the WebGUI.  I recently updated my docker containers, and I believe it was working fine before the last update.  Could it be related to the ciphers warnings?  

 

2021-01-21 09:22:33,410 DEBG 'start-script' stdout output:
2021-01-21 09:22:33 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-01-21 09:22:33 TLS Error: TLS handshake failed

2021-01-21 09:22:33,410 DEBG 'start-script' stdout output:
2021-01-21 09:22:33 SIGHUP[soft,tls-error] received, process restarting

2021-01-21 09:22:33,411 DEBG 'start-script' stdout output:
2021-01-21 09:22:33 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.

2021-01-21 09:22:33,411 DEBG 'start-script' stdout output:
2021-01-21 09:22:33 WARNING: file 'credentials.conf' is group or others accessible
2021-01-21 09:22:33 OpenVPN 2.5.0 [git:makepkg/a73072d8f780e888+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov  6 2020
2021-01-21 09:22:33 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
2021-01-21 09:22:33 Restart pause, 5 second(s)

2021-01-21 09:22:38,411 DEBG 'start-script' stdout output:
2021-01-21 09:22:38 WARNING: --ping should normally be used with --ping-restart or --ping-exit
2021-01-21 09:22:38 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2021-01-21 09:22:38,412 DEBG 'start-script' stdout output:
2021-01-21 09:22:38 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2021-01-21 09:22:38 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2021-01-21 09:22:38 TCP/UDP: Preserving recently used remote address: [AF_INET]134.19.189.171:1194
2021-01-21 09:22:38 Socket Buffers: R=[212992->212992] S=[212992->212992]
2021-01-21 09:22:38 UDP link local: (not bound)
2021-01-21 09:22:38 UDP link remote: [AF_INET]134.19.189.171:1194

2021-01-21 09:23:38,818 DEBG 'start-script' stdout output:
2021-01-21 09:23:38 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-01-21 09:23:38 TLS Error: TLS handshake failed

2021-01-21 09:23:38,819 DEBG 'start-script' stdout output:
2021-01-21 09:23:38 SIGHUP[soft,tls-error] received, process restarting

2021-01-21 09:23:38,820 DEBG 'start-script' stdout output:
2021-01-21 09:23:38 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.

 

In the FAQ it says if you see the following error you just need to give escalated permissions and turn on the net.ipv4.conf.all.src_valid_mark sysctl. 

Quote

RTNETLINK answers: Operation not permitted

Unable to access interface: Operation not permitted

[#] ip link delete dev wg0

Cannot find device "wg0"

[warn] WireGuard interface failed to come 'up', exit code is '1'

 

Despite this, I have both turned on.  I ran with

Quote

    --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
    --privileged=true \

And I can see they're set when I look at `docker inspect <container>`

I'm running with the latest image.  I've completely removed and did a completely fresh install.  Does anyone know if it just doesn't work with Synology servers or is there something else I'm missing?

 

My launch Params:

docker run -d \
    --name=delugewireguard \
    --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
    --privileged=true \
    -p 8112:8112 \
    -p 8118:8118 \
    -p 58846:58846 \
    -p 58946:58946 \
    -v /volume2/Media/:/data \
    -v /volume1/docker/delugewireguard/config/:/config \
    -v /etc/localtime:/etc/localtime:ro \
    -e VPN_ENABLED=yes \
    -e VPN_USER=p1234567 \
    -e VPN_PASS=password \
    -e VPN_PROV=pia \
    -e VPN_CLIENT=wireguard \
    -e STRICT_PORT_FORWARD=yes \
    -e ENABLE_PRIVOXY=yes \
    -e LAN_NETWORK=192.168.1.0/24 \
    -e NAME_SERVERS=209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1 \
    -e DELUGE_DAEMON_LOG_LEVEL=info \
    -e DELUGE_WEB_LOG_LEVEL=info \
    -e DEBUG=false \
    -e UMASK=000 \
    -e PUID=1026 \
    -e PGID=100 \
    -e TZ=America/Las_Angeles \
    binhex/arch-delugevpn

 

Edited January 22, 20215 yr by stridera

9 hours ago, stridera said:

  Does anyone know if it just doesn't work with Synology servers or is there something else I'm missing?

Synology are running an old kernel, you need kernel 5.2.x or later i think it is, so unless you can load the required kernel modules for wireguard then you are out of luck.

On 1/21/2021 at 7:52 AM, binhex said:

see Q6:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Thank you for the response. I have tried almost everything listed here.

Port forwards are set up.

Disabled in/out utp

Disabled rate limit overhead

It is writing to a cache SSD that is not in a pool. qBittorent on a different computer connected to the same router pulls more than 30Mb down. In Deluge it is a completely flat 1.1Mb. Is there a certain set of logs that would be helpful here to post?

2 minutes ago, stelks said:

Port forwards are set up.

i doubt this, as nordvpn does not offer port forwarding, see Q15 for what i think you have done:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

port forwarding not being operational is no doubt your issue here.

1 minute ago, binhex said:

i doubt this, as nordvpn does not offer port forwarding, see Q15 for what I think you have done:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

port forwarding not being operational is no doubt your issue here.

Ah I get what you are saying, I just forwarded the TCP ports nord says they are using to the ports needed for Deluge. I guess I will try PIA and see if that works better. I have a year and a half left on the nordVPN subscription so that is to bad! Thanks for the help.