New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qBt traffic escapes allowed interface #5272

Open
zeule opened this Issue May 19, 2016 · 28 comments

Comments

Projects
None yet
@zeule
Contributor

zeule commented May 19, 2016

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

This comment has been minimized.

Contributor

sledgehammer999 commented May 23, 2016

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

@zeule

This comment has been minimized.

Contributor

zeule commented May 23, 2016

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

Yes.

@sledgehammer999

This comment has been minimized.

Contributor

sledgehammer999 commented May 23, 2016

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

This comment has been minimized.

Contributor

zeule commented May 23, 2016

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

This comment has been minimized.

aleqx commented Jun 15, 2016

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

This comment has been minimized.

rodolpheh commented Aug 1, 2016

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

This comment has been minimized.

Contributor

sledgehammer999 commented Aug 1, 2016

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

This comment has been minimized.

Contributor

sledgehammer999 commented Aug 1, 2016

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 comment has been minimized.

rodolpheh commented Aug 1, 2016

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

This comment has been minimized.

sueridgepipe commented Aug 28, 2016

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

This comment has been minimized.

sueridgepipe commented Aug 28, 2016

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

This comment has been minimized.

sueridgepipe commented Aug 29, 2016

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

This comment has been minimized.

DiegoAlbertoTorres commented Oct 8, 2016

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

This comment has been minimized.

Seeker2 commented Oct 9, 2016

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

This comment has been minimized.

banyan47 commented Nov 8, 2016

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

This comment has been minimized.

Contributor

zeule commented Jul 12, 2017

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

@arvidn

This comment has been minimized.

arvidn commented Jul 12, 2017

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

This comment has been minimized.

Contributor

zeule commented Jul 12, 2017

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

@zeule

This comment has been minimized.

Contributor

zeule commented Jul 12, 2017

@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

This comment has been minimized.

arvidn commented Jul 13, 2017

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

This comment has been minimized.

Seeker2 commented Jul 13, 2017

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

This comment has been minimized.

Contributor

zeule commented Jul 13, 2017

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 comment has been minimized.

alkim0 commented Oct 29, 2017

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

This comment has been minimized.

benpye commented Jul 11, 2018

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

This comment has been minimized.

arvidn commented Jul 11, 2018

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

This comment has been minimized.

benpye commented Jul 11, 2018

@zeule

This comment has been minimized.

Contributor

zeule commented Jul 11, 2018

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

@thalieht

This comment has been minimized.

Contributor

thalieht commented Jul 11, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment