[Support] binhex - qBittorrentVPN


Recommended Posts

For reference

 

192.168.1.217 : main pc

192.168.1.6    : unraid server

 

 

Just got qbittorrent installed, everything appears to be working, but I'm getting a ton of errors in unraid log.

 

Jun 24 14:48:42 Tower nginx: 2019/06/24 14:48:42 [error] 4938#4938: *819467 connect() to unix:/var/tmp/binhex-qbittorrentvpn.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.1.217, server: , request: "GET /dockerterminal/binhex-qbittorrentvpn/ws HTTP/1.1", upstream: "http://unix:/var/tmp/binhex-qbittorrentvpn.sock:/ws", host: "192.168.1.6"

 

 

I did have to change the host for the webui from 8080 to 9090 as 8080 was already being used.  To do this I deleted the ports that were in the config (the one pointing to 8080), changed the webui container variable to 9090 and created a new TCP port for 9090:9090.

 

Is that the right way?
 

This is happening even when I'm not connected to qbittorrent via a web browser in any fashion.

 

I can post more info if needed.  Thanks.

Edited by swtz
Link to comment

For as popular as qBittorrent has been getting recently — it sure is difficult to get qBittorrent working out of the box with Sonarr, Radarr, & Binhex's SABnzbd-VPN. The port changing isn't as straight forward in this container as it is in the other Binhex containers.

 

I give up and I'm going back to the old setup that SpaceInvaderOne outlined in his video — which works with the Handbrake automation.

Link to comment
On 5/24/2019 at 9:04 AM, bally12345 said:

I was having issues again with this and deluge pia vpn (France) maxing out around 1Mb/s

I have just installed binhex-privoxy and going to try just using this minus vpn and enter proxy settings instead.


Sent from my SM-G973F using Tapatalk
 

try setting connection to tcp only and uncheck rate limiting

Edited by d3funct
Link to comment
try setting connection to tcp only and uncheck rate limiting
I did do this and worked initially then same thing. Eventually gave up and disabled using torrents all together and removed container.

Will have a look again later and see if I can get it working

Sent from my SM-G973F using Tapatalk

Link to comment

Hi, I am using the .ovpn from my provider (NordVPN) and am able to connect, but only if I put the username and password in the VPN_USER and VPN_PASS environments.  And credentials.conf in the ovpn directory apparently gets populated by them, the environments overwrite the user/pass on every boot.

Question: is there a more secure way to do this?  Would  rather not have my login details in cleartext on the Docker page...

Thanks for any tips!

Link to comment

I managed to set up qbittorrent on docker and it works flawlessly!

 

I had some issues though with downloading speeds with frequent drops. As all memory and caching options is hidden in webui I added these settings to qBittorrent.conf and it did a massive improvement. I now have full speed without drops.

 

(First make a backup of config!)

 

Add these to [Bittorrent] section:

Session\AsyncIOThreadsCount=4

Session\SendBufferLowWatermark=160
Session\SendBufferWatermark=15000
Session\SendBufferWatermarkFactor=150

 

Add to [Preferences] section:

Downloads\DiskWriteCacheSize=-1
Downloads\DiskWriteCacheTTL=300

  • Like 1
Link to comment

@binhex Thanks for this container, it seems to work great!

 

One bit of additional functionality I would like to see is the ability to use the "remote-random" option in the ovpn file, and specify a handfull of "remote" servers for the pool to pick from. I looked at your git page, and in the install script you mention that you list:

# get first matching 'remote' line in ovpn (Ignores any other remote hosts after the first entry)

# remove all remote lines as we cannot cope with multi remote lines (strip out all remote lines, wipes any remaining?)

# write the single remote line back to the ovpn file on line 1 (write contents of line 1 back into stripped ovpn file, all other remote now wiped out)


Out side of coming up with some juggling logic, is there any other reason you would have to not support multiple remote hosts outside of cleaning the entry prior to using it? I could work on submitting a PR to you to try and accommodate this, but wanted your take on it first?

 

EDIT: Or just add the ability to pick from a random .ovpn file that exists in /config/openvpn when defining VPN_CONFIG, if more than one .ovpn file exists. That would be a pretty clean way, and would give the container the ability to bounce around a few different servers on restart. Plus would keep most of your logic as is, since we would only be changing the VPN_CONFIG definition line.

 

Edited by cybrnook
Add another thought
Link to comment

I just added this docker today and was able to get it up and running. Was on the WebUI (via 192.168.1.69:8080) without issue, but wasn't able to connect, and still can't, from my subdomain (qbittorrent.WEBSITE.com). In my troubleshooting I went into the QBitTorrent Options -> WebUI and turned on the WebUI and set the IP address and port to match my Unraid QBitTorrent docker. After this I immediately lost connection to the WebUI and have not been able to get it back.

I imagine setting the WebUI in the QBitTorrent options to match the Docker caused a conflict, but now I'm not sure how to resolve this issue.

 

Edit: I solved this issue by going to \\tower\appdata\binhex-qbittorrentvpn\qBittorrent\config and editing the qBittorrent.conf file. At the bottom you'll see a section for WebUI -- at first I tried to just wipe the "WebUI\Address" to "*" but that didn't work. So I deleted the entire WebUI section. It reverted the password back to the default so I had to go change it again, but it got me back onto the WebUI.

l4jXuBV.png

Edited by SgtSeamonkey
Link to comment
I just added this docker today and was able to get it up and running. Was on the WebUI (via 192.168.1.69:8080) without issue, but wasn't able to connect, and still can't, from my subdomain (qbittorrent.WEBSITE.com). In my troubleshooting I went into the QBitTorrent Options -> WebUI and turned on the WebUI and set the IP address and port to match my Unraid QBitTorrent docker. After this I immediately lost connection to the WebUI and have not been able to get it back.
I imagine setting the WebUI in the QBitTorrent options to match the Docker caused a conflict, but now I'm not sure how to resolve this issue.
 
Edit: I solved this issue by going to \\tower\appdata\binhex-qbittorrentvpn\qBittorrent\config and editing the qBittorrent.conf file. At the bottom you'll see a section for WebUI -- at first I tried to just wipe the "WebUI\Address" to "*" but that didn't work. So I deleted the entire WebUI section. It reverted the password back to the default so I had to go change it again, but it got me back onto the WebUI.
l4jXuBV.png&key=156789bc649abe4c8b018ae21e63c5183910bfc950d80d4ffdb2b07e31a554b8
Check in the supervisord.log file that you have iptables mangle module enabled

Sent from my EML-L29 using Tapatalk

Link to comment
10 hours ago, binhex said:

Check in the supervisord.log file that you have iptables mangle module enabled

Sent from my EML-L29 using Tapatalk
 

Is that for the subdomain issue? I keep getting a 502 Bad Gateway error - none of my other subdomains are having an issue. Although I did have to change port 8118 to 8119 (which I may have done incorrectly) since 8118 is being used by deluge. I have both deluge and qbittorrent because the deluge version isn't whitelisted by a private tracker I use.

When I search "iptable" in supervisord.log I see many instances of this:

67sZ8fW.png

With the only differences between them being the timestamps and the "4" and "8" on lines 4 & 5. 

Link to comment
On 7/6/2019 at 12:24 PM, cybrnook said:

@binhex Thanks for this container, it seems to work great!

 

One bit of additional functionality I would like to see is the ability to use the "remote-random" option in the ovpn file, and specify a handfull of "remote" servers for the pool to pick from. I looked at your git page, and in the install script you mention that you list:

# get first matching 'remote' line in ovpn (Ignores any other remote hosts after the first entry)

# remove all remote lines as we cannot cope with multi remote lines (strip out all remote lines, wipes any remaining?)

# write the single remote line back to the ovpn file on line 1 (write contents of line 1 back into stripped ovpn file, all other remote now wiped out)


Out side of coming up with some juggling logic, is there any other reason you would have to not support multiple remote hosts outside of cleaning the entry prior to using it? I could work on submitting a PR to you to try and accommodate this, but wanted your take on it first?

 

EDIT: Or just add the ability to pick from a random .ovpn file that exists in /config/openvpn when defining VPN_CONFIG, if more than one .ovpn file exists. That would be a pretty clean way, and would give the container the ability to bounce around a few different servers on restart. Plus would keep most of your logic as is, since we would only be changing the VPN_CONFIG definition line.

 

Opened a PR: https://github.com/binhex/arch-qbittorrentvpn/pull/22

Link to comment
21 hours ago, cybrnook said:

An interesting PR :-), i see two issues with this that need to be either worked around or defined as how it currently works:-

 

1. random connection to another endpoint will only occur on full restart of the container, not ideal but still better than it currently is, i.e. no random endpoint connection at all.

2. not everybody will want this, some peopl want to connect to the same endpoint every time, some for security reasons, others for bandwidth related reasons, and possibly port forwarding comes into play too. so with this in mind i think i would need to add in an env var to control whether random endpoints are selected or not on startup, its def doable, but its more work. 

 

Note: I DO have random SERVER connection in place, so for a single endpoint, such as sweden.privateinternetaccess.com, this will resolve to multiple server ip addresses, these are then added to openvpn cli and the random option is added to try and prevent getting stuck on a single 'bad' server.

Link to comment
2 hours ago, binhex said:

An interesting PR :-), i see two issues with this that need to be either worked around or defined as how it currently works:-

 

1. random connection to another endpoint will only occur on full restart of the container, not ideal but still better than it currently is, i.e. no random endpoint connection at all.

2. not everybody will want this, some peopl want to connect to the same endpoint every time, some for security reasons, others for bandwidth related reasons, and possibly port forwarding comes into play too. so with this in mind i think i would need to add in an env var to control whether random endpoints are selected or not on startup, its def doable, but its more work. 

 

Note: I DO have random SERVER connection in place, so for a single endpoint, such as sweden.privateinternetaccess.com, this will resolve to multiple server ip addresses, these are then added to openvpn cli and the random option is added to try and prevent getting stuck on a single 'bad' server.

If you implement, I can work on submitting a PR to your readme page to write a little summary on how it works.

 

For your points:

 

1. Correct, random connection would only happen during a full container restart. Yes, it's a little heavier handed, however, with the seamless integration you have right now, there is not much front end integration to the end user anyways. So, I find that just restarting the container is the best/easiest way while keeping most everything the same.

 

2. I don't see this as much of an issue. Because even with users who only want to keep one .ovpn file inside the openvpn folder, it will just attempt to choose a random selection of 1. So, by default the same .ovpn file will always be used, and the enduser will always connect to the same server (unless more than one ovpn exists).

 

I personally use NordVPN, and they provide individual ovpn files per server. In all, the entirety of the file is the same, keys and certs are all the same, options the same, just the IP of the end point server is different per ovpn.

Edited by cybrnook
Link to comment
26 minutes ago, cybrnook said:

So, I find that just restarting the container is the best/easiest way while keeping most everything the same.

you would probably find most users wouldnt be too happy restarting the container, as it could mean lengthy re-checks of existing downloads, so not sure really how often this would happen.

22 minutes ago, cybrnook said:

Because even with users who only want to keep one .ovpn file inside the openvpn folder, it will just attempt to choose a random selection of 1.

this is assuming that users only have a single ovpn file in the folder, this is not always the case, and some people may not even be aware that they should only have a single ovpn file in the folder, you have to expect the unexpected, doubly so with users :-).

24 minutes ago, cybrnook said:

I personally use NordVPN

not a good choice for torrenting, no port forwarding available so your speeds will be affected, but im sure you know that right.

 

 

Link to comment

Hmm, then going back to the original idea of supporting "remote-random" would be the better case then. ovpn file would look something like this:

 

#2703 UDP
remote 96.9.245.120 1194
#3410 UDP
remote 172.93.153.187 1194
#4231 UDP
remote 198.23.164.115 1194
remote-random
client
dev tun
proto udp
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
ping 15
ping-restart 0
ping-timer-rem
comp-lzo no
remote-cert-tls server
auth-user-pass credentials.conf
verb 3
pull
fast-io
cipher AES-256-CBC
auth SHA512

Catch to this though, is we would need to be more crafty with your logic that's currently in there since your current script just grabs the first occurrence of "remote" and strips the rest out. So, the example above would go in fine, but the moment you started the container for the first time, you would only be left with the 120 address, with 187 and 115 now being MIA from the ovpn file. That's the first step then.

 

Second, would be that you are (very nice though) adding manual firewall rules during startup. So, if the tunnel was to go down and your watchdog restarts it, this would be the time that openvpn would automatically assign a new random server you have in the ovpn file. However, if the watchdog is only restarting openvpn, but ignoring the current firewall rules (I haven't looked that far yet), then the rules would be built around an old IP that would no longer match the new tun. So firewall rules would also need to repopulated during the tun restart. (Maybe you are already doing this, and if that's the case, then it's just as simple as allowing multiple entries in one single ovpn file to exist for "server").

 

Let me ask, do you ever have a taste for this? To me, it would be a great addition! However, it's your container and you maintain it. So any PR I issue will ultimately get checked by you anyways....

 

P.S. I haven't noticed any issues with Nord. I have my down cap set at ~15 MB/s and my up set at ~3.5 MB/s and I max out every time.

image.png.bcd82846ba071c3856a7cccc7c582625.png

Edited by cybrnook
Nord Perf
Link to comment
13 hours ago, cybrnook said:

Let me ask, do you ever have a taste for this? To me, it would be a great addition!

it would be nice to be able to rotate through multiple endpoints, but it probably will be a lot of work and its not top of my priorities right now, so this will have to be shelved for now, feel free to have a play yourself, but be warned im extremely picky with PR's so i may or may not accept any changes until i am 100% sure the change is good :-).

Link to comment

brand new install and the web ui login and pass (admin : adminadmin) does not work.  I missing something?  The only change I made from the template was to put it on a separate bridged network, assign to IP to container and to update the LAN_NETWORK variable to use my bridged subnet.  All browsers tried and no luck.

Edited by repomanz
Link to comment

Problem: default username and password ("admin" ; "adminadmin") not working on the qbittorrent webui

 

Solution: https://github.com/qbittorrent/qBittorrent/wiki/Web-UI-password-locked-on-qBittorrent-NO-X-(qbittorrent-nox)

 

notably: 

Quote

If you are still unable to login check if your antivirus is not blocking sending password via unencrypted connection (http). Bitdefender seems to do it by default, you need to whitelist qbittorrent server url

 

Bitdefender was blocking me. I tried using a firefox docker through my unraid server and it worked flawlessly.

 

Hope it helps others having the same problem.

Link to comment
On 7/13/2019 at 9:06 PM, tuna83 said:

Problem: default username and password ("admin" ; "adminadmin") not working on the qbittorrent webui

 

Solution: https://github.com/qbittorrent/qBittorrent/wiki/Web-UI-password-locked-on-qBittorrent-NO-X-(qbittorrent-nox)

 

notably: 

 

Bitdefender was blocking me. I tried using a firefox docker through my unraid server and it worked flawlessly.

 

Hope it helps others having the same problem.

 

This did the trick! Didn't notice the alert until now.  thanks

  • Upvote 1
Link to comment

I'm having trouble getting sonarr/radarr to talk to qBitTorrent. 

I've done a lot of sleuthing, and after following Radarr's error of 

19-7-14 16:27:01.9|Warn|HttpClient|HTTP Error - Res: [POST] http://192.168.0.101:8080/login: 503.ServiceUnavailable
19-7-14 16:27:01.9|Error|QBittorrent|Failed to connect to qBittorrent, please check your settings.

[v0.2.0.1358] NzbDrone.Core.Download.Clients.DownloadClientException: Failed to connect to qBittorrent, please check your settings. ---> NzbDrone.Common.Http.HttpException: HTTP request failed: [503:ServiceUnavailable] [POST] at [http://192.168.0.101:8080/login]
  at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00131] in C:\projects\radarr-usby1\src\NzbDrone.Common\Http\HttpClient.cs:93 
  at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxy.AuthenticateClient (NzbDrone.Common.Http.HttpRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentSettings settings, System.Boolean reauthenticate) [0x000a4] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxy.cs:276 
   --- End of inner exception stack trace ---
  at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxy.AuthenticateClient (NzbDrone.Common.Http.HttpRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentSettings settings, System.Boolean reauthenticate) [0x000e5] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxy.cs:286 
  at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxy.ProcessRequest (NzbDrone.Common.Http.HttpRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentSettings settings) [0x00000] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxy.cs:217 
  at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxy.ProcessRequest[TResult] (NzbDrone.Common.Http.HttpRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentSettings settings) [0x00000] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxy.cs:210 
  at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxy.GetVersion (NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentSettings settings) [0x00012] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxy.cs:48 
  at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrent.TestConnection () [0x00000] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrent.cs:214 

I found a corresponding error in qBitTorrents logs

(W) 2019-07-14T20:40:40 -  is not a valid IP address and was rejected while applying the list of banned addresses.
(N) 2019-07-14T20:40:40 - Web UI: Now listening on IP: *, port: 8080

Google really didn't bring up much. I suspect most people enable localhost authentication and ignore authentication processes entirely, but I can't get that to work when entering my subnets for the host PC/docker image.

 

I have no banned addresses entered - this is a clean image of qbit with no settings changed. I tried to enter some with no luck as well.

 

The only troubleshooting I've really found on this issue is here: https://www.reddit.com/r/qBittorrent/comments/9oej06/is_not_a_valid_ip_address_and_was_rejected_while/

 

 

The solution

Quote

I just found the answer.

In the Options > WebUI set the IP address to the real address of the server.The problem is that maybe there is a check there for the IP and it drops an exception

 

Doesn't work either, as changing the IP address to anything else results in being unable to connect to the webui.

 

I'd really like to get qbittorrent working, as I find it the most user friendly client!

 

 

Untitled.png

Link to comment
1 hour ago, tuna83 said:

 

 

I'd really like to get qbittorrent working, as I find it the most user friendly client!

 

 

 

Fixed! I had the wrong subnet in the docker settings.

 

entered 192.168.0.1 instead of 192.168.0.0

 

Interestingly, managed to typo that a few times since I think I reinstalled the docker image 3 times.

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.