Bypass authentication for clients in whitelisted IP subnets doesn't work with avahi

[flaggz]

Please provide the following information

qBittorrent version and Operating System

4.1.3 no gui Debian Testing

If on linux, libtorrent and Qt version

libtorrent-rasterbar 1.1.9-1 qtbase-opensource-src 5.11.1+dfsg-8

What is the problem

I try to access on local url from another computer on http://server.local:8080 but it asks for password even if "Bypass authentication for clients in whitelisted IP subnets" is enabled server ip is 192.168.1.3 client ip is 192.168.1.4 "Bypass authentication for clients in whitelisted IP subnets" is set to 192.168.1.0/24 It works if using http://192.168.1.3:8080

What is the expected behavior

Access in the web ui without password

Steps to reproduce

Install avahi on server Access web from another computer/Mac with the zeroconf ip (machinename.local)

[Piccirello]

Not really sure what's going on here. Do you have Bypass authentication for clients on localhost enabled?

[flaggz]

Yes Basically you need an Apple device as client and a linux server with avahi installed qbittorrent can't recognize the client in the whitelist if it has been accessed with an avahi address (hostname.local)

[Piccirello]

Can you try individually disabling clickjacking protection and CSRF protection and seeing if either of these has any effect? Is neither does, please try disabling both and test again (and of course re-enable both once finished testing).

[flaggz]

No changes, same result for all combination. If it helps when I connect with ssh using bonjour address (avahi) the shell says that I'm connected as xxxx::xxxx:xxxx:xxxx:xxxx (ipv6 address) So I think that qbittorrent is looking for ipv4 when instead is receiving a ipv6 address

[flaggz]

correction. the address expected by qbittorrent is ipv4 but avahi is giving ipv6

[AlexZigante]

was this ever solved? any suggestions?

[flaggz]

same problem with 4.2.5 qbittorrent needs to check the reverse address when not opened from a direct ip address

[biodigitalfish]

Same here. Doing dev using localhost:3000 against local Qbittorrent mapped to 8080. Doesn't work unless I disable CSRF protection. Would be great to have option for whitelist to include different ports

[GeorgeGedox]

The absurd focus of this project to prevent any changes regarding authentication baffles me. Yes, I want to be able to bypass the authentication, give a "Disable authentication" checkbox, I'm running this thing behind a reverse proxy, behind a firewall only for LAN usage and Authelia for authentication, I don't need to be asked two times to log in just because.

I've been on a binge trough around 5 issues related to bypassing authentication already and each of them were met with angry responses by the developers and long discussions that ended in the current ways of bypassing that don't work in Docker containers and the subnet things that is a joke when all that was needed was just a simple option to remove the authentication. People that use the webUI are not that inexperienced and I think that just a simple warning would be enough instead of the current measures.

[FranciscoPombal]

@GeorgeGedox

This report is specifically for issues with avahi. If you have a more traditional setup, you can just use "Bypass authentication for clients on localhost". This should work with your reverse-proxy setup.

[martin-c91]

I put in the exact ip/cidr and sill doesn't work. Have you managed to solved this?

[flaggz]

nope the server is expecting an ipv4 while the clients are connecting with ... (mac address?)

[salcatroppa]

More or less same setup here, except I'm running qBittorrent from a docker-compose, behind traefik and https://github.com/hardillb/traefik-avahi-helper.

I don't know if this could be of any help for you, but since I noticed an IPv6 in the logs I used an IPv6 CIDR and it worked.

172.23.0.0/24 -> ::ffff:172.23.0.0/120

[flaggz]

mine is different so doesn't work as yours

WebAPI login success. IP: fe80::41a:3d15:21a6:5540%enp3s0

[flaggz]

same problem with 4.5.0 alpha 1 any suggestion?

[giacomocerquone]

Yes Basically you need an Apple device as client and a linux server with avahi installed qbittorrent can't recognize the client in the whitelist if it has been accessed with an avahi address (hostname.local)

not really... I'm running qbitorrent on a windows 11 machine I'm using as a media center / nas and I'm trying to exclude the webui auth but using the hostname won't work.

So you don't really need any macos, apple, linux whatever system. I suppose that if you're connecting through the hostname to the machine running qbittorent, there is no way, currently, to disable the auth on the web panel.

If they'd just put the damn "disable auth" checkbox 😢 (don't tell me "do a pr", I've read they won't put it no matter what)

[flaggz]

Try to put * in the whitelist to bypass everything but it is not very secure I would just like to disable auth for the local network when using avanti/hostname. apparently it is not possible.

[giacomocerquone]

Try to put * in the whitelist to bypass everything but it is not very secure I would just like to disable auth for the local network when using avanti/hostname. apparently it is not possible.

It doesn't work, the add button is disabled if you enter "*" as ip subnet

[flaggz]

anyway if you ping the hostname.local address you get the ip so it can be solved in qbittorrent

[giacomocerquone]

anyway if you ping the hostname.local address you get the ip so it can be solved in qbittorrent

this again...

Yes, I can discover of course the IP of my local machine, point is that if I add it and then I access the web ui through its hostname it asks you the password nonetheless. This is the "bug"

[flaggz]

I'm telling that the devs can fix it, not that it is your fault

[PilaScat]

I have the same problem

[rwjack]

0.0.0.0/0 works But that's just stupid. We need qbit web to read some sort of ORIGIN_IP header, if the proxy option is checked. This will be the fix

[spencerthayer]

Is this fixed yet?

[flaggz]

Is this fixed yet?

Nope

[technodrome]

4 years to solve this. Jesus.

[rwjack]

^ not spam

[inertia666]

Same problem using Docker and Tailscale and adding 100.0.0.0/8. The whitelist doesn't work. Using 0.0.0.0/0 for now.

[qudiqudi]

Using 0.0.0.0/0 will expose the qbittorrent API to external. I noticed that with the NZB360 app. I have authelia in front of qbittorrent webUI and can still access my downloads list and control them via the API, although authentication is activated with said whitelist. This is a major security flaw. We need API bound authentication like the *arrs or sabnzb have it asap.

[Fma965]

Using 0.0.0.0/0 will expose the qbittorrent API to external. I noticed that with the NZB360 app. I have authelia in front of qbittorrent webUI and can still access my downloads list and control them via the API, although authentication is activated with said whitelist. This is a major security flaw. We need API bound authentication like the *arrs or sabnzb have it asap.

Came across this today also! NZB360 and Electorrent can access it without issue as they call the /api , and in most cases people have /api exlucded from authentik/authelia etc.

Looks like this is never going to be fixed though,

Curious how many people's torrent clients we could control since this doesn't seem to be widely known and everywhere just says yeah say 172.16.0.0 or 0.0.0.0 as the bypass addresses.

[chenks]

i came here also to find out how to disable the stupid webui authentication. qbittorrent running with docker, i don't expose the torrent client to the internet though (by that i mean i can only access the webui when on the local network), so really have no need for any sort of authentication on the webui.

i just entered 0.0.0.0/0 into the whitelist, i assume i won't have any sort of security related issues doing this?

[flaggz]

No issues. Just everyone that have access to your network can access qbittorrent webui without authentication.

[chenks]

No issues. Just everyone that have access to your network can access qbittorrent webui without authentication.

that would just be me then!

what made me wonder was what the previous post meant by "Curious how many people's torrent clients we could control since this doesn't seem to be widely known and everywhere just says yeah say 172.16.0.0 or 0.0.0.0 as the bypass addresses."

[qudiqudi]

No issues. Just everyone that have access to your network can access qbittorrent webui without authentication.

How can this be intended from a security standpoint? Mulit-user households, uni dorms ...

[flaggz]

No issues. Just everyone that have access to your network can access qbittorrent webui without authentication.

that would just be me then!

what made me wonder was what the previous post meant by "Curious how many people's torrent clients we could control since this doesn't seem to be widely known and everywhere just says yeah say 172.16.0.0 or 0.0.0.0 as the bypass addresses."

you said that the torrent client is not exposed to the internet. so the actual machine doesn't have internet access, right? why use a torrent client without internet access then? If you have internet access the torrent client is exposed to the net and could potentially be accessed by anyone. this is not the place to explain thoroughly internet security. take care.

[chenks]

i don't expose the torrent client to the internet though (by that i mean i can only access the webui when on the local network)

i said "i don't expose the torrent client to the internet though (by that i mean i can only access the webui when on the local network)"

[rwjack]

Can't believe we're still discussing this.

Running qbittorrent on a bare OS works FINE regarding this issue. We can permit. eg. a management network - 192.168.1.0/24, or a single management host, eg. the admin PC - 192.168.1.5/32

Running qbittorent in a docker container does NOT WORK how we expect it to. It doesn't matter what we permit since docker runs on it's own isolated network, basically making qbit inaccessible unless allowing 0.0.0.0/0 (which is just stupid).

As I wrote previously:

We need qbit web to read some sort of ORIGIN_IP header, if the proxy option is checked.

That way we can actually use the trusted proxy option, and voila, problem solved.

Now if only someone could convert this user story into code, that would be amazing.

[chenks]

Running qbittorent in a docker container IS NOT FINE!

whether you think it is fine or not neither here not there. just give us the god damn option to disable webui authentication so we can disable if WE choose to.

[rwjack]

I didn't express myself clearly.

When running qbittorrent on a bare OS, the setting works as intended.

When running qbittorent in a docker container, the setting DOES NOT WORK as intended.

[chenks]

When running qbittorent in a docker container, the setting DOES NOT WORK as intended.

no, no such setting currently exists. there is no setting to DISABLE webui authentication, there are settings to workaround it for various scenarios, but no setting to disable it complete.y

[rwjack]

Uhhh, english.exe has stopped responding?

I said the setting doesn't work as intended, not that it doesn't exist.

As for your specific issue, that option does exist, and it's solved by settingBypass authentication for clients in whitelisted IP subnets to 0.0.0.0/0

[chenks]

uuuh? intelligence.exe has left the building? most are asking for a setting that completely disables the webui authentication, not a setting that that gets around it by adding a whitelist.

[Fma965]

Can't believe we're still discussing this.

Running qbittorrent on a bare OS is FINE. We can permit. eg. a management network - 192.168.1.0/24, or a single management host, eg. the admin PC - 192.168.1.5/32

Running qbittorent in a docker container IS NOT FINE! It doesn't matter what we permit since docker runs on it's own isolated network, basically making qbit inaccessible unless allowing 0.0.0.0/0 (which is just stupid).

As I wrote previously:

We need qbit web to read some sort of ORIGIN_IP header, if the proxy option is checked.

That way we can actually use the trusted proxy option, and voila, problem solved.

Now if only someone could convert this user story into code, that would be amazing.

Fwiw this isn't strictly true, running a docker container with "host" networking will keep it's networking as if it was hosted outside of docker.

[spencerthayer]

It’s been four years, I don’t think this is gonna get resolved. My solution to this was an OpenWRT router and controlling access to my container via that router.

But the take that Docker isn’t a suitable environment is wildly out of touch with modern homelab / seedbox methodologies. I have the exact opposite opinion of @rwjack; running qbittorrent on “bare OS” is not best practice and shouldn’t be done except for in the most extreme limited memory use cases.

[Fma965]

I mean or iptables or any other firewall, pfsense, opnsense, etc

Regardless I've moved to other torrent clients so makes no difference to me.

[spencerthayer]

Regardless I've moved to other torrent clients so makes no difference to me.

What client?

[darkrypt3d]

I was having the same issue, I found a "dirty" fix that makes it work using the hostname instead of IP, you have to change your hosts file and add your server IP and hostname in the same line, save it and should be working. Remember you have to open the hosts file as admin to be able to change it.

[plenaerts]

mine is different so doesn't work as yours

WebAPI login success. IP: fe80::41a:3d15:21a6:5540%enp3s0

I'm far from an IPv6 or avahi expert, but I have my IPv6 address in my qbt logs suffixed with %end0. I confirmed my IPv6 address using ip addr, which shows the address and the CIDR for my end0 network interface, and end0 is the wired network interface I was using at the time.

I put fe80::/64 in my bypass subnets below my IPv4 subnet and the bypassing now works for me both for IPv4 and for IPv6 clients.

[flaggz]

doesn't work for me but what finally worked is using proper ipv6 annotation

you have to take the first 4 groups of the ipv6 address, that's your local network, and add ::/64 ad the end

ex: if your local ipv6 address is 2001:db8:abcd:0012:0000:0000:0000:0000 you can whitelist the entire local network by using 2001:db8:abcd:0012::/64 source https://www.ibm.com/docs/en/ts3500-tape-library?topic=formats-subnet-masks-ipv4-prefixes-ipv6

the problem with avahi is that the connection is always coming from the ipv6 of the local machine and not the device itself thou this is a security problem that needs to be fixed

[Neobond]

I feel safe adding 0.0.0.0/0 since I have a firewall configured in the NAS and the webUI port only allows computers on the local subnets, external addresses are blocked. (this even allows hostname.local to work)

But yeah, odd how 192.168.178.0/24 refuses to work. I even have IPv6 disabled in the NAS Network interface settings.