Client should not use all available interfaces for outgoing requests

[ValdikSS]

qBittorrent & operating system versions

• qBittorrent: 5.2.3
• libtorrent: 2.1.0
• Linux

What is the problem?

In short:

• qBittorrent in its default configuration uses all available network interfaces for outgoing requests
• To do so, it binds to both IP address and network interface
• This results in using all interfaces for outgoing requests per se, at least for DHT
• Most importantly, for L3/Point-to-Point interfaces (almost all tunnels: PPP, PPTP, OpenVPN, WireGuard, GRE, IPIP, ...) this results in using them even if no routes are present

---

Basically I've only added a GRE tunnel, added the address on it, and qBittorrent started to send UDP packets to DHT peers over it, even if there's no default route is configured for this interface.

Right now, from what I could see in the code and in the behavior, qBittorrent auto-detects network interfaces and configures 0.0.0.0, :: as lt::settings_pack::listen_interfaces and an empty string as lt::settings_pack::outgoing_interfaces

qBittorrent/src/base/bittorrent/sessionimpl.cpp

Lines 2247 to 2259 in e70f13d

	for (const QString &portString : asConst(portStrings))
	endpoints << (ip + portString);
	outgoingInterfaces << ip;
	#endif
	}
	}
	const QString finalEndpoints = endpoints.join(u',');
	settingsPack.set_str(lt::settings_pack::listen_interfaces, finalEndpoints.toStdString());
	LogMsg(tr("Trying to listen on the following list of IP addresses: \"%1\"").arg(finalEndpoints));
	settingsPack.set_str(lt::settings_pack::outgoing_interfaces, outgoingInterfaces.join(u',').toStdString());
	m_listenInterfaceConfigured = true;

According to libtorrent documentation, outgoing_interfaces:

This string is a comma-separated list of IP addresses and interface names. An empty string will not bind TCP sockets to a device, and let the network stack assign the local address.

but listen_interfaces

These are also used for outgoing uTP and UDP tracker connections and DHT nodes.

It seems that supplying 0.0.0.0, :: to listen_interfaces means that it will not use 0.0.0.0, :: in a sense of "bind to 0.0.0.0 and use default routing", but it handles it in a "smart" way of enumerating all interfaces and binding to all of them (opens the socket for each device and binds it both to the address (bind()) and to the device (setsockopt SO_BINDTODEVICE), as seen with strace).

I hope the comment for listen_interfaces means that every interface would be used only for DHT/trackers, and not for data downloading, but mentioning µTP makes me doubt it.

Steps to reproduce

1. On Linux, create dummy GRE interface: ip link add testgre type gre remote 1.0.0.0
2. Set it up: ip link set testgre up
3. Assign the address: ip addr add 192.168.60.1/32 dev testgre
4. Run tcpdump -n -i testgre
5. Launch qBittorrent

Result

First-launched qBittorrent starts to discover DHT peers over testgre interface, even if there's no default route over it.

15:21:40.106980 IP 192.168.60.1.64051 > 67.215.246.10.6881: UDP, length 111
15:21:40.107009 IP 192.168.60.1.64051 > 87.98.162.88.6881: UDP, length 111
15:21:40.107033 IP 192.168.60.1.64051 > 185.157.221.247.25401: UDP, length 111
15:21:40.107056 IP 192.168.60.1.64051 > 212.129.33.59.6881: UDP, length 111

Expected result

qBittorrent might listen for incoming connections on all interfaces but should not attempt to do any outgoing activity over non-default-route interface, especially with bypass of main routing table.

Additional context

No response

Log(s) & preferences file(s)

Default qBittorrent configuration (~/.config/qBittorrent and ~/.local/share/Qbittorrent clean).

[qBittUser]

qBittorrent: 5.2.3
libtorrent: 2.1.0

Did you or someone else modified v5.2.3 to work with libtorrent v2.1.0?

Linux
default configuration uses all available network interfaces for outgoing requests

Another user had similar issue, but was using Windows and wrote as if changing network interface didn't help:

• 5.1.4 and 5.1.3 use two internet connections concurrently in Win11 #24114

[ValdikSS]

Did you or someone else modified v5.2.3 to work with libtorrent v2.1.0?

No? Specifically ArchLinux, 5.2.3 is in repository, with libtorrent v2.1.0. I don't see any patches in the package, it's a regular 5.2.3.

I wrote more information in libtorrent issue.
arvidn/libtorrent#8642 (comment)

This is apparently a documented behavior of libtorrent
https://github.com/arvidn/libtorrent/blob/8c3f7f9126ad65eea8cfbf767b606316cdd938d2/docs/manual.rst#expanding-unspecified-addresses (and the whole "multi-homed hosts" paragraph), but I don't think this is a good defaults IMO.

[ValdikSS]

Will copy libtorrent comment here:

https://github.com/arvidn/libtorrent/blob/8c3f7f9126ad65eea8cfbf767b606316cdd938d2/docs/manual.rst#expanding-unspecified-addresses

expanding unspecified addresses

If an IP address is the unspecified address (i.e. 0.0.0.0 or ::),
libtorrent will expand it to specific IP addresses. This expansion will
enumerate all addresses it can find for the corresponding address family.
The expanded IP addresses are considered "local network" if any of the following
conditions are met:

• the IP address is in a known link-local range
• the IP address is in a known loopback range
• the item the IP address was expanded from was marked local (l)
• the network interface has the loopback flag set
• NONE of the following conditions are met:
  1. the IP address is in a globally reachable IP address range
  2. the network interface has the point-to-point flag set
  3. the routing table contains a route for at least one global internet address
     (e.g. a default route) for the address family of the expanded IP that points to
     the network interface of the expanded IP.

Due to ii (point-to-point), the interface is marked as non-local.
If non-point-to-point interface (wi-fi in my case) has default route with higher metric, it also will be used due to point iii.