[Support] binhex - qBittorrentVPN


Recommended Posts

49 minutes ago, binhex said:

im not too sure whats going on either, as for me its completely working, try connecting to endpoint 'sweden', as that is what im connected to, see if port forwarding is operational there.

 

Tried 5 different endpoints, still no dice. I put in a ticket to PIA see if they have any idea why the ports aren't being opened, how frustrating.

Link to comment

Somehow I had trouble downloading files when using Socks5 on NordVPN. Tried everything really, could not get it to work. Disabling Socks5 and it started downloading just fine. Tried different connections and servers, nothing worked.

 

After editing the credentials.conf file and removing a 'return' on the 3rd line it instantly started downloading with Socks5 again.

Thought to post it here for it might help others to get things working.

EDIT: I might have been too quick to judge. New downloads don't start either, so I'm back to square one. I might start trying a different download client at this point.

Edited by SysRq
Link to comment

So... totally new to this docker... installed it from CA, put my PIA credentials in there... but the docker won't start. Nothing in /var/log/docker.log, and I have this in /var/log/syslog:

Feb 29 11:08:14 server kernel: docker0: port 1(veth979aba4) entered blocking state
Feb 29 11:08:14 server kernel: docker0: port 1(veth979aba4) entered disabled state
Feb 29 11:08:14 server kernel: device veth979aba4 entered promiscuous mode
Feb 29 11:08:14 server kernel: IPv6: ADDRCONF(NETDEV_UP): veth979aba4: link is not ready
Feb 29 11:08:14 server kernel: docker0: port 1(veth979aba4) entered blocking state
Feb 29 11:08:14 server kernel: docker0: port 1(veth979aba4) entered forwarding state
Feb 29 11:08:14 server kernel: docker0: port 1(veth979aba4) entered disabled state
Feb 29 11:08:14 server kernel: eth0: renamed from vethda9dccf
Feb 29 11:08:14 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth979aba4: link becomes ready
Feb 29 11:08:14 server kernel: docker0: port 1(veth979aba4) entered blocking state
Feb 29 11:08:14 server kernel: docker0: port 1(veth979aba4) entered forwarding state
Feb 29 11:08:15 server kernel: vethda9dccf: renamed from eth0
Feb 29 11:08:15 server kernel: docker0: port 1(veth979aba4) entered disabled state
Feb 29 11:08:15 server kernel: docker0: port 1(veth979aba4) entered disabled state
Feb 29 11:08:15 server kernel: device veth979aba4 left promiscuous mode
Feb 29 11:08:15 server kernel: docker0: port 1(veth979aba4) entered disabled state

I tried bridge, host and custom modes as network types. Also tried the debug flag. Haven't done anything else yet (didn't see any special instruction in the first post of this thread so I assumed it would work without any extra setup). Never had any problem with anything else from binhex or dockers in Unraid in general.

Link to comment

Got it working WITHOUT vpn enabled. Now, if I enable VPN, I get this:

 

2020-02-29 22:26:14,822 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 7 from curl != 0
[info] 10 retries left
[info] Retrying in 10 secs...

I'm using PIA, not sure what's wrong, the error is very generic? Do I need to port forward something?

root@server:~# ls -l /mnt/user/appdata/qbittorrentvpn/openvpn/
total 16
-rwxrwxr-x 1 nobody users 2025 Oct 22 17:06 ca.rsa.2048.crt*
-rwxrwxr-x 1 nobody users   20 Feb 29 22:25 credentials.conf*
-rwxrwxr-x 1 nobody users  869 Oct 22 17:06 crl.rsa.2048.pem*
-rwxrwxr-x 1 nobody users 3170 Feb 29 22:25 us2-aes-128-cbc-udp-dns.ovpn*

 

Link to comment

Noticed the server I'm using doesn't support port fowarding? Can't use anything in the US???

2020-02-29 22:30:59,893 DEBG 'start-script' stdout output:
[info] ca-toronto.privateinternetaccess.com
[info] ca-montreal.privateinternetaccess.com
[info] ca-vancouver.privateinternetaccess.com
[info] de-berlin.privateinternetaccess.com
[info] de-frankfurt.privateinternetaccess.com
[info] sweden.privateinternetaccess.com
[info] swiss.privateinternetaccess.com
[info] france.privateinternetaccess.com
[info] czech.privateinternetaccess.com
[info] spain.privateinternetaccess.com
[info] ro.privateinternetaccess.com
[info] israel.privateinternetaccess.com
[info] Attempting to get dynamically assigned port...

Got it working with the Toronto VPN but eh...

Edited by dnLL
Link to comment

Can't put it on port 80 whatever I do. Seems like the available settings don't actually do anything, it keeps mapping port 8080 even if I put port 80 for webui and host port 2 and 80 in the app settings too. We should have the option...

Link to comment
On 2/29/2020 at 3:14 AM, binhex said:

im not too sure whats going on either, as for me its completely working, try connecting to endpoint 'sweden', as that is what im connected to, see if port forwarding is operational there.

 

So I finally found the issue after spending too many hours investigating and pulling my hair out. For reference, the reason the port was being shown as closed is because PIA will only show open when data is flowing through it, so because my port was never being changed in qBittorrent this never applied.

 

 

Anyway.... the issue turns out to be how you interact with qBittorrents API in qbittorrent.sh, the curl commands you use don't support https nor self signed certs.

 

curl -i -X POST -d "json={\"listen_port\": ${VPN_INCOMING_PORT}}" "http://localhost:${WEBUI_PORT}/api/v2/app/setPreferences" &> /dev/null

 

The above command will first fail if the user has HTTPS enabled as you specifically query http://localhost:(etc), this needs to be changed to dynamically tell if HTTPS is enabled.

 

Secondly the request will fail if the user has a self signed cert;

 

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

 

To fix this you will also need to add the -k flag ( -k, --insecure      Allow insecure server connections when using SSL) to allow curl to accept self signed certs.

 

 

With that being said, I tested the changes locally and everything works smoothly. Hope this helps. 

 

 

Edit; Made a pull request for convenience

Edited by Adamm
Pull request url
Link to comment
20 hours ago, Adamm said:

 

So I finally found the issue after spending too many hours investigating and pulling my hair out. For reference, the reason the port was being shown as closed is because PIA will only show open when data is flowing through it, so because my port was never being changed in qBittorrent this never applied.

 

 

Anyway.... the issue turns out to be how you interact with qBittorrents API in qbittorrent.sh, the curl commands you use don't support https nor self signed certs.

 


curl -i -X POST -d "json={\"listen_port\": ${VPN_INCOMING_PORT}}" "http://localhost:${WEBUI_PORT}/api/v2/app/setPreferences" &> /dev/null

 

The above command will first fail if the user has HTTPS enabled as you specifically query http://localhost:(etc), this needs to be changed to dynamically tell if HTTPS is enabled.

 

Secondly the request will fail if the user has a self signed cert;

 


curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

 

To fix this you will also need to add the -k flag ( -k, --insecure      Allow insecure server connections when using SSL) to allow curl to accept self signed certs.

 

 

With that being said, I tested the changes locally and everything works smoothly. Hope this helps. 

 

 

Edit; Made a pull request for convenience

thanks for the continued digging on this, i see the PR and have optimised it and committed the change in so i will close the PR, look out for a new build soon.

Link to comment
On 3/8/2020 at 10:40 PM, roobix said:

When I try to use the search tab in the WebGUI, the search results are all over the place and rarely relevant to the keywords I'm using. Does anyone know why?

 

I tried searching this topic for "search" and came up with nothing that helped me.

best asking on the qbittorrent forum/reddit/github, there wil be people with more experience on there.

Link to comment

I've been getting issues with trackers not connecting at all (status is Not Working in the WebUI). As soon as I restart the docker container it connects fine. I don't even know where to begin troubleshooting tbh. VPN seems to be working since I'm able to see the WebUI and a restart of the docker works fine. Haven't really seen much when searching for tracker not working in this thread.

Link to comment
On 3/14/2020 at 1:36 PM, constellation said:

I've been getting issues with trackers not connecting at all (status is Not Working in the WebUI). As soon as I restart the docker container it connects fine. I don't even know where to begin troubleshooting tbh. VPN seems to be working since I'm able to see the WebUI and a restart of the docker works fine. Haven't really seen much when searching for tracker not working in this thread.

Same here. I'm using my own server with OpenVPN. I've noticed that qBittorrent just stops trying to connect and reports timeouts. If I pull up the console for the container, the VPN is connected and everything else connects just fine.  The VPN definitely reconnects like it is supposed to, qBittorrent seems to be giving up and never retrying until a container restart.

 

I did not have this issue with ruTorrent, but had other issues where it somehow reported that I downloaded 20 TB on two torrents.

Edited by psycho_asylum
Link to comment
3 hours ago, psycho_asylum said:

Same here. I'm using my own server with OpenVPN. I've noticed that qBittorrent just stops trying to connect and reports timeouts. If I pull up the console for the container, the VPN is connected and everything else connects just fine.  The VPN definitely reconnects like it is supposed to, qBittorrent seems to be giving up and never retrying until a container restart.

 

I did not have this issue with ruTorrent, but had other issues where it somehow reported that I downloaded 20 TB on two torrents.

Same here with NordVPN.

A container restart temporarily sovles the problem - until next time.

Link to comment

Any update on fixing the credentials issue? how can I disable container from updating the vpn's auth user setting?

.conf files seem to be parsed differently from .txt files and .conf does not work for me so I need to edit it everytime i restart the container..

Link to comment

I'm having trouble getting this to work within a traefik reverse-proxy network.

 

My YML can be found here: https://ghostbin.co/paste/nhdx5

 

Currently it works fine, but if I simply uncomment the "networks" section, I receive the following error: https://ghostbin.co/paste/myhcz

 

Can anyone point me in the right direction for fixing this?

Edited by flumpywoss
Added information
Link to comment

I'm having a bit of a weird issue tonight with this docker on one of my two servers. It appears all of my torrents have slowed to a crawl (less than 10kb/s total).

The two servers are running the same docker image, and VPN configuration but only one of the servers is having this slowness issue with torrents. I tested it with the same torrent on both servers, one of which had normal speeds and the other barely moved. I tried restarting the docker, upgrading/downgrading the version, removing the image, checked the hard drive health itself which appeared to be fine (but could probably stand to be investigated more in depth). Any ideas? I'm at a loss. 

 

edit- Looks like I bungled my way into fixing it by nuking the config data in addition with removing the docker, and then reinstalling everything from scratch.

Edited by Dysun
Link to comment

Having an issue with the docker running external programs after a torrent finishes downloading. 

 

I've had a suspicion for a while that it's not actually running anything at all. So today I decided to test it. I set the command it's supposed to run to be just about the simplest thing it could be

touch test.test

Then I triggered a torrent to download. Once it finished, I first checked the qbittorrent.log:

(N) 2020-03-24T13:33:25 - Torrent: <torrent name>, running external program, command: touch test.test

So qbittorrent at least believes it's running the command. However, when I check - anywhere - on the container for the file that should have been created, it doesn't exist. So it's not actually running the external program.

 

I'm sure it's something I'm doing wrong, but I'm not really sure what it is. Anyone have a thought?

Edited by LeJoker
Link to comment
6 minutes ago, LeJoker said:

when I check - anywhere - on the container for the file that should have been created

Where exactly are you looking? I would expect that relative file path "test.test" to be inside the docker image and not anywhere you could access it from outside the container.

Link to comment
38 minutes ago, trurl said:

Where exactly are you looking? I would expect that relative file path "test.test" to be inside the docker image and not anywhere you could access it from outside the container.

I'm not trying to access from outside the container. I'm in the console for the container itself, running a find command for that file. Checking / inside the container finds no results for that file at all.

 

I'd have expected the relative path to either be the download folder, or maybe / or something, but it just doesn't appear to be there. That tells me, I would think, that the command isn't executing at all.

Edited by LeJoker
Link to comment
15 hours ago, LeJoker said:

I'm not trying to access from outside the container. I'm in the console for the container itself, running a find command for that file. Checking / inside the container finds no results for that file at all.

 

I'd have expected the relative path to either be the download folder, or maybe / or something, but it just doesn't appear to be there. That tells me, I would think, that the command isn't executing at all.

are you literally telling qbittorrent to run 'touch test.test' if so you may well need the absolute path to touch, and i would personally advise creating a bash script instead and then calll the script, e.g. save the below as /config/test.sh, chmod +x /config/test.sh, then reference the script /config/test.sh in the post processing section in qbittorrent.

#!/bin/bash

/usr/bin/touch '/config/test.test'

then see if the file appears in /config on the host path, if it does you know it works, if not then there is a bug in qbittorrent.

Link to comment
On 3/25/2020 at 5:47 AM, binhex said:

are you literally telling qbittorrent to run 'touch test.test' if so you may well need the absolute path to touch, and i would personally advise creating a bash script instead and then calll the script, e.g. save the below as /config/test.sh, chmod +x /config/test.sh, then reference the script /config/test.sh in the post processing section in qbittorrent.

Thanks for the help, and the work you do :)

 

Yes, I'm literally running 'touch test.test', partially because I wanted to see what path the command was running from if I didn't provide it an absolute path. It used to, I believe, run from the folder of the completed torrent, because I used to use "unrar e *.rar" as the complete unrar command for when the torrent finishes and it would just work. It's stopped working recently, so this was part of my investigation as to why.

 

I will try writing a script and calling that instead, and seeing if it helps. Thanks! :)

Link to comment

I'm currently using this docker with Mullvad VPN. Everything seems to be working fine, but how can I check that all of the traffic is truly going through the VPN for this Docker? I have VPN_ENABLED set to yes, and I have my Mullvad ID in VPN_USER and VPN_PASS, and then I have VPN_PROV set to custom. I've had a few terabytes incoming and outgoing, and haven't been throttled or warned yet, so I'm guessing that it's working, but I just want to be absolutely sure that all of that traffic is going through Mullvad.

 

Any tips are appreciated, thanks!!

Link to comment

  

1 hour ago, chrisp1992 said:

I'm currently using this docker with Mullvad VPN. Everything seems to be working fine, but how can I check that all of the traffic is truly going through the VPN for this Docker? I have VPN_ENABLED set to yes, and I have my Mullvad ID in VPN_USER and VPN_PASS, and then I have VPN_PROV set to custom. I've had a few terabytes incoming and outgoing, and haven't been throttled or warned yet, so I'm guessing that it's working, but I just want to be absolutely sure that all of that traffic is going through Mullvad.

 

Any tips are appreciated, thanks!!

 

If your vpn connection fails nothing else is started, once your vpn connection is up it starts rest of the applications, it's designed that way.

Edited by Jaska
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.