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)

  • Confining@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    53
    ·
    23 hours ago

    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.

    • lerky@lemmy.blahaj.zoneOP
      link
      fedilink
      English
      arrow-up
      15
      arrow-down
      2
      ·
      23 hours ago

      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.

        • lerky@lemmy.blahaj.zoneOP
          link
          fedilink
          English
          arrow-up
          5
          ·
          21 hours ago

          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.

      • JasSmith@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        7
        ·
        22 hours ago

        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.

    • iAmTheTot@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      22 hours ago

      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.

      • bad_news@lemmy.billiam.net
        link
        fedilink
        English
        arrow-up
        3
        ·
        21 hours ago

        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.