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)
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.