starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

qBittorrent doesn't always use external service to detect IPv6 / Leaks IPv6 #13956

New issue

Open

opened 2026-02-22 00:31:34 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-22 00:31:34 -05:00

Owner

Originally created by @haarp on GitHub (Nov 3, 2022).

qBittorrent & operating system versions

qBittorrent 4.4.5 x86_64
OS: Debian Linux bookworm
Qt: 5.15.1
libtorrent-rasterbar: 2.0.7-1+b1

What is the problem?

IPv4 is always detected through an external service to get the external IP. Relevant log lines look like Detected external IP: $ipv4.

For IPv6, an external service is used to get the IP (this is correct). But in addition, it also just uses system IPv6. Thus, there multipe logs:

Detected external IP: $external_ipv6
...
Detected external IP: $system_ipv6

And the system's IPv6 is being sent to trackers and thus leaked.

This is relevant when the VPN is on a different machine, i.e. the router. The qBittorrent machine gets assigned the real (non-VPN) IPv6, but is still routed over the VPN in the end. Binding qBittorrent to the VPN's IPv6 is not possible, as the machine doesn't own that address - the router does.

Simple solution: (optionally) disable auto-adding system IPv6s to the external IP pool.

Thanks!

Steps to reproduce

Set up qBittorrent machine with IPv4+IPv6
Set up router with VPN
Configure router to route all traffic from qBittorrent machine through VPN
Start qBittorrent
Observe qBittorrent log as it adds both the VPN's IPv6 and the system's IPv6 to the pool of external addresses

Additional context

No response

Log(s) & preferences file(s)

No response

Originally created by @haarp on GitHub (Nov 3, 2022). ### qBittorrent & operating system versions qBittorrent 4.4.5 x86_64 OS: Debian Linux bookworm Qt: 5.15.1 libtorrent-rasterbar: 2.0.7-1+b1 ### What is the problem? IPv4 is always detected through an external service to get the external IP. Relevant log lines look like `Detected external IP: $ipv4`. For IPv6, an external service is used to get the IP (this is correct). But in **addition**, it also just uses system IPv6. Thus, there multipe logs: ``` Detected external IP: $external_ipv6 ... Detected external IP: $system_ipv6 ``` And the system's IPv6 is being sent to trackers and thus leaked. This is relevant when the VPN is on a different machine, i.e. the router. The qBittorrent machine gets assigned the real (non-VPN) IPv6, but is still routed over the VPN in the end. Binding qBittorrent to the VPN's IPv6 is not possible, as the machine doesn't own that address - the router does. Simple solution: (optionally) disable auto-adding system IPv6s to the external IP pool. Thanks! ### Steps to reproduce 1. Set up qBittorrent machine with IPv4+IPv6 2. Set up router with VPN 3. Configure router to route all traffic from qBittorrent machine through VPN 4. Start qBittorrent 5. Observe qBittorrent log as it adds both the VPN's IPv6 and the system's IPv6 to the pool of external addresses ### Additional context _No response_ ### Log(s) & preferences file(s) _No response_

deekerman added the

Waiting upstream

Network

Libtorrent

labels

2026-02-22 00:31:34 -05:00

deekerman commented

2026-02-22 00:31:42 -05:00

Author

Owner

@ghost commented on GitHub (Nov 3, 2022):

The bug resides in libtorrent library and was reported once but not fixed.

@ghost commented on GitHub (Nov 3, 2022): The bug resides in libtorrent library and was reported once but not fixed.

deekerman commented

2026-02-22 00:31:44 -05:00

Author

Owner

@haarp commented on GitHub (Nov 3, 2022):

The bug resides in libtorrent library and was reported once but not fixed.

Cheers. Do you have an issue number? I'm having a hard time tracking it down. There are some issues that look related (e.g. arvidn/libtorrent#4803) but they're not quite the same and supposedly fixed.

@haarp commented on GitHub (Nov 3, 2022): > The bug resides in libtorrent library and was reported once but not fixed. Cheers. Do you have an issue number? I'm having a hard time tracking it down. There are some issues that look related (e.g. arvidn/libtorrent#4803) but they're not quite the same and supposedly fixed.

deekerman commented

2026-02-22 00:31:44 -05:00

Author

Owner

@ghost commented on GitHub (Nov 3, 2022):

I would suggest to create a new ticket there for prompt resolution.

@ghost commented on GitHub (Nov 3, 2022): I would suggest to create a new ticket there for prompt resolution.

deekerman commented

2026-02-22 00:31:44 -05:00

Author

Owner

@haarp commented on GitHub (Nov 3, 2022):

Done: arvidn/libtorrent#7176

@haarp commented on GitHub (Nov 3, 2022): Done: arvidn/libtorrent#7176

deekerman commented

2026-02-22 00:31:44 -05:00

Author

Owner

@lucasmz-dev commented on GitHub (Nov 16, 2022):

qBittorrent is very spotty with IPv6 support, no NAT64 support, it announces your permanent SLAAC address which LITERALLY has your MAC ADDRESS ON IT. It seems or at least someone said it breaks with the fact that the temporary addresses change every 24 hours, and I would bet that the 'Don't allow multiple connections from the same IP' takes only IPv4 mentality into mind and I am pretty sure that it only blocks connection from the same IP and not network. (the first 64 bits of an IPv6 address identify the network)

To be fair I guess every other client is also not properly implementing IPv6 which is hurtful because IPv6 means that people can actually be connectable and create a GOOD network, that isn't currently breaking down because of CGNAT like in IPv4.

@lucasmz-dev commented on GitHub (Nov 16, 2022): qBittorrent is very spotty with IPv6 support, no NAT64 support, it announces your permanent SLAAC address which LITERALLY has your MAC ADDRESS ON IT. It seems or at least someone said it breaks with the fact that the temporary addresses change every 24 hours, and I would bet that the 'Don't allow multiple connections from the same IP' takes only IPv4 mentality into mind and I am pretty sure that it only blocks connection from the same IP and not network. (the first 64 bits of an IPv6 address identify the network) To be fair I guess every other client is also not properly implementing IPv6 which is hurtful because IPv6 means that people can actually be connectable and create a GOOD network, that isn't currently breaking down because of CGNAT like in IPv4.

deekerman commented

2026-02-22 00:31:44 -05:00

Author

Owner

@Neustradamus commented on GitHub (Jan 30, 2025):

To follow this ticket.

@Neustradamus commented on GitHub (Jan 30, 2025): To follow this ticket.