[Support] binhex - qBittorrentVPN


Recommended Posts

Good day.

 

wg0.conf is losing it's permissions every time it starts, is unable to be read, and thus fails to start the container citing unable to connect to wg0. I am using a new conf downloaded from the provider but it does the same thing. Even if I set permissions using chmod, it just reverts upon starting the docker.

Am I missing something simple here?

Link to comment
11 minutes ago, KinkyBanjo said:

I did consider spending the time bringing it up to VPNUnlimited. But if deluge's vpn docker and the OpenVpn client connect without issue using this exact same configuration file it makes it harder to convince them its something on their end.

the latest qbittorrent image no doubt has a later version of openvpn as the image been built more recently, this new version is now flagging the cert provided by your vpn provider as insecure, you can either ignore the error and use an earlier version of this image (not what i would do), or get your vpn provider to provide a cert that isnt insecure (the right thing to do), i will leave it up to you to decide.

 

p.s. delugevpn and sabnzbdvpn will be showing the same error once they get updated with the later version of openvpn (common base).

 

https://forums.openvpn.net/viewtopic.php?t=34656

  • Thanks 1
Link to comment
5 hours ago, reporrted said:

Good day.

 

wg0.conf is losing it's permissions every time it starts, is unable to be read, and thus fails to start the container citing unable to connect to wg0. I am using a new conf downloaded from the provider but it does the same thing. Even if I set permissions using chmod, it just reverts upon starting the docker.

Am I missing something simple here?

 

Fixed it. I changed the owner of the file to root and now it retains permissions. If this is bad, please let me know?

 

Cheers.

Link to comment
7 hours ago, KinkyBanjo said:

I did consider spending the time bringing it up to VPNUnlimited. But if deluge's vpn docker and the OpenVpn client connect without issue using this exact same configuration file it makes it harder to convince them its something on their end.

I am also having this issue with VPNUnlimited using openvpn. I have attempted to migrate to wireguard, but now I am having dns failure issues instead. Keep me posted on anything you find, and I will do the same! (I would be very happy if I can get wireguard to work. It's a much more efficient protocol) 

Link to comment

Good Day,

 

I switched over to Mullvad VPN and got two questions.

 

1) The Container is running and working except for port forwarding. The wireguard config contains the port which is supposed to be forwarded and I have entered the same port in qbt settings. Qbt is also bound to wg0 and the IP address set in the wireguard config. However, I am not connectable.

Am I missing something? Are the following variables to be used with Mullvad? -e VPN_INPUT_PORTS=<port number(s)> \ -e VPN_OUTPUT_PORTS=<port number(s)> \

 

2) DNS Leaks: When browsing over privoxy, the Mullvad checking site detects DNS Leaks. There are no DNS leaks when using the Mullvad App with Privoxy disabled. So, I assume it has to do with the DNS servers in the container config. By default, I use Binhex recommended servers (-e NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 \). However, even removing these does not stop the leaks. Any advice?

 

Thanks!

 

Edit: Alright, 1)  is no longer a problem. The port forwarding setup with Mullvad is kind of confusing as the forwarded port is NOT the port you can choose when creating the config file but a random port that you get assigned at a later step. Anyway, port forwarding seems to be working now. You also do not need to put the port in the docker compose but only add it in qbt.

 

@binhex Do you have any idea regarding the 2) DNS leaks?

Edited by TombRaider
progress
Link to comment

I was also experiencing issues with Wireguard (Mullvad) on the latest version since updating, speeds were stuck at 1MiB/s maximum, a far cry from the 60 I usually get.

 

I rolled back to 4.4.5-1-01 using the exact same configs and now speeds are back to normal. Happy to provide more details if that helps in diagnosis.

 

EDIT: Also interesting to note is that it only seemed to be download speeds which were restricted, seeding speeds seemed okay. I did also try fresh openvpn configs from Mullvad on the latest version and it just wouldn't connect. I've just tried mullvad openvpn on the older build and I'm getting issues as well, but I prefer using Wireguard. Happy to provide logs on that as well if it will be helpful.

Edited by Fromnack
More info
Link to comment
22 hours ago, TombRaider said:

2) DNS Leaks: When browsing over privoxy, the Mullvad checking site detects DNS Leaks. There are no DNS leaks when using the Mullvad App with Privoxy disabled. So, I assume it has to do with the DNS servers in the container config. By default, I use Binhex recommended servers (-e NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 \). However, even removing these does not stop the leaks. Any advice?

this is expected, privoxy is a http(s) proxy only it will not proxy dns requests so dns requests will go over your ISP not via the VPN tunnel, this is NOT the case for torrent clients as they do not use privoxy, they simply use the VPN tunnel directly setup inside of the container.

  • Upvote 1
Link to comment
26 minutes ago, binhex said:

this is expected, privoxy is a http(s) proxy only it will not proxy dns requests so dns requests will go over your ISP not via the VPN tunnel, this is NOT the case for torrent clients as they do not use privoxy, they simply use the VPN tunnel directly setup inside of the container.

Thanks for the explanation. It makes sense.

To make sure I understand, do torrent clients use DNS servers and this would be the reason why we should use the name server list you provided? If not, I assume we could leave this variable empty.

Link to comment
59 minutes ago, TombRaider said:

do torrent clients use DNS servers and this would be the reason why we should use the name server list you provided

correct, and without dns you would also be unable to resolve any vpn endpoint hostname and thus unable to connect to your vpn provider.

  • Thanks 1
Link to comment
On 11/24/2022 at 10:07 PM, Narvath said:

Have you found the issue? I'm having the same thing...

Something is totally broken with the image (Edit: or not, see below), all settings reset to default (including password which is `adminadmin`). I hope none of you have it exposed to the internet.

 

Edit: Could be a qb issue, due to power loss on the server.

Edited by another_one
Link to comment
Something is totally broken with the image, all settings reset to default (including password which is `adminadmin`). I hope none of you have it exposed to the internet.
Going from qbit 4.3.x to 4.4.x does lead to loss of some settings (qbit issue), other than that I've seen no loss of settings myself.

Sent from my 22021211RG using Tapatalk

Link to comment

Haven't had it happen recently but I do think the settings resetting is an issue with this container.  I personally only ever saw it after my unraid system crashed/unexpectedly shutdown, but have seen a few people post about it in this thread.  I never moved from 4.3 so it's unrelated to any 4.3->4.4 issues.  

 

When it happened it was a complete loss of the settings, as if the conf file was deleted and regenerated to a default state.  From just having the qBittorrent.conf file open in Notepad++ it seems like its constantly being saved every ~minute or so, maybe if the system or container becomes unresponsive this can sometimes cause it to overwrite it with an empty file?

Link to comment
21 minutes ago, THF13 said:

Haven't had it happen recently but I do think the settings resetting is an issue with this container.  I personally only ever saw it after my unraid system crashed/unexpectedly shutdown, but have seen a few people post about it in this thread.  I never moved from 4.3 so it's unrelated to any 4.3->4.4 issues.  

 

When it happened it was a complete loss of the settings, as if the conf file was deleted and regenerated to a default state.  From just having the qBittorrent.conf file open in Notepad++ it seems like its constantly being saved every ~minute or so, maybe if the system or container becomes unresponsive this can sometimes cause it to overwrite it with an empty file?

Alright, then it's probably what happened to me. I had a power loss the other day. Could be corruption that qb does on its own.

 

Edit: For now I just rolled back to 4.4.5, considering 4.5 is not supported in few places.

Edited by another_one
Link to comment
13 hours ago, THF13 said:

I personally only ever saw it after my unraid system crashed/unexpectedly shutdown

data loss due to unexpected shutdown/crash can happen for any application, if the file is open and being written to at the time the crash occurs then you may end up with either a corrupt file (half written) or an empty file, the trick is to try and minimise this from happening by employing a UPS for browouts/blackouts and decent quality hardware that is verified as good (mem checks for instance), and of course make sure you have backups - install plugin 'Appdata Backup/Restore v2'.

Link to comment
4 minutes ago, owzo said:

Maybe this has already been asked, but is there a correct way to downgrade the qBittorrent-VPN to a pervious version?

I accidentally updated my docker to 4.5, however my trackers have not whitelisted this version yet.

Open the docker configuration (click the docker name) and in the repository field type a colon and tag number (no spaces). Click “apply” at the bottom of the page. You can get the tag number from dockerhub. See the link in the first post.

Link to comment
1 hour ago, wgstarks said:

Open the docker configuration (click the docker name) and in the repository field type a colon and tag number (no spaces). Click “apply” at the bottom of the page. You can get the tag number from dockerhub. See the link in the first post.


Thank you so much, worked like a charm. 

Link to comment

Had an issue with 4.5 where memory ballooned to about 4GB, best I can tell.

 

My system should have been able to handle it but I couldn't investigate – GUI was non-responsive and even simple bash commands would throw "resource fork" errors (maybe nproc limits?) I managed to restart the server and downgrade cleanly, no problems since.

Link to comment
Had an issue with 4.5 where memory ballooned to about 4GB, best I can tell.
 
My system should have been able to handle it but I couldn't investigate – GUI was non-responsive and even simple bash commands would throw "resource fork" errors (maybe nproc limits?) I managed to restart the server and downgrade cleanly, no problems since.
Interesting, not seen this problem myself....yet

Sent from my 22021211RG using Tapatalk

Link to comment

Hi, I updated to the v4.5.0 qbittorrent and I've found that the queue icon does not seem to not load in the table.

 

Seems like the queue.svg file did not download as /images/queue.svg does not exist. Other icons like /images/download.svg do exist, which show fine as seen in screenshot below;

 

image.png.e892628588b0fccc60edec408365709f.png

Link to comment

I also was having weird issues with the latest version and downgraded but was still getting an issue with the wireguard interface starting. Replaced with a new wg0.conf from Mullvad but now the only way the container works is to start it privileged. I clearly have some kind of permission issue somewhere. Any ideas? wg0.conf is already root owned.

Link to comment
I did consider spending the time bringing it up to VPNUnlimited. But if deluge's vpn docker and the OpenVpn client connect without issue using this exact same configuration file it makes it harder to convince them its something on their end.
I spoke to VPNUnlimited about this issue (depreciated cipher AES-256-CBC), and they said that they are aware of the problem and are issuing new certificates to the servers, but in the meantime add this to your openvpn.conf

tls-cipher DEFAULT:@SECLEVEL=0

It's not optimal, but it works for now,

Sent from my SM-G965W using Tapatalk

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.