4.2.2 will not connect to VPN

[Marque66]

Please provide the following information

qBittorrent version and Operating System

4.2.2 Windows 64 8.1

If on linux, libtorrent-rasterbar and Qt version

(type here)

What is the problem

no downloading unable to connect to VPN

What is the expected behavior

reinstall 4.2.1 working fine VPN = BT Guard

Steps to reproduce

(type here)

Extra info(if any)

Thanks

[Gorthezar]

I'm also having issues with QBT refusing to connect to VPN.

[Ninjistix]

same here, with socks5 enabled all torrents get stalled.

[roemba]

can confirm, exact same issue, I use Mullvad with Wireguard if that helps and also running via socks5 proxy

[Kolcha]

can't confirm... VPN provider - AirVPN, VPN client software - OpenVPN client. no any issues on any OS (macOS/Windows/Linux), official qBittorrent 4.2.2, tried both public torrents (aka Linux distros) and private torrents, magnet links. everything was fine for me. download was started in few moments, upload also works fine.

so, it looks like only specific connection types are affected...

[ghost]

I don't have this issue and I'm using a VPN too. This seems to be a problem with a certain OpenVPN configuration + socks5 settings.

[FranciscoPombal]

@pencilbook @Kolcha

I don't have this issue and I'm using a VPN too. This seems to be a problem with a certain OpenVPN configuration + socks5 settings.

Mind posting your system/qbittorrent configs relating to network/VPN/socks5, so that they can be compared to other users'?

[Kolcha]

nothing special, on macOS and Windows I'm using VPN client app from provider (AirVPN), it is just an UI around OpenVPN daemon, on Linux - clean OpenVPN client (daemon, started by systemd) with config generated by provider's config generator (online tool) what about qBittorrent settings, I just disable UPnP and set port what I have as forwarded. the rest - defaults "out of the box" (I performed clean installations, removing any qBittorrent data). I didn't select VPN interface in qBittorrent' advanced settings, when VPN is connected, all traffic goes through it by default. so, from qBittorrent point of view there is no difference if I am connected to VPN or not. later I'll try to select interface and report results here. right now only can say that qBittorrent 4.2.2 with libtorrent 1.1 (self-compiled, running on Debian, libtorrent from repo) also have no issues with VPN, even with selected interface.

[FranciscoPombal]

config generated by provider's config generator (online tool)

These are the details that matter - whether or not you are using port mappings, TCP or UDP, etc....

I didn't select VPN interface in qBittorrent' advanced settings, when VPN is connected, all traffic goes through it by default. so, from qBittorrent point of view there is no difference if I am connected to VPN or not.

Are you sure? How does the client app guarantee this? Does it modify the routing tables or something, so that programs that bind to any address end up going through it anyway? Is there no way such methods could be causing problems?

later I'll try to select interface and report results here. right now only can say that qBittorrent 4.2.2 with libtorrent 1.1 (self-compiled, running on Debian, libtorrent from repo) also have no issues with VPN, even with selected interface.

:+1:

[Kolcha]

there is everything except keys/certificates from my OpenVPN client config generated by mentioned online tool, I just added lines launching some script, just because all linux manuals said to do that (I'm not admin, I know nothing about this script purpose):

# --------------------------------------------------------
# Air VPN | https://airvpn.org | Thursday 25th of April 2019 08:26:53 PM
# OpenVPN Client Configuration
# AirVPN_Czech-Republic_UDP-41185-Entry2
# --------------------------------------------------------

client
dev tun
remote cz2.vpn.airdns.org 41185
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
route-delay 5
verb 3
explicit-exit-notify 5
push-peer-info
setenv UV_IPV6 yes
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
proto udp
key-direction 1
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Are you sure? How does the client app guarantee this? Does it modify the routing tables or something

I'm 100% sure, on Linux routing table is modified when VPN connection is established, and tun0 device becomes first in list (routes from my "production" server):

nick@animesrv:~$ ip route 
0.0.0.0/1 via 10.33.16.1 dev tun0 
default via 192.168.0.1 dev enp30s0 
10.33.16.0/24 dev tun0 proto kernel scope link src 10.33.16.9 
89.238.166.236 via 192.168.0.1 dev enp30s0 
128.0.0.0/1 via 10.33.16.1 dev tun0 
192.168.0.0/24 dev enp30s0 proto kernel scope link src 192.168.0.10 

moreover, on Windows and macOS, provider's app (VPN client), reports up/down speed, so when torrent starts, I can see that. even more, I can monitor VPN connections from the web, also showing the current speed. see attached screenshots

even more, on my Linux seeding server I used iptraf-ng just to ensure that nothing except VPN and ssh connections goes though my ethernet card when torrent is active, and I saw no traffic on it as expected, all torrent traffic gone through tun0 interface.

I tried to configure qBittorrent to bind just one VPN interface on Windows (see first screenshot), nothing changed in its behavior, everything works as before - torrent are loading (see second screenshot). so, I assume there is no issues affects me, and it is safe for me to upgrade my server to use qBittorrent 4.2.2 with libtorrent 1.2 instead of 1.1 shipped with distro. I even already created a repo for Debian with it, but not upgraded yet

[FranciscoPombal]

@roemba @Gorthezar @Marque66 @Ninjistix Do you have Tools -> Preferences -> Advanced -> Network Interface set to Any interface? If not, go to https://github.com/qbittorrent/qBittorrent/issues/12253 and follow the steps in https://github.com/qbittorrent/qBittorrent/issues/12253#issuecomment-605348631 and https://github.com/qbittorrent/qBittorrent/issues/12253#issuecomment-605360856.

The workaround is to set the option to Any interface and configure your VPN to force all traffic on your system to go through it. Usually this is a simple option in your VPN client.

If you DO have it set to Any interface, let us know below.

[Ninjistix]

@FranciscoPombal yes mines is set to any interface.

[FranciscoPombal]

@Ninjistix since you are using SOCKS5 and not VPN, wait for 4.2.3 which will have improve SOCKS5 error logging. Then you can post the logs and then hopefully the problem can get fixed.

[Gorthezar]

@roemba @Gorthezar @Marque66 @Ninjistix Do you have Tools -> Preferences -> Advanced -> Network Interface set to Any interface? If not, go to #12253 and follow the steps in #12253 (comment) and #12253 (comment).

The workaround is to set the option to Any interface and configure your VPN to force all traffic on your system to go through it. Usually this is a simple option in your VPN client.

If you DO have it set to Any interface, let us know below.

@FranciscoPombal I have mine bound to my VPN not any interface however I rolled back one Version and it works fine so for the time being that is my workaround. Thanks for the response and help :)

[FranciscoPombal]

@roemba @Gorthezar @Marque66 @Ninjistix Do you have Tools -> Preferences -> Advanced -> Network Interface set to Any interface? If not, go to #12253 and follow the steps in #12253 (comment) and #12253 (comment). The workaround is to set the option to Any interface and configure your VPN to force all traffic on your system to go through it. Usually this is a simple option in your VPN client. If you DO have it set to Any interface, let us know below.

@FranciscoPombal I have mine bound to my VPN not any interface however I rolled back one Version and it works fine so for the time being that is my workaround. Thanks for the response and help :)

Then, in your case, you should go over to https://github.com/qbittorrent/qBittorrent/issues/12253

[dvikulin]

4.2.2 macOS Mojave 10.14.6

Torrents stalled (on dowloading metadata stage). I am using Windscribe VPN. Checked to use option "Any interface", but it did not help. Rolling back to 4.2.1 solved the issue for me. Please see log in attachment. log.pdf

[FranciscoPombal]

@dixistenz

4.2.2 macOS Mojave 10.14.6

Torrents stalled (on dowloading metadata stage). I am using Windscribe VPN. Checked to use option "Any interface", but it did not help. Rolling back to 4.2.1 solved the issue for me.

Are you using proxy also? What about Tools -> Preferences -> Advanced -> Optional IP address to bind to? Do you also have it set to "Any address"?

[dvikulin]

Yeah, it's set to "All addresses"

[FranciscoPombal]

@ everyone please post your logs.

[gothicserpent]

I just tested with 4.2.2 on Windows 10 using: Options->Connection->Enabled Protocol: TCP Advanced->Network Interface->Optional IP Address to bind to: All addresses Advanced->Network Interface->Any interface and did a restart of QBittorrent.

I am able to connect this way, as indicated in this image:

Here are my logs when these settings are active (any interface): https://pastebin.com/i8dsM77r

in the qbittorent.log file, it says (among other successful listen lines, these are just 2): (I) 2020-03-30T16:56:21 - Successfully listening on IP: [real ip], port: TCP/9638 (I) 2020-03-30T16:56:21 - Successfully listening on IP: [real ip], port: UDP/9638 and I confirmed my real ip/ipv6 was listed in there. For an abundance of privacy I will revert again to my VPN interface (mullvad) for now in settings, and select the option TCP and uTP for the protocol, which does connect via uTP. Hope this helps.

When I go back to my previous privacy setup with VPN selected as the interface (Optional IP Address to bind to: All addresses remains the same, using TCP and uTP protocol), these are the only 6 listen lines I get in the log (here is the full log when my mullvad VPN is selected as the interface - https://pastebin.com/aZWpwmVu):

(I) 2020-03-30T17:09:09 - Successfully listening on IP: fdda:d0d0:cafe:443::1006, port: TCP/9638 (I) 2020-03-30T17:09:09 - Successfully listening on IP: fdda:d0d0:cafe:443::1006, port: UDP/9638 (I) 2020-03-30T17:09:09 - Successfully listening on IP: fe80::878:e4cf:942f:61cf%24, port: TCP/9638 (I) 2020-03-30T17:09:09 - Successfully listening on IP: fe80::878:e4cf:942f:61cf%24, port: UDP/9638 (I) 2020-03-30T17:09:09 - Successfully listening on IP: 10.5.0.8, port: TCP/9638 (I) 2020-03-30T17:09:09 - Successfully listening on IP: 10.5.0.8, port: UDP/9638

These are the ipv6, link-local ipv6, and ipv4 addresses of my mullvad vpn, and my real ipv4/ipv6 is not listed there. There are no other Successfully listening on IP lines other than these in my log when I revert to my VPN as an interface, for my continued assured privacy.

Here's part of the result of ipconfig /all I did to confirm the information of my mullvad VPN:

Unknown adapter Mullvad: IPv6 Address. . . . . . . . . . . : fdda:d0d0:cafe:443::1006(Preferred) Link-local IPv6 Address . . . . . : fe80::878:e4cf:942f:61cf%24(Preferred) IPv4 Address. . . . . . . . . . . : 10.5.0.8(Preferred)

Here is a double check torrent magnet download test I did with my VPN provider's website to make sure QBittorrent is not leaking my own IP when in use (selecting VPN as interface) with the public IP of the VPN hidden with 0s:

[ghost]

@FranciscoPombal yes mines is set to any interface.

This doesn’t look like qBt 4.2.2 interface. It shouldn’t contain that listen on ipv6 thing.

[FranciscoPombal]

@Ninjistix upgrade to 4.2.2 (or 4.2.3, as it may have already released when you see this) and try again.

[ghost]

@FranciscoPombal if qBt 4.2.3 is going to be released soon then I’d request to use libtorrent 1.2.3 till these issues get sorted out. Otherwise VPNs will remain broken for many users.

[FranciscoPombal]

@an0n666 As far as we know, VPNs are not completely broken, just when you select the specific adapter. I find it strange that selecting any interface fixes the problem for every user except one in this thread. It must be something else (the others have either not confirmed they have the VPN interface selected or are not using 4.2.2). Also, from what I have seen in other threads, only libtorrent 1.2.5 works well with Wireguard, for example.

[FranciscoPombal]

@gothicserpent wait, so you're saying that even when forcing all system traffic through the VPN, if you select "Any interface" in qBittorrent, your real IPv6 still gets leaked? Please confirm this.

[ghost]

I agree that it’s not completely broken. But this ticket confused me. I myself couldn’t reproduce the issue when all interfaces is selected.

[FranciscoPombal]

Please see log in attachment. log.pdf

Please use a text file instead or copy-paste in a new comment if it's small enough. See the attachment rules at https://github.com/qbittorrent/qBittorrent/blob/master/CONTRIBUTING.md

[gothicserpent]

@FranciscoPombal from what i saw in the log (I) 2020-03-30T16:56:21 - Successfully listening on IP: [real ipv6], port: TCP/9638 (I) 2020-03-30T16:56:21 - Successfully listening on IP: [real ipv6], port: UDP/9638

Those lines were listed. The traffic may be flowing through my VPN but I didn't want there to be a possibility of it going through the real IP. I was under the assumption that if I selected any interface with the TCP protocol it would choose my real ethernet adapter if the VPN wouldn't connect.

When I tried the VPN provider's website that I mentioned above to see if my IP was leaking when using any interface & TCP, the result did not display on the webpage. It may have been an error -- or the IP was being leaked. It did not exactly specify IP Leaked on the page though, so maybe if someone else was to confirm this it would be helpful.

From what I understand, my vpn automatically routes all traffic. So it's very likely that even if the connection to the ethernet adapter is successful it was still routing through the VPN after all. I just took all the security measures mentioned on my vpn provider's site to promote privacy.

[ghost]

@gothicserpent when you select any interface to bind, qBt binds to all available interfaces. But your VPN should force all traffic through the VPN gateway.

If you want to prevent IP leak on VPN disconnection then using a killswitch/firewall is the only solution now till the manual interface selection bug gets patched.

[gothicserpent]

Makes sense. I am currently using uTP / vpn interface and it works for my needs. haven't noticed any issues. I'll be happy to move to TCP once that's resolved.

@FranciscoPombal Just did a quick test to see if this was the case -- it seems what was said here is correct and traffic is flowing through my VPN gateway when I select any interface and TCP. My mullvad VPN Provider's leak test site was not functioning due to high latency, so I went to the torgaurd checkmytorrentipaddress site, downloaded a magnet torrent, and had the site display what IP it was that they found that downloaded the torrent file (replaced the real public VPN ip with 0s).

So in summary my real ipv4/ipv6 does not leak when selecting any interface.

[FranciscoPombal]

Great, closing this as a duplicate of https://github.com/qbittorrent/qBittorrent/issues/12253. Some people are reporting the symptoms of that issue have been fixed in 4.2.3.