[Support] binhex - qBittorrentVPN

[Smonrad]

37 minutes ago, Arteekay said:

Thanks wgstarks, that appears to be all the hint I needed, resolved. But I'll post what happened in case it helps Smonrad or anyone else.

 

Apparently, since I installed this docker a few months ago, I was using the wrong value in "Container Variable: LAN_NETWORK". My IP is 192168.0.200, but I had 192.168.1.0/24 entered here. I've got hundreds of this entry in my supervisord.log. This has "worked" up until today's update. 

 

Changing to the proper 192.168.0.0/24 resolves the issue.

 

I find the following interesting entries in my supervisord.log from before and after:

 

• DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 

 

• file 'credentials.conf' is group or others accessible

 

• NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

 

Assumed they were nothing to worry about. 

 

New since today's update is the following entry:

 

• Error: argument "8080_qbittorrent" is wrong: invalid table ID

 

Doesn't appear in my archived log.

 

I've attached my supervisord.log for completeness. Hopefully I caught everything I should delete prior.

 

 

supervisord.log 22.94 kB · 1 download

Thank you @Arteekay, you are a legend!

 

Just as you, I had left that default on BOTH containers, it has worked for months but I guess something in the last update shook it loose, but incorrectly configured none the less.  After correcting I can get to both containers web gui’s.

 

Thank you very much!

[Arteekay]

That's awesome @Smonrad, I'm ecstatic I was able to resolve it (basically) myself, and that I helped someone else as well. It's a good day.

 

I was hoping to downgrade back to the previous version (Never did figure that out. another time maybe) but having to reconfigure the docker after deletion caused me to notice the problem. Was shocked when the interface loaded. 😁

 

 

[wgstarks]

45 minutes ago, Arteekay said:

was hoping to downgrade back to the previous version (Never did figure that out. another time maybe)

Downgrading is very simple. Just click the docker name in the unRAID docker tab. This will open the docker configuration. In the repository field type a colon after the name that’s already populated followed by the desired version tag. Version tags are available via the dockerhub link in the first post in this thread.

 

Example:

binhex/arch-qbittorrentvpn:4.5.5-1-02

[Arteekay]

Awesome. I knew there'd be a reasonably simple way.  Thanks again @wgstarks

[ADDAndy]

Im trying to get the this image up and running, but can't seem to access the webui when the vpn is turned on.

 

I've moved the port in question to 8083 (using the webui_port method)

The only way i can get this to work is either with the vpn off, or by putting it on the main bridge network. 

I have a similar setup on the deluge docker (proxynet + vpn on) and everything works fine.

 

but for some reason the same config doesn't work for qbittorrent

 

Any suggestions?

 

Attached is my supervisor log, and the network setup from docker:

supervisord.log

[binhex]

3 hours ago, ADDAndy said:

Im trying to get the this image up and running, but can't seem to access the webui when the vpn is turned on.

 

I've moved the port in question to 8083 (using the webui_port method)

The only way i can get this to work is either with the vpn off, or by putting it on the main bridge network. 

I have a similar setup on the deluge docker (proxynet + vpn on) and everything works fine.

 

but for some reason the same config doesn't work for qbittorrent

 

Any suggestions?

 

Attached is my supervisor log, and the network setup from docker:

supervisord.log 29.52 kB · 1 download

LAN_NETWORK is incorrectly configured, from your log:-
 

LAN_NETWORK defined as '10.10.124.1/24,172.18.0.3/16'

go read up here Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

[binhex]

8 hours ago, Smonrad said:

Just as you, I had left that default on BOTH containers, it has worked for months but I guess something in the last update shook it loose, but incorrectly configured none the less.

 

9 hours ago, Arteekay said:

Apparently, since I installed this docker a few months ago, I was using the wrong value in "Container Variable: LAN_NETWORK". My IP is 192168.0.200, but I had 192.168.1.0/24 entered here. I've got hundreds of this entry in my supervisord.log. This has "worked" up until today's update.

i have literally NO idea how that would of previously worked!, I have not touched iptables whatsoever in the latest release, so if it broken with the latest it should of been broken with the previous version, are you guys sure you didn't change your home network address space or introduce VLAN's into your network?.

[Smonrad]

4 hours ago, binhex said:

 

i have literally NO idea how that would of previously worked!, I have not touched iptables whatsoever in the latest release, so if it broken with the latest it should of been broken with the previous version, are you guys sure you didn't change your home network address space or introduce VLAN's into your network?.

Hi Binhex

 

I promise I did not change anything to do with my network subnet and certainly did not implement any VLANing or anything, certainly something I would remember! 😄  I'm just going to chock it up to my fault for not properly configuring the containers in the first place and must just be a lucky guy for it working as long as it did.

 

Your containers rock, thank you for the work you do!

[Darryl Lang]

Came here because I suddenly couldn't get to the webui for qBittorrent this morning. I had to roll back to version 4.5.5-1-01 for it to work again, the -02 and -03 had the same issue.  Is there anything I can add to this recent discussion that would help?

[wgstarks]

32 minutes ago, Darryl Lang said:

Is there anything I can add to this recent discussion that would help?

The supervisord.log with the latest version installed. Be sure that user and passwords are redacted.

[binhex]

1 hour ago, Darryl Lang said:

Came here because I suddenly couldn't get to the webui for qBittorrent this morning. I had to roll back to version 4.5.5-1-01 for it to work again, the -02 and -03 had the same issue.  Is there anything I can add to this recent discussion that would help?

There was an issue upstream with the base os, please try pulling down latest (built around 30 mins ago).

[tahd]

I am really enjoying the application, but I was curious if the VPN connection ceases will qbittorrent stop downloading (like it would if you had it bound to the VPN on the windows application)? I was looking through the settings but I couldn't really find a definitive answer. I just wanted to make sure I am covered in case VPN malfunctions.

[binhex]

5 minutes ago, tahd said:

I am really enjoying the application, but I was curious if the VPN connection ceases will qbittorrent stop downloading (like it would if you had it bound to the VPN on the windows application)? I was looking through the settings but I couldn't really find a definitive answer. I just wanted to make sure I am covered in case VPN malfunctions.

Q1:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

[ericreager]

I'll just add a "me too" for having LAN_NETWORK incorrectly configured, worked fine for last few months, lost WebUI sometime in the last couple days, corrected LAN_NETWORK, now everything is working again. I also have not made any changes to my network and I checked my router's update log and nothing updated since 9/9. 

 

And thanks to all who worked that out. 

[Arteekay]

14 hours ago, binhex said:

 

i have literally NO idea how that would of previously worked!, I have not touched iptables whatsoever in the latest release, so if it broken with the latest it should of been broken with the previous version, are you guys sure you didn't change your home network address space or introduce VLAN's into your network?.

 

Bizarre right? I'd have noticed the problem on initial install had it not worked. I'm new to unraid/docker, only picked it up about three months ago.

 

i was at work over a cloudflare tunnel happily upgrading my entire library to h265/1080p+ as I've done for a few long weeks when I noticed the update. As I've done for months now, I mindlessly clicked update and expected nothing to go wrong. Only noticed a half hour later that the webui hadn't reloaded. I've had that happen a few times after restart, so I stopped and restarted while watching the log. Once I'd see that "listening on 8080" it would always work, not this time.

 

i of course can't prove nothing else changed, but I can at least provide the original log generated since install.

 

On a side note, I have noticed that occasionally I'll be stuck at around 7MiB/s after a few hours/days/whatever. Pausing and resuming active torrents changes nothing, but I'd restart the container and suddenly go back up to my usual 50/60MiB/s. Hardly any real inconvenience, but thought I'd mention it anyway. 

 

Cheers and thank you for your time and efforts, truly wonderful.

 

 

supervisord.old.log

[Green Dragon]

Thanks @binhex for everything you do for the community!

 

This docker has always worked great for me using the default (ip) bridge network and does so even today.  However, I recently found that when I try to move it to my custom (macvlan) network which all of my other media management dockers (sonarr, radarr, lidarr, sabnzbd, etc) are on the media management dockers all time out trying to connect to qbittorrentvpn and I cannot access the qbittorrentvpn docker webui.  Essentially, nothing is able to connect to it.

 

Here are my networks:

default unraid bridge (ip) network address: 172.16.1.100/24

bridge (macvlan) network address: 172.16.1.168/24 (qbtvpn address. each docker has its own static address)

 

Attached is the supervisord.log that is generated when the docker is using the custom (macvlan) network (address .168) that does not work...

 

Thoughts?

168.supervisord.log

[H2OKing]

is there a way to use the Run external program on torrent finished to run this?

curl -XPOST http://cross-seed:2468/api/webhook --data-urlencode "name=%N"

It only works when VPN is turned off

Edited September 24, 2023 by H2O_King89

[Mattti1912]

Hello people..

 

I use this container.. I use Vpn, but also a proxy.. But does anyone know how to check both connections simultaneously??

 

Best Regards

[H2OKing]

20 hours ago, H2O_King89 said:

is there a way to use the Run external program on torrent finished to run this?

curl -XPOST http://cross-seed:2468/api/webhook --data-urlencode "name=%N"

It only works when VPN is turned off

Found my fix. I tried using the ip address of the server with no luck then i tried the docker ip and that worked. I tried pinging cross-seed and could not find it. I added the ip address the other dockers use for a name server 127.0.0.11. now I can use hostnames

[wallywally]

1 hour ago, H2O_King89 said:

Found my fix. I tried using the ip address of the server with no luck then i tried the docker ip and that worked. I tried pinging cross-seed and could not find it. I added the ip address the other dockers use for a name server 127.0.0.11. now I can use hostnames

I adding the dns in my docker-compose.yml file but it didn't work...

Something like...

dns:

   - 127.0.0.11

 

How did you add the name server?

[Darryl Lang]

On 9/21/2023 at 7:49 AM, Darryl Lang said:

Came here because I suddenly couldn't get to the webui for qBittorrent this morning. I had to roll back to version 4.5.5-1-01 for it to work again, the -02 and -03 had the same issue.  Is there anything I can add to this recent discussion that would help?

fyi, I can't say I understand the fix, but I changed the LAN_NETWORK entry from "10.0.1.1/24" to "10.0.1.0/24,10.0.30.0/29,192.168.118.0/23" and it's working with the -04 release now.  I am accessing from the 10.0.1.0/24 network so I would think both the old and the new "Should have" been valid.

[binhex]

3 minutes ago, Darryl Lang said:

but I changed the LAN_NETWORK entry from "10.0.1.1/24"

yep thats def wrong see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

4 minutes ago, Darryl Lang said:

I am accessing from the 10.0.1.0/24

if you are accessing from web browser only from 10.0.1.0/24 then you can remove the others, that's some wacky networks you got setup there, a network with 8 hosts only per network (10.0.30.0/29) never seen somebody use that before on their home network.

[sundown]

21 hours ago, H2O_King89 said:

Found my fix. I tried using the ip address of the server with no luck then i tried the docker ip and that worked. I tried pinging cross-seed and could not find it. I added the ip address the other dockers use for a name server 127.0.0.11. now I can use hostnames

Could anyone provide additional information here?  @H2O_King89 when you mention "tried the docker ip" - are you referring to the docker internal addresses (in my case 172.17.x.x)?  To clarify, I'm also attempting to run a Crossseed command (identical to the one quoted here).  I have my LAN_NETWORK correctly set to 192.168.2.0/24 and have NO problems reaching the webUI from my home network (192.168.2.x) (not to be confused with the other user's issues here).  However running "nc -zv 192.168.2.222 2468" from qbittorrent's command line returns a "connection timeout."  Executing this from any of my other dockers succeeds.

[binhex]

15 hours ago, sundown said:

However running "nc -zv 192.168.2.222 2468" from qbittorrent's command line returns a "connection timeout."  Executing this from any of my other dockers succeeds.

completely expected, this image is highly locked down to prevent ip leakage, you will not be able to connect to an ip on your lan with port 2469 from within the container, what is the problem you are trying to solve?.

[sundown]

5 hours ago, binhex said:

completely expected, this image is highly locked down to prevent ip leakage, you will not be able to connect to an ip on your lan with port 2469 from within the container, what is the problem you are trying to solve?.

Attempting to call, via qbittorrent's "run external command" functionality, an API call from another container (cross-seed) to check if a torrent can be cross seeded at the torrent's completion.  The command is:  curl -XPOST http://ipaddress:2468/api/webhook --data-urlencode "name=%N".  I was hoping that the LAN_ADDRESS worked both inbound and outbound - but appears to only impact incoming requests to qbittorrent (for the UI).  Do I have any options?