mr-hexen

Have you tried starting / stopping the docker service (not the container, but the service) after the VM on/off thing?

Go into the VM tab, turn VM's on, then off, and try again.

AShman, post up a copy of the docker exec command when you save the sonarr container.

Have you waited sufficiently long? Cloning means downloading from GIT and compiling...

Why not just turn the VPN off? No need to change dockers...or maybe I'm not understanding you correctly.

Yes, I see that (just looked at their pictures). Most of the CyberPower units I've seen (in the US) have two sets of outputs -- one set is battery backed up; the other set are surge only. Quite common as my APC unit in Canada has the same.

That port is used in the DelugeVPN container mapping. Default web for this container is 8080 Myk Right, wrongfully assumed these were the same.

Isn't default 8112 for the admin port?

I expect this docker to see an influx of new users with the recent takedown of KAT and the arrest of it's owner. I'm considering usenet right now too.

Is your appdata share set to cache only? If YES, then set config to /config --> /mnt/cache/appdata/plexmediaserver If NO, then set it to cache only, and move it to the cache drive (might take a while), then change your mappings to /mnt/cache/...

But what's stopping people from mapping their own?

Ok I'll try it in a little while.

UDP is usually the better choice as TCP requires ACK packets for every packet sent where UDP does not. Meaning all things equal UDP should be quicker. In MY case I use TCP because my ISP throttles UDP or its not setup right in the system and speeds are 10%.

Since updating delugevpn I've noticed that paused torrents continually start up by themselves. Might not be such a big issue for some or most, but those who are on metered plans might want to keep an eye out for this so you don't seed yourself into a huge internet bill. I found that the scheduler plugin was the cause and disabled it.

that's cool, no rush :-) No go. Because when the PROV variable is set to PIA a script overwrites the existing files, thereby resetting the lower case aes-128-cbc... If I set the PROV to custom it just spams the log with reset connection and doesn't work. For it to work on TCP/443 I have to set PROV to custom, PORT to 443 and then load my custom .ovpn file. Change the name of the ovpn file to custom.ovpn you can then set it back to pia for the VPN provider Sent from my SM-G900F using Tapatalk Tried that, twice to make sure I wasn't seeing things. It actually removed my custom.ovpn file and replaced it with openvpn.ovpn

To every body reading this thread TCP connections are somewhat unique to me in this recent discussion because my ISP has an issue w/ UDP that essentially neuters my speeds.

that's cool, no rush :-) No go. Because when the PROV variable is set to PIA a script overwrites the existing files, thereby resetting the lower case aes-128-cbc... If I set the PROV to custom it just spams the log with reset connection and doesn't work. For it to work on TCP/443 I have to set PROV to custom, PORT to 443 and then load my custom .ovpn file.

I can but not for about 7 hours from now ...

good catch!, so is this for tcp and udp (and default and strong variants?). That's my undestanding (all certs since July 12). To add to this, apparently there was a delay in updating the actual servers to use the new certs as well. Some servers are still using BF-CBC instead of AES-128-CBC (for default certs). See here for details: https://www.privateinternetaccess.com/forum/discussion/21782/mismatch-config-client-and-server

Seems like PIA might have borked some of the ovpn files.

i wonder if the certs are different depending on whether you choose tcp or udp, i wasnt really expecting them to be, but it might be the case, let me do some md5 checks, i will get back to you. p.s changing the name of the ovpn file to "custom.ovpn" will prevent the overwrite. hmm ok its not the certs, md5 checksum matches for udp and tcp (both default and strong) so its not that, i wonder if pia just have an issue right now with tcp connections with their new certs and encryption ciphers, worth a look on their forum perhaps?. I'll see what I can find there. I did try the tcp certs from their site and opened the ovpn file to check on ports etc. Configured the docker with the same settings and no go. I think it has to do with the AES vs BF decipher as that's the error that pops up. Going back to TCP/443 w/ the old certs everything works fine so that's what I'll use in the mean time. I'll let you know if I find anything on their forums.

So I tried to go back to my original certs and now the docker overwrites the openvpn folder each boot clobbering the tcp certs (I believe this is a result of the new STRONG_CERTS variable. I had to change my provider to "custom" and move my certs back to get it up on TCP/443. I know my use case is a bit of an edge case because my ISP is a arse, but I appreciate the help.

Tried that using "weak certs" (no variable, older template). Command that executes: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="binhex-delugevpn" --net="bridge" --privileged="true" -e VPN_ENABLED="yes" -e VPN_USER="my user" -e VPN_PASS="my password" -e VPN_REMOTE="ca-toronto.privateinternetaccess.com" -e VPN_PORT="502" -e VPN_PROV="pia" -e ENABLE_PRIVOXY="no" -e LAN_NETWORK="192.168.1.0/24" -e VPN_PROTOCOL="tcp" -e TZ="America/New_York" -p 8112:8112/tcp -p 8118:8118/tcp -p 58846:58846/tcp -v "/mnt/cache/docker/config/delugevpn/":"/config":rw -v "/mnt/cache/docker/downloads/":"/data":rw -v "/mnt/cache/docker/downloads":"/downloads":rw binhex/arch-delugevpn Log shows its working: 2016-07-14 17:31:20,565 DEBG 'deluge-script' stdout output: [info] All checks complete, starting Deluge... 2016-07-14 17:31:21,080 DEBG 'webui-script' stdout output: [info] Starting Deluge webui... 2016-07-14 17:31:21,692 DEBG 'deluge-script' stdout output: Setting random_port to False.. Configuration value successfully updated. 2016-07-14 17:31:21,875 DEBG 'deluge-script' stdout output: Setting listen_ports to (34605, 34605).. Configuration value successfully updated. I see two warnings in the log: Thu Jul 14 17:31:17 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1560', remote='link-mtu 1544' Thu Jul 14 17:31:17 2016 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC' Then when I start a download (using ubuntu server official torrent): 2016-07-14 17:34:28,622 DEBG 'start-script' stdout output: Thu Jul 14 17:34:28 2016 Fatal decryption error (process_incoming_link), restarting 2016-07-14 17:34:28,627 DEBG 'start-script' stdout output: Thu Jul 14 17:34:28 2016 /usr/bin/ip addr del dev tun0 local 10.31.1.6 peer 10.31.1.5 2016-07-14 17:34:28,640 DEBG 'start-script' stdout output: Thu Jul 14 17:34:28 2016 SIGUSR1[soft,decryption-error] received, process restarting 2016-07-14 17:34:33,658 DEBG 'start-script' stdout output: Thu Jul 14 17:34:33 2016 Attempting to establish TCP connection with [AF_INET]172.98.67.17:502 [nonblock] 2016-07-14 17:34:34,658 DEBG 'start-script' stdout output: Thu Jul 14 17:34:34 2016 TCP connection established with [AF_INET]172.98.67.17:502 Thu Jul 14 17:34:34 2016 TCPv4_CLIENT link local: [undef] Thu Jul 14 17:34:34 2016 TCPv4_CLIENT link remote: [AF_INET]172.98.67.17:502 2016-07-14 17:34:34,837 DEBG 'start-script' stdout output: Thu Jul 14 17:34:34 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1560', remote='link-mtu 1544' Thu Jul 14 17:34:34 2016 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC' 2016-07-14 17:34:34,837 DEBG 'start-script' stdout output: Thu Jul 14 17:34:34 2016 [1987f7cb6fd9a231bcaa67d5cb2d25a7] Peer Connection Initiated with [AF_INET]172.98.67.17:502

Tried that with: VPN_PROTOCOL: TCP VPN_PORT: 502 as per the PIA manual openvpn config files. It connected, but I began getting decryption errors when a torrent tried to d/l and speeds were 0. I saw a warning that remote/local ciphers didnt match (AES vs BF) so that's likely the cause.

@binhex, I was unable to get the new certs working with a TCP connection. As you might recall my ISP has issues with UDP (maxes out around 1.2MB/s) but TCP maxes out my connection (12.5MB/s). I tried the TCP certs from the PIA website but it kept throwing errors. I saved my previous openvpn folder files and restored those with the new docker image and its working. I can't help but suspect i've only manually hacked the system to use the TCP protocol instead of UDP and I'm still running on the older security settings. Any guidance you could provide would be great. Thanks,