A fully VPN’ed family member got hit with an automated copyright strike and when looking into how it happened I found out that using the default qBittorrent config with a killswitch-enabled ProtonVPN meant that the home IP address was being leaked. I verified it through a few tools, including ipleak(dot)net’s fake magnet link feature which showed both the VPN and home IPs when connected. I’m at best a tinkerer so I’m not sure if this is a Proton-exclusive problem at all, or if the killswitch useage is even relevant, but that’s what they were using and figured this all might be worth mentioning since it was certainly a shock to us and not something we’ve seen brought up before.
The solution was to change which network interface qBittorrent was set to use via “Tools > Preferences > Advanced > Network interface”. Which one to pick will depend on the protocol you’re using in Proton’s client, but unless you’re confident in what you’re doing I’d recommend testing each with the ipleak(dot)net (or similar) torrent tool until you’re only seeing the VPN IP show up.
Hope this is useful! (and not common knowledge that we were just wildly ignorant of)
For what its worth, I’ve been using this container for years and have never had any issues https://haugene.github.io/docker-transmission-openvpn/
This is probably the #1 reason I started using qbit and now use it in my homelab’s docker container.
I’m actually kind of shocked that these VPN clients don’t have little sandbox functions built into them where you can launch an app from within the client and the client keeps that app in a little sandbox that only has the clients own path to the internet. It would be an easy mode for this kind of thing.
Is there a way to do that (to software with a GUI) other than virtual machines?
Good find, that method is what I used too when I was still split tunneling my regular PC apps. Since then I have migrated to a docker setup using Qbittorrent’s webUI and I just run it’s network through a Gluetun container. Haven’t thought about it in ages.
Another option to preventing leaks is to run the qBittorrent application inside a namespace that only has the VPN interface passed through to it. Its basically like docker only you are just pulling the networking component out and using that. wg-netns is one tool that uses that approach to things. Might be more geared to the self-hosted community, but worth mentioning if anyone is wanting that level of security.
I’m curious if something like firejail may have a similar use-case here. I’ve only ever used it to block all connections to an application, but am wondering if it has similar functionality.
That’s a really good mention. I’m pretty sure firejail is usig linux namespaces too. It has a flag called
--netwhich accepts interfaces, so you could pass an existing VPN connection to it before it launches the torrent application. Probably a much cleaner way of doing it than YAML config files like I was suggesting.Hmm, well poking around it doesn’t seem to like using the necessary VPN interface, which with a killswitched wireguard ProtonVPN would be something like
--net=proton0. This is territory I’m wildly unfamiliar with, but it appears to fail because point-to-point “/31 networks” aren’t supported and as far as I can tell that’s the only applicable choice in this situation.
Binding the client to the VPN network interface is the only reliable method, I don’t know why it isn’t mentioned more in guides and stuff.
Sounds like they were using a vpn on their device but didn’t actually bind it to qbit. The solution you posted is exactly how you bind it to the vpn. So now even if the vpn leaks, qbit will cease to up/dwn. Glad you guys learned and hopefully you guys never get a letter again.
Most of our shock was from how useless the so-called killswitch turned out to be since the assumption was that any potential mistakes or bad configurations in an application would at the very least be outright blocked from connecting to anything.
I think it was also a massive gut-punch for them because they’d been heavily torrenting both privately and publicly for decades without ever hearing about this particular step of the process, so to realize their ass had been waving in the wind this whole time… oofph. Kinda surprised this is the first letter they’ve received, considering.
Definitely learned a lot, just wish it had been “on the tin”, so to speak.
so-called killswitch
It’s an ad
It’s also implemented as an actual feature rather than purely marketing fluff though, so the deception/ineptness goes further than just being an ad in my opinion. It clearly works for certain use-cases (e.g. disconnect the VPN and try to connect somewhere via browser or ping), but definitely not in the absolute way it (and particularly the “Advanced” setting) implies.
Yeah, those “kill switches” are marketed as being effective but they are imperfect. Same issues with Private Internet Access. They’re probably good enough for most people for browsing the internet, but when torrenting, it takes just one TCP packet to give you away.
The point is that the killswitch doesn’t seem to do much, at least on Linux in my experience. I’ve never had it work.
Transmission does this by explicit binding to the IP for a singular interface, which seems safer to me. By only sending data on the IP for the VPN, if anything goes wrong it will just literally refuse to send packets on the non-VPN network.
You can do this in qbt as well, op just didn’t have it set
I think proton has two levels of ‘killswitch’ on it’s VPN. The regular one is more of a ‘killswitch but only when you have the app open’ while the extra options are supposed to make it an actual kill switch. Whether or not this second level is completely effective I can’t say.
Binding your client to the vpn interface is definitely the way to go. This safety measure is widely known, but I feel that it is much less well known than it should be.
For the record the “Advanced” killswitch mode is what was used, so their assumption was that nothing would be able to leak and would, in worst case scenarios, just not connect at all. Which was definitely not the case.
Binding the interface is definitely the recommended way to go about it, it was in some manual when I first informed myself about torrenting. But it’s not required and easy to miss if you don’t consume correct resources, it’s not obvious.
Iduno how we both managed to miss that part over all these years. Neither of us are new to any of this and we’re both privacy fanatics… but somehow it slipped through the cracks. Enough tech-shame for a lifetime, condensed and consumed in a singular moment.
Always bind your torrent client to the VPN interface and use Socks5 if possible. I’ve been torrenting on Linux this way (albeit with a different provider) for the better half of my life and it hasn’t failed me once.
Exactly the correct approach. Similar thing happened to one of my friends a couple years back with Nord. This sort of “leak” could happen with any other VPN provider; not binding the interface is just rolling the dice.
Had either of us known about it beforehand we certainly would have. The lack of binding was definitely not an intentional choice.
Though as I’ve mentioned in a few other replies the biggest shock was how worthless the killswitch feature was. The presumption was that this screw-up is the exact kind situation that feature was designed to prevent, but clearly it’s either broken, total nonsense, or poorly/misleadingly described.
use Socks5 if possible
Not possible on ProtonVPN, unfortunately. They say that a SOCKS5 proxy is just a VPN without encryption. I’m not smart enough to tell you if they are wrong…seems to me that a user could use BOTH and enhance their privacy, but I have no clue.
You can use Socks5 on top of your existing connection. Some don’t even require authentication, just being connected to your regular VPN is enough.
This is why the most foolproof solution I’ve found is to use a docker container that has VPN and torrent client built-in. It’ll have the networking configuration done by someone who knows better. The most popular ones, like this, would permit no internet access out of the container outside of the VPN host. Then it doesn’t matter whether the torrent client binds to a specific interface or not, or what its configuration is. It’s trapped, or sandboxed, and the only way out is via the VPN tunnel. Once you have setup one of these, you can also reuse it from other containers with other apps, like your Usenet client, or even outside of containers via the built-in HTTP proxy. I know there’s also a qBit based container but I haven’t read into it or used it so I can’t vouch for it. The Transmission-OpenVPN based one is rock solid. Have used it for many, many years.
would permit no internet access out of the container outside of the VPN host
And that exactly the same as using the VPN network interface. No need to add more complexity to ones setup.
I outlined some differences that could make it worth it over just interface binding for some. Another is that it makes it impossible to accidentally have another application exit through the tunnel, leaking your identity, like a browser logged into gmail.com. You have to explicitly set the container as proxy in the browser for that to become possible. It also allows using a separate VPN connection, provider or region for the torrent client, while the desktop user is free to use a different VPN connection or none.
Good to know! I’ve avoided docker for years, but if there was a time to learn now would be it.
oh snap. i was not aware of that magnet service. thats handy for testing clients. scribbles down notes
Yeah it was a useful find! No idea about how trustworthy ipleak is though so do use with caution. There were a few other similar services I found while going through this, but I’m not having luck finding my notes on it at the moment… ipleak was just an easy one to remember the name of.
yeah, not a huge deal. I’ll be using it to as a smoke test for the personal media archive and distribution application im building.
got tired of not having reasonably priced archive storage.
Was this pc running Linux by any chance? I was in exact same scenario a few weeks ago. But only after I switched to Linux. Before that, never had any issues with protonvpn (or any VPN) and qbittorrent.
No problems since I did the same thing you did. Set qbittorrent to use only the VPN connection.
Yep, it was a Linux setup. I don’t know if they ever used Proton when they were still using Windows though so I’m not sure if the issue was happening on there as well.
