I am using ProtonVPN, and have (or so I thought) set up qBittorrent to bind to the network interface that ProtonVPN is using (tun0). The connection symbol turns red if I turn off the VPN, and downloads will stop. However, when checking the torrent address on ipleak.net, it seems that this bind is not working properly - my real IP shows up after I have disconnected my VPN. I thought that there shouldn’t be any connections made when traffic is not via the tun0 interface, so that my real IP should never be known by the detection tool. Am I wrong?
I have not configured the kill switch, but perhaps I should do so?
You could also try split tunneling to specify that Qbittorrent goes through your VPN: https://protonvpn.com/support/protonvpn-split-tunneling/
I was under the impression that this would be redundant if you’re properly binding to an interface, but maybe it will help in your case.
That is unfortunately not available in the Linux client.
Im using gluetun + qbittorrent in docker containers. I was just following recommendations and it works amazingly well
Are you misreading the webpage?
What you’re describing seems like intended behavior. Other than what someone else here noted about using the proton0 adapter rather than tun0, you should not have to do anything other than bind qBittorrent to your VPN’s adapter to stop leaking any and all IP information to the peer swarm.
When you use ipleak.net, you will see your current IP address at the top. This has nothing to do with qbittorrent. Farther down, you need to add the “Torrent Address detection” magnet link to qBittorrent, then that sectoin of the page will show what IP address is being broadcast by qBittorrent (which should match the IP shown at the top of the page when your VPJN adapter is present and active.)
If you have qBit bound to an adapter that is no longer present, you should see both the Speed chart on qBit drop to zero and the page’s Torrent Address section will stop updating since it will no longer be receiving any new traffic.
It is the “Torrent Address detection” magnet link I am using, and it is this that reveals my real IP when the VPN is disabled. The traffic in qBittorrent stops though.
EDIT: And as I mentioned in an earlier post, it works as intended if I open the client when not connected to the VPN. It is just if the client is running while I disconnect that this problem occurs, as far as I can tell.
If that is indeed the case you should report this issue with as much detail as possible to the Proton team, because it seems like qBit is behaving propperly and there’s some portion of Proton virtual adapter that is failing here.
I use Proton Vpn as well, but I have a custom wireguard interface & server switching script via their API that doesn’t run into the same issue you’re describing. So the issue must lie somewhere in the Linux GUI app.
Do you get the same issue if you try using an openvpn or wireguard config generated from logging into the proton vpn website? or maybe just from the CLI version of the app?
I’m almost certain when using the official proton VPN app that proton creates a “proton0” network interface, or something similar, instead of using tun0. So you would have to bind to that interface instead of tun0.
I can’t remember for definite, its been so long since I used the official app.
I’m not sure it explains your problem though since you’re bound to tun0 anyway.
That was the case until the recent update to the Linux GUI client. I had to change the network interface bind in qBittorrent because the proton0-one stopped appearing. I assumed they had just made some changes, but could this mean that something is faulty with my install?
Its pretty weird, being specifically bound to tun0 and still having your IP show after disconnecting, makes it seem like there is something else running tun0 like openVPN or Wireguard without a kill switch enabled and they’re just not connected to a VPN, if you’ve ever used them?
You could probably test this if you exit qbittorrent completely and disconnect from your VPN then open qbittorrent again and connect to another network interface in qbittorrent like wlan0 and save it. Then reopen that setting and see if tun0 is still an option. I don’t think it should show up, if it does something is keeping tun0 active.
Either way, I would suggest uninstalling ProtonVPN v3 and v4 and reinstalling v4, maybe something is getting mixed up with v3 and v4 files?
https://protonvpn.com/support/official-linux-vpn-fedora/
https://protonvpn.com/support/official-ubuntu-vpn-setup/
Under the notes section they specifically show how to uninstall v3 so that might help too.
tun0 goes away when I am disconnected, so I don’t think anything is keeping it open. I noticed that connections in Proton VPN were set to UDP, so I changed this to TCP and this seems to have worked. Will still want to do more testing to be sure.
I don’t seem to have v3 installed, by the way. The old GUI tool seems to have been uninstalled when upgrading, and the CLI tool I unisntalled myself.
deleted by creator
Are you leaking data via IPv6? That’s a known issue at least with the default Wireguard configs, not sure about OpenVPN.
How could I check this?
In ipleak.net, your ipv4 address will be VPN IP and your IPv6 will be your own.
Hm, I don’t see any IPv6 addresses anywhere, even on https://ipv6.ipleak.net/
Ah then that’s not the issue then. Weird that the qbittorrent interface bind isn’t working for you. Maybe try Wireguard instead? Def set IPv6 to link local and add
::/0to allowed IPs on the Wireguard profile.
If I start the client without being connected through the VPN, my IP does not show up. It is only when the VPN connection is disconnected and I transition from one network interface to another. This is also if I have the kill switch enabled, so I imagine that if the connection is lost, I am safe as all internet access would be blocked then. And that it is only if I manually disconnect myself that this happens.
Could this be a Proton VPN issue? I am pretty sure I checked this previously, and didn’t see it before the recent Linux client GUI update, but I am not entirely sure.
I’ve noticed before that a manual disconnect from the VPN will automatically disconnect the kill switch but qbittorrent should still lose connection once its bound to the correct interface
Yeah, that is true - I didn’t formulate that quite well. This also happens to me when the kill switch is enabled, as it is disabled when I disconnect. However, it would not disable itself if I simply lost connection, which is in the case where I most want the leak protection. In the other cases, I could make sure to always quit qBittorrent before disconnecting from the VPN. Not ideal, as it would be easy to make a mistake.
In addition to binding, you must also turn off dht and local peer discovery.
Huh? You shouldn’t need to do this? Simply binding to the interface should be enough. Can you explain?
Edit: yep just tested it. Everything works. No clue what you’re talking about. First I’ve ever heard of it.
Following up once again on this comment. These aren’t required. Can you explain why you think they are? Does it work differently on Linux or something?
Edit: welp, no follow up from this person so I’m just gonna go ahead and say his comment was absolute fake news. Cool.
Thanks - those were both enabled, and I’ve disabled them now. However, this still happens after I’ve done this and restarted the client. I also tried turning off peer exchange that I found together with these options under the Privacy tab, also without solving the issue.
Not sure what to tell you. Mine works and doesn’t leak even if I turn it off on the fly. Are you sure that leak website isn’t showing your real IP cos, you know, turn off the vpn?
I’m using the Torrent Address Detection tool, which I assume is checking the IP broadcast by my torrent client.
After you disconnect the VPN the interface likely goes down so qbit falls back to the actual connection I think.
That is what the interface bind is supposed to prevent, or at least that is what I thought it was supposed to prevent. To avoid IP leaks in case of a lost VPN connection. I wonder if I’ve misunderstood it, or misconfigured it or something else.
You have some configuration wrong somewhere. It shouldnt connect to anything
You’re correct that it’s supposed to prevent leaks. It shouldn’t fall back, though there may be a checkbox for that somewhere in the menu that you have accidentally ticked? I’m not near my computer at the moment, so I can’t just go digging in my own menus to verify.
I’ve tried staring with all my might at the different options in the hopes I might identify something. I did turn off the features suggested above in the comment field, but have still been unable to solve it.
I don’t understand why that guy suggested turning off DHT and Local Peer Discovery. It shouldn’t matter…If you have the client bound to the VPN interface, then that should be that.
deleted by creator
