[Support] binhex - DelugeVPN

[binhex]

I just logged back into my server and updated my PIA credentials as they have recently expired. I haven't touched deluge in over a month until now and now after the new credentials have been put in it's not allowing me to get into the docker.

 

I'll be honest that I've tried to read the last few pages of this thread to see if my question was answered there but a lot of it is going over my head as I still don't have all of this down very well.

 

If you need anymore info let me know.

 

I just posted the same issue (I believe) right above you. Something about the latest version of the docker doesn't allow it to connect to PIA so it shuts down the access to protect your identity.

Is not related at all, you issue is to do with changing your VPN port to 1198 as this is the new port used since the pia cert changes.

 

Edit - ok if the logs are identical then please do the same as above

 

[Bjonness406]

So I'll essentially have two lines for /data in the docker config?

 

/data -> /mnt/user/Downloads

/data -> /mnt/user/Incomplete-Downloads

 

?

 

Also, unrelated but just happened:

 

I just updated my docker, which was working perfectly, but now it's unable to load for me... log gives me these errors:

 

2016-07-15 15:39:57,119 DEBG 'start-script' stdout output:

Fri Jul 15 15:39:55 2016 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]

Fri Jul 15 15:39:55 2016 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Fri Jul 15 15:39:55 2016 TLS_ERROR: BIO read tls_read_plaintext error

Fri Jul 15 15:39:55 2016 TLS Error: TLS object -> incoming plaintext read error

Fri Jul 15 15:39:55 2016 TLS Error: TLS handshake failed

Fri Jul 15 15:39:55 2016 SIGUSR1[soft,tls-error] received, process restarting

Nearly.

Map

/downloads -> /mnt/user/Downloads

/incomplete -> /mnt/user/Incomplete-Downloads

 

Then go inside deluge, and set incomplete downloads to /incomplete and complete downloads to /downloads

[Adam64]

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.

 

ok so if you have STRONG_CERTS set to yes then use port 501, if the env var doesnt exist or isnt set to yes then set the port to 502, that should sort it.

 

I'm confused about the right port.  I thought it was supposed to be 1198 (or 1197)?  Where did 501 and 502 come from?

[binhex]

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.

 

ok so if you have STRONG_CERTS set to yes then use port 501, if the env var doesnt exist or isnt set to yes then set the port to 502, that should sort it.

 

I'm confused about the right port.  I thought it was supposed to be 1198 (or 1197)?  Where did 501 and 502 come from?

From memory it goes like this:-

 

1198 = standard udo

1197 = strong UDP

502 = standard TCP

501 = strong tcp

 

 

Sent from my SM-G900F using Tapatalk

 

 

[Adam64]

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.

 

ok so if you have STRONG_CERTS set to yes then use port 501, if the env var doesnt exist or isnt set to yes then set the port to 502, that should sort it.

 

I'm confused about the right port.  I thought it was supposed to be 1198 (or 1197)?  Where did 501 and 502 come from?

From memory it goes like this:-

 

1198 = standard udo

1197 = strong UDP

502 = standard TCP

501 = strong tcp

 

 

Sent from my SM-G900F using Tapatalk

 

Thanks!

[DaClownie]

OK, i'm reading all this and I'm confused as to what I need to do.

 

I need to navigate the PIA website, find the new cert files, modify a section to make it capitalized, change the docker's port from 1194 (old port setup) to 1197 or 1198, and it will work?

 

Just getting my ducks in a row so I can solve my issues tomorrow morning.

[Bjonness406]

OK, i'm reading all this and I'm confused as to what I need to do.

 

I need to navigate the PIA website, find the new cert files, modify a section to make it capitalized, change the docker's port from 1194 (old port setup) to 1197 or 1198, and it will work?

 

Just getting my ducks in a row so I can solve my issues tomorrow morning.

See here

 

http://lime-technology.com/forum/index.php?topic=45812.msg483281#msg483281

[MyKroFt]

VPN_REMOTE=nl.vpn.airdns.org

 

 

 

I have no clue on this part - there is nothing listed on AirVPNs site about exit point

 

 

Myk

[Adam64]

I'm getting a malformed expression error in the log:

 

File "/usr/lib/python2.7/site-packages/deluge/ui/console/commands/config.py", line 77, in atom

raise SyntaxError("malformed expression (%s)" % token[1])

SyntaxError: malformed expression (,)

 

My settings are:

 

VPN_PROV:  pia

VPN_PROTOCOL: udp

VPN_PORT:  1198 (or 1197 with STRONG_CERTS: yes).

 

Interestingly sabnzbdvpn works fine with the same exact settings.

[Guest dranani]

I just logged back into my server and updated my PIA credentials as they have recently expired. I haven't touched deluge in over a month until now and now after the new credentials have been put in it's not allowing me to get into the docker.

 

I'll be honest that I've tried to read the last few pages of this thread to see if my question was answered there but a lot of it is going over my head as I still don't have all of this down very well.

 

If you need anymore info let me know.

 

I just posted the same issue (I believe) right above you. Something about the latest version of the docker doesn't allow it to connect to PIA so it shuts down the access to protect your identity.

Is not related at all, you issue is to do with changing your VPN port to 1198 as this is the new port used since the pia cert changes.

 

Edit - ok if the logs are identical then please do the same as above

I'm getting the same errors as him I believeI found the fix from someone in this thread. Thanks!

[mr-hexen]

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

 

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.

[mr-hexen]

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.

[binhex]

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

 

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

 

 

[binhex]

VPN_REMOTE=nl.vpn.airdns.org

 

 

 

I have no clue on this part - there is nothing listed on AirVPNs site about exit point

 

 

Myk

If airvpn doesn't list all the endpoints then they will be defined in the ovpn file,  the example above is the netherlands

[mr-hexen]

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

 

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

[DaClownie]

OK, i'm reading all this and I'm confused as to what I need to do.

 

I need to navigate the PIA website, find the new cert files, modify a section to make it capitalized, change the docker's port from 1194 (old port setup) to 1197 or 1198, and it will work?

 

Just getting my ducks in a row so I can solve my issues tomorrow morning.

See here

 

http://lime-technology.com/forum/index.php?topic=45812.msg483281#msg483281

 

The steps outlined in that post fixed my problems.

 

Thanks kindly and enjoy your day!

 

To Binhex: Great docker and really appreciate the effort that goes into making them happen!

[mr-hexen]

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.

[binhex]

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

 

 

Several people are reporting issues with the new ovpn-files (both the regular and strong config). Myself and others have had success with editing the ovpn-files and changing he cipher and auth settings to uppercase, before importing the file:

 

cipher AES-256-CBC

auth SHA256

 

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

 

ok so a bit more investigation into the warnings some people are seeing in their supervisord.log files when using strong encryption, it looks like this is perfectly normal and can be ignore, see here for more details:-

 

https://www.privateinternetaccess.com/forum/discussion/21830/more-encryption-issues

 

I am going to quieten down these warning for PIA, if anybody has a problem with this then please let me know, im reasonably happy with the explanation given above.

[ThatDude]

UPDATE: Had to add "ENABLE_PRIVOXY = yes" variable too.

 

I'm using PIA, I went to the site and generated new creds then setup the docker settings as below, it's all working fine now - thanks for your hard work Binhex

 

I was wondering if there is an advantage to using TCP over UDP or if I should be using the strong encryption option, can anyone offer any advice on this?

 

 

 

[mr-hexen]

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%.

[unevent]

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

 

 

Several people are reporting issues with the new ovpn-files (both the regular and strong config). Myself and others have had success with editing the ovpn-files and changing he cipher and auth settings to uppercase, before importing the file:

 

cipher AES-256-CBC

auth SHA256

 

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

 

ok so a bit more investigation into the warnings some people are seeing in their supervisord.log files when using strong encryption, it looks like this is perfectly normal and can be ignore, see here for more details:-

 

https://www.privateinternetaccess.com/forum/discussion/21830/more-encryption-issues

 

I am going to quieten down these warning for PIA, if anybody has a problem with this then please let me know, im reasonably happy with the explanation given above.

 

Increase to at least verb 3 and look for the Data Channel Encrypt and Data Channel Decrypt messages in the log, those will tell you what ciphers are being used regardless of warnings about mismatch.  Refer to http://lime-technology.com/forum/index.php?topic=45822.msg484068#msg484068.

[binhex]

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

 

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

 

ok change is in to quieten things down with regards to default mismatch with local and remote endpoints, the above issue is also fixed now, so you should be able to prevent overwrite on start by settings the ovpn filename to "custom.ovpn" in the folder /config/openvpn/

 

[mr-hexen]

ok change is in to quieten things down with regards to default mismatch with local and remote endpoints, the above issue is also fixed now, so you should be able to prevent overwrite on start by settings the ovpn filename to "custom.ovpn" in the folder /config/openvpn/

 

Ok I'll try it in a little while.

[macdo03]

I'm having a few issues with Privoxy included with DelugeVPN. Deluge is maxing out my internet connection over the VPN connection but when I try to access any web pages using Privoxy or set Couch/Sonarr to access privoxy, it is painfully slow and some requests fail. Are there any specific configurations that I need to set?

 

Thanks

[binhex]

I'm having a few issues with Privoxy included with DelugeVPN. Deluge is maxing out my internet connection over the VPN connection but when I try to access any web pages using Privoxy or set Couch/Sonarr to access privoxy, it is painfully slow and some requests fail. Are there any specific configurations that I need to set?

 

Thanks

If deluge is maxing out your line then privoxy will be slow as it will be competing against deluge traffic, simply throttle back deluge and privoxy should perform just fine.

 

Sent from my SM-G900F using Tapatalk