[Support] binhex - DelugeVPN


Recommended Posts

Hey guys:)

I actually have question about this itConfig plugin

@binhex Can you add this plugin to your container by default please? 

And another thing. I was getting terrible speeds with PIA, but after looking on internet i found solution for Deluge to install this itConfig plugin and:

- check Apply settings on startup
- check enable_incoming_utp and remove the checkmark from the Setting column
- check enable_outgoing_utp and remove the checkmark from the Setting column

Now i am getting nice speeds, but question is how secure is this?)

Thank you

Link to comment
12 minutes ago, J05u said:

Can you add this plugin to your container by default please? 

i dont really want to do that as it means whenever the plugin gets updated i would get requests to rebuild the image, not keen on that idea, best to leave plugins to users to install.

 

13 minutes ago, J05u said:

Now i am getting nice speeds, but question is how secure is this?)

not sure what you mean by this, how secure is what?, the plugin?, the use of the plugin or this image as a whole?.

Link to comment
6 minutes ago, binhex said:

i dont really want to do that as it means whenever the plugin gets updated i would get requests to rebuild the image, not keen on that idea, best to leave plugins to users to install.

I guess this plugin won't be updated very often, but its very important to have it for normal download speeds. Or it was my mistake, but after restarting Deluge i need to re-apply this plugin and settings. I spend few days to figure out how to speed up this VPN and been swearing on PIA support. 

8 minutes ago, binhex said:

not sure what you mean by this, how secure is what?, the plugin?, the use of the plugin or this image as a whole?.

no, i mean whole vpn. I am noob in networks and their protection. I am not sure that this settings change will change VPN security (like ip leak, dns leak and etc) 

Link to comment
1 minute ago, J05u said:

but after restarting Deluge i need to re-apply this plugin and settings.

this is a bug in deluge which sadly persists to deluge v2.0, in short plugins do not stay enabled, see Q4 here for how to work around it:-

https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md

 

3 minutes ago, J05u said:

no, i mean whole vpn. I am noob in networks and their protection. I am not sure that this settings change will change VPN security (like ip leak, dns leak and etc) 

applying those changes using itconfig will not compromise anything, you are still protected from ip leakage via the use of iptables.

 

  • Thanks 1
Link to comment

I updated the container for the first time in months (since updating from OS 6.6.x to 6.7) and suddenly I cannot connect to the web GUI. Is there something obvious that I'm missing? Potentially a permission issue for the openvpn folder for credentials.conf? Not sure where to go from here..

 

This is what I'm seeing in my log repeatedly:


2019-09-28 15:18:18,909 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:18 2019 SIGTERM[soft,auth-failure] received, process exiting

2019-09-28 15:18:47,756 DEBG 'start-script' stdout output:
[warn] OpenVPN process terminated, restarting OpenVPN...

2019-09-28 15:18:47,763 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:47 2019 WARNING: file 'credentials.conf' is group or others accessible
Sat Sep 28 15:18:47 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Sat Sep 28 15:18:47 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10

2019-09-28 15:18:47,764 DEBG 'start-script' stdout output:
[info] OpenVPN restarted

2019-09-28 15:18:47,764 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:47 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2019-09-28 15:18:47,764 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:47 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Sep 28 15:18:47 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

2019-09-28 15:18:47,764 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:47 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]198.52.38.195:443
Sat Sep 28 15:18:47 2019 UDP link local: (not bound)
Sat Sep 28 15:18:47 2019 UDP link remote: [AF_INET]198.52.38.195:443

2019-09-28 15:18:47,848 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:47 2019 VERIFY OK: depth=1, C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Operations, CN=Windscribe Node CA

2019-09-28 15:18:47,848 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:47 2019 VERIFY KU OK
Sat Sep 28 15:18:47 2019 Validating certificate extended key usage
Sat Sep 28 15:18:47 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Sep 28 15:18:47 2019 VERIFY EKU OK
Sat Sep 28 15:18:47 2019 VERIFY OK: depth=0, C=CA, ST=ON, O=Windscribe Limited, OU=Operations, CN=Windscribe Node Server 4096

2019-09-28 15:18:47,882 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:47 2019 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1550'
Sat Sep 28 15:18:47 2019 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM'
Sat Sep 28 15:18:47 2019 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]'
Sat Sep 28 15:18:47 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Sat Sep 28 15:18:47 2019 [Windscribe Node Server 4096] Peer Connection Initiated with [AF_INET]198.52.38.195:443

2019-09-28 15:18:49,057 DEBG 'start-script' stdout output:
Sat Sep 28 15:18:49 2019 AUTH: Received control message: AUTH_FAILED
Sat Sep 28 15:18:49 2019 SIGTERM[soft,auth-failure] received, process exiting

Edited by BBLV
Link to comment

Hi folks,

I'm currently having issues with the privoxy included in this container. When I use the the privoxy in other containers, they won't connect. I used firefox in order to test it, I get a message to the effect of "connection was reset" when I try to connect to any website. Deluge itself works fine, and it is connected to the vpn. I can verify that I can actually connect to the proxy itself, it just seems to bin off any site I send through it.

 

You can view the log from the container here:
https://paste.dimdev.org/uboluyutab.coffeescript

I couldn't find anything particularly relevant in the log.

Any help would be much appreciated, thanks in advanced.

 

Edit:

 

To add a bit more info, the docker is running inside a custom docker network (configured as per our lord and saviors SpaceInvaderOne letsencrypt docker video), and I'm trying to access the proxy through the Unraid server's IP (10.0.0.200:8118).

Edited by mrfrogydog
Adding more info
Link to comment
18 hours ago, BBLV said:

I updated the container for the first time in months (since updating from OS 6.6.x to 6.7) and suddenly I cannot connect to the web GUI. Is there something obvious that I'm missing? Potentially a permission issue for the openvpn folder for credentials.conf? Not sure where to go from here..

 

For whatever reason, I had to create a new OpenVPN config file through my Static IP provider and loading that into the container fixed it. What I find extremely odd is that literally no other changes were made beyond updating the container to Deluge v2.

Link to comment
57 minutes ago, BBLV said:

For whatever reason, I had to create a new OpenVPN config file through my Static IP provider and loading that into the container fixed it. What I find extremely odd is that literally no other changes were made beyond updating the container to Deluge v2.

Rebooted my server and now I'm getting the same errors and web ui won't load... I'm at a loss.

Link to comment
16 hours ago, BBLV said:

For whatever reason, I had to create a new OpenVPN config file through my Static IP provider and loading that into the container fixed it. What I find extremely odd is that literally no other changes were made beyond updating the container to Deluge v2.

possible the old certificate from your vpn provider was using a weak cipher which is no longer permitted with the later version of openvpn, thus when you updated you couldnt connect, that would be my guess.

Link to comment
On 9/28/2019 at 10:38 PM, mrfrogydog said:

Hi folks,

I'm currently having issues with the privoxy included in this container. When I use the the privoxy in other containers, they won't connect. I used firefox in order to test it, I get a message to the effect of "connection was reset" when I try to connect to any website. Deluge itself works fine, and it is connected to the vpn. I can verify that I can actually connect to the proxy itself, it just seems to bin off any site I send through it.

 

You can view the log from the container here:
https://paste.dimdev.org/uboluyutab.coffeescript

I couldn't find anything particularly relevant in the log.

Any help would be much appreciated, thanks in advanced.

 

Edit:

 

To add a bit more info, the docker is running inside a custom docker network (configured as per our lord and saviors SpaceInvaderOne letsencrypt docker video), and I'm trying to access the proxy through the Unraid server's IP (10.0.0.200:8118).

so when you say 'custom docker network' you mean custom docker bridge right?, not macvlan?, cos macvlan is not supported and wont work.

Link to comment

How's delugevpn running these days? I had switched to binhex qbitorrentvpn after having issues with the webui crashing on me too often when not being able to handle too many torrents in the queue, and not picking all my magnets. I last used it about a year ago.

I don't really have a reason to switch, I'm mainly curious what the webui looks like now

Sent from my SM-G955U using Tapatalk

Link to comment
6 hours ago, binhex said:

possible the old certificate from your vpn provider was using a weak cipher which is no longer permitted with the later version of openvpn, thus when you updated you couldnt connect, that would be my guess.

 

- Looks like you might have solved an issue I brought up a few pages ago. Seems 2.4.7 openVPN is not playing nice with my vpn provider.

 

Issue: when VPN set to

write UDP: Operation not permitted (code=1)

 


Not working Binhex DelugeVPN:
Sun Sep 29 10:30:24 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019

 

Working Flexget delugeVPN:
Sat Sep 21 15:27:14 2019 OpenVPN 2.4.0 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 28 2016

 

Also working OpenVPN client app:

openvpnclient

2019.02.09

Update of OpenVPN packages to 2.4.6-2

 

 

 

Link to comment
On 9/30/2019 at 1:56 AM, binhex said:

possible the old certificate from your vpn provider was using a weak cipher which is no longer permitted with the later version of openvpn, thus when you updated you couldnt connect, that would be my guess.

Do you know what the minimum cipher requirements are with the newer version of OpenVPN you've integrated? Would like to know exactly what I'm asking Windscribe to confirm... Thanks again!

Link to comment

Probably a useful message shown below:

 

~# curl -vvv --proxy 10.0.0.200:8118 https://www.google.co.uk
*   Trying 10.0.0.200:8118...
* TCP_NODELAY set
* Connected to 10.0.0.200 (10.0.0.200) port 8118 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.co.uk:443
> CONNECT www.google.co.uk:443 HTTP/1.1
> Host: www.google.co.uk:443
> User-Agent: curl/7.65.3
> Proxy-Connection: Keep-Alive
>
* Recv failure: Connection reset by peer
* Received HTTP code 0 from proxy after CONNECT
* CONNECT phase completed!
curl: (56) Recv failure: Connection reset by peer

 

So I try to get the page at google.co.uk (via HTTPS) using curl, through the proxy (at 10.0.0.200:8118) which is the one running on my delugevpn container. It feels like there's a simple config problem with the privoxy, or it's not running properly for some reason. The rest of the container itself is accesible, as is the proxy, however the proxy isn't properly dealing with requests.
 

Worth mentioning also, I have remade the container, tried several versions, completely deleted the config (from appdata), but still have the same problem unfortunately.

Appreciate any further help if you have the chance.

Many thanks.

Link to comment
2 hours ago, mrfrogydog said:

Probably a useful message shown below:

 

~# curl -vvv --proxy 10.0.0.200:8118 https://www.google.co.uk
*   Trying 10.0.0.200:8118...
* TCP_NODELAY set
* Connected to 10.0.0.200 (10.0.0.200) port 8118 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.co.uk:443
> CONNECT www.google.co.uk:443 HTTP/1.1
> Host: www.google.co.uk:443
> User-Agent: curl/7.65.3
> Proxy-Connection: Keep-Alive
>
* Recv failure: Connection reset by peer
* Received HTTP code 0 from proxy after CONNECT
* CONNECT phase completed!
curl: (56) Recv failure: Connection reset by peer

 

So I try to get the page at google.co.uk (via HTTPS) using curl, through the proxy (at 10.0.0.200:8118) which is the one running on my delugevpn container. It feels like there's a simple config problem with the privoxy, or it's not running properly for some reason. The rest of the container itself is accesible, as is the proxy, however the proxy isn't properly dealing with requests.
 

Worth mentioning also, I have remade the container, tried several versions, completely deleted the config (from appdata), but still have the same problem unfortunately.

Appreciate any further help if you have the chance.

Many thanks.

 

I'm having the same issue. Privoxy only accepts local connections, but not from LAN. It was working perfectly before, something changed in the image. Not sure what...

 

Link to comment
22 hours ago, cmer said:

 

I'm having the same issue. Privoxy only accepts local connections, but not from LAN. It was working perfectly before, something changed in the image. Not sure what...

 

Huh that is interesting, it's actually something I hadn't noticed. So if I try to connect to the proxy from another docker on the same subnet image (in this case the binhex-jackett one) then I actually get a successful connection to the proxy. Shown below:

 

curl -vvv --proxy 10.0.0.200:8118 https://www.google.co.uk

*   Trying 10.0.0.200:8118...
* TCP_NODELAY set
* Connected to 10.0.0.200 (10.0.0.200) port 8118 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.co.uk:443
> CONNECT www.google.co.uk:443 HTTP/1.1
> Host: www.google.co.uk:443
> User-Agent: curl/7.66.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
^C

 

I don't actually get a response though, which is unusual. I would expect it to give me the html or whatever, but in this case I have to manually close the program with ctrl-c.

 

I'm quite puzzled; I wonder if there is a problem with the iptables config. Not sure yet.

Edited by mrfrogydog
Link to comment

Hey guys,

I am looking for some help with super slow performance on downloads. I know normally there is port forwarding required on routers to get good speeds but I am not sure how this works going through a VPN.

From what I have read delugevpn should be taking care of that on its own but it sounds like its vpn provider specific. Does this work with torguard? or are there ports I need to manually open and container settings to modify to get speeds back to normal?

Link to comment
9 hours ago, ozzyc said:

Hey guys,

I am looking for some help with super slow performance on downloads. I know normally there is port forwarding required on routers to get good speeds but I am not sure how this works going through a VPN.

From what I have read delugevpn should be taking care of that on its own but it sounds like its vpn provider specific. Does this work with torguard? or are there ports I need to manually open and container settings to modify to get speeds back to normal?

https://torguard.net/faq.php#panel2

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.