qBt traffic escapes allowed interface

[zeule]

My setup allows qBt to use tun0, which is managed by OpenVPN. When I suspend and resume the PC with running qBt, OpenVPN drops the connection, tun0 disappears and qBt continues to operate on wlan0 (regular WiFi).

[sledgehammer999]

Do you mean that in advanced settings you have selected "tun0" as your interface?

[zeule]

Do you mean that in advanced settings you have selected "tun0" as your interface?

Yes.

[sledgehammer999]

If you don't get any output in the log, I suspect that the bug is in libtorrent. We tell it "listen to this ip-interface". Once that ip goes away it should just get stuck there with not traffic. At least that is what reports said.
I think suspension/resume has something to do with it.
Can you test? ->While running and you disconnect the VPN connection, does qbt traffic stop?

[zeule]

Do you mean message "qBittorrent didn't find an %1 local address to listen on" from Session::getListeningIPs()? There is no this line in the log file. However, there are
"qBittorrent is trying to listen on interface 127.0.0.1 port ..." after I disconnect the VPN. So I think this is not a libtorrent issue.

[aleqx]

I wanted to create a separate issue but I'll post here. Let me know if this should be a new issue.

I'm on Windows 8.1 x64 and also running OpenVPN on a TAP interface. I configured qBT to listen to the TAP interface and it worked fine for a long time. Here's what happened recently.

• I updated OpenVPn, which also updated the driver for the TAP interface. The interface name didn't change, but most likely the GUID did
• qBT could not find the TAP interface and it said as much in the log
• qBT silently proceeded to use the main interface! this is very bad!
• I had no idea!!! <--- this is the biggest problem. I only discovered it a few days later by mistake.
• I went into qBT's advanced settings menu, chose a different interface, applied, then went back to choose the TAP again, restarted qBT and it then worked fine.

At the very least, qBT should warn the user that it could not bind to the specified TAP. However, it should stop right there. It should not continue to use a different interface if the one the userspecified could not be bound to.

[rodolpheh]

On this day, binding to a specific interface still doesn't limit access to the network. I'm using a VPN and i'm binding qbittorrent to tun0 in the advance settings. However, it is still uploading and downloading when tun0 is down. It used to work before (but don't remember the working version). I'm using 3.3.6-1 on ArchLinux x64.

EDIT: I just tried again, it still downloading even if tun0 is down. It says "interface is not valid : tun0". There was no resuming involved.

[sledgehammer999]

EDIT: I just tried again, it still downloading even if tun0 is down. It says "interface is not valid : tun0". There was no resuming involved.

What does the log say in this case? When the interface doesn't exist on launch, qbittorrent binds to 127.0.0.1. (or it should)

[sledgehammer999]

qBT silently proceeded to use the main interface! this is very bad!

Do you mean 0.0.0.0? qBittorrent in this case should bind to 127.0.0.1.

[rodolpheh]

This is the configuration relevant to the network (found in $HOME/.config/qBittorrent/qBittorrent.conf) :

Connection\GlobalDLLimit=-1
Connection\GlobalDLLimitAlt=10
Connection\GlobalUPLimit=-1
Connection\GlobalUPLimitAlt=10
Connection\InetAddress=
Connection\Interface=tun0
Connection\InterfaceAddress=
Connection\InterfaceListenIPv6=false
Connection\InterfaceName=tun0
Connection\MaxHalfOpenConnec=20
Connection\PortRangeMin=8999
Connection\Proxy\Authentication=false
Connection\Proxy\IP=0.0.0.0
Connection\Proxy\Password=
Connection\Proxy\Port=8080
Connection\Proxy\Username=
Connection\ProxyForce=true
Connection\ProxyOnlyForTorrents=false
Connection\ProxyPeerConnections=false
Connection\ProxyType=-1
Connection\ResolvePeerCountries=true
Connection\ResolvePeerHostNames=false
Connection\UPnP=true

As for my log, I can't find a way to copy them from the main interface. I'm trying to find where the log are stored, and a clue would be appreciated ;). Anyway it does seems to bind to 127.0.0.1.

EDIT: when I put tun0 up, it does detect the changes and bind to the new address. Anyway, every few seconds, it displays :

01/08/2016 16:06 - Network configuration of tun0 has changed, refreshing session binding

[sueridgepipe]

Using 3.3.6 on Manjaro Linux, binding all traffic to tun0, and when the VPN connection drops all qBt traffic reverts to wlan0.

This is a major bug and needs resolution asap.

Within the execution log these two messages repeat over and over, filling the log:

8/29/16 10:49 AM - Network configuration of tun0 has changed, refreshing session binding
8/29/16 10:49 AM - qBittorrent is trying to listen on interface xxx.xxx.xxx.xxx port: xxxx

This message was also in the execution log, which makes sense as the VPN connection dropped.

8/29/16 10:29 AM - The network interface defined is invalid: tun0

Anyone know how to configure IP Tables to ensure all traffic is always funnelled through tun0, regardless of qBt?

[sueridgepipe]

Just tested manually disconnecting VPN connection and it took about 30 seconds and all traffic was happily downloading through wlan0.

Big problem.

High priority fix.

[sueridgepipe]

As a workaround I have configured my firewall to block all traffic through my specific qBt port, on both wlan0 and eth0. Thus, qBt traffic works as usual on tun0, but if VPN connection drops the firewall will block all attempts to re-route qBt traffic to either wlan0 or eth0.

[DiegoAlbertoTorres]

10/8/16 12:40 PM - The network interface defined is invalid: tun0
10/8/16 12:40 PM - qBittorrent is trying to listen on interface 127.0.0.1 port: 18791 <<< Other interface.

This happens whenever openvpn restarts. Probably because OpenVPN removes and creates a new interface every time it is started or killed.

[Seeker2]

sueridgepipe said: "As a workaround I have configured my firewall to block all traffic through my specific qBt port, on both wlan0 and eth0."

The firewall will render qBT firewalled, giving it no incoming connections...but qBitTorrent's outgoing connections (which count against qBT's half open connection limit) do not use qBT's listening port...unless explicitly configured to do so, which can cause problems if it is!

[banyan47]

As sueridgepipe says, this is a big problem.

My (overkill) workaround was to follow these instructions for Ubuntu so that all traffic is blocked when the VPN drops.

[zeule]

Tagging @arvidn as it might be a problem in libtorrent.

[arvidn]

Note that there are two separate settings. One for which interface to listen on, and one for which interface to make outgoing connections over. If you listen on tun0 and it goes away, chances are that you no longer listen for incoming connections, but you may still make outgoing connections (unless you configure the outgoing_interface as well)

[zeule]

Bingo! Thanks a lot, @arvidn! qBt does not set settings_pack::outgoing_interfaces.

[zeule]

@arvidn, could you clarify also, please, how this done in libtorrent 1.0? We use session::listen_on() right now. I did not find any second method to set interface for outgoing connections.

[arvidn]

I believe 1.0.x only supports binding outgoing connections to specific ports (the use case was for routers that could do traffic shaping based on source ports).

[Seeker2]

If you want to do router-side QoS traffic shaping by ports, it's somewhat easier to put the outgoing ports next to qBT's single incoming listening port and then use a single QoS rule on the router. May need to leave extra port "room" for WebUI and other features as well if you use them.
(Hi arvidn, your comment looks strangely familiar. :)

[zeule]

I believe 1.0.x only supports binding outgoing connections to specific ports…

1.0.11 was leaking connections after a VPN drop and a call to session::listen_on() with a VPN iface address. 1.1.4 with #7099 seems to be working fine so far.

[alkim0]

This post may be related to this:
https://qbforums.shiki.hu/index.php/topic,5407.0.html

I posted part of a log output there which might be helpful.

[benpye]

I'm unfortunately seeing this behaviour, I'm running qBittorrent 4.0.4. Interestingly http://ipmagnet.services.cbcdn.com/ indicates that it only leaks over IPv6 and disabling IPv6 via Connection\InterfaceListenIPv6=false appears to have no effect. If I set Connection\InterfaceAddress to the specific IPv4 local address it still does not seem to work and I see my public IPv6 address being used.

Just to be clear this isn't with a typical tun/tap interface but instead a wireguard tunnel.

[arvidn]

also note that binding which interface outgoing connections are made via is not generally well supported. Different systems have different ways of doing it, but the classing model (which is still primarily how IP stacks work afaik) is that you have a single routing table for the machine. The outgoing interface you use is determined by the destination IP, which when it's on the internet will be going over the default route.

There's no way (normally) to change the routing table per socket (BSD has some fancy options for this that I'm not familiar with). So the general rule for outgoing connections is to be made over the default route. Now, there are some system specific socket options, like SO_BINDTODEVICE, IP_BOUND_IF and IP_FORCE_OUT_IFP to force outgoing packets over a specific interface.

Most of the sophisticated code around this feature is still in master (not in the libtorrent-1.1.x series).
1.1.x mostly tries to verify the local address of connections match the interface address of one of the interfaces we allow, and block connections.

[benpye]

Is there any client compatible with master. I would be interested to see if I get the same behaviour there.

…

On Wed, 11 Jul 2018, 10:56 Arvid Norberg, ***@***.***> wrote: also note that binding which interface *outgoing* connections are made via is not generally well supported. Different systems have different ways of doing it, but the classing model (which is still primarily how IP stacks work afaik) is that you have a *single* routing table for the machine. The outgoing interface you use is determined by the *destination IP*, which when it's on the internet will be going over the *default route*. There's no way (normally) to change the routing table per socket (BSD has some fancy options for this that I'm not familiar with). So the general rule for outgoing connections is to be made over the default route. Now, there are some system specific socket options, like SO_BINDTODEVICE, IP_BOUND_IF and IP_FORCE_OUT_IFP to force outgoing packets over a specific interface. Most of the sophisticated code around this feature is still in master (not in the libtorrent-1.1.x series). 1.1.x mostly tries to verify the local address of connections match the interface address of one of the interfaces we allow, and block connections. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5272 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbA__iC6tKUZHqf4Urs-8BLSjh9r3ilks5uFcvNgaJpZM4IiLNv> .

[zeule]

@benpye: I keep my qBt fork compatible with the libtorrent master branch, although it is untested on anything except Linux.

[thalieht]

Picotorrent (windows only) uses master branch as well but i don't know how recent it is. The only info i found about it using the master branch is in one of their Pull requests the author mentioned it.

[ghost]

@FranciscoPombal please close this as it has been fixed recently in libtorrent.