this post was submitted on 22 Oct 2023
56 points (95.2% liked)

Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

54577 readers
490 users here now

⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.

Rules • Full Version

1. Posts must be related to the discussion of digital piracy

2. Don't request invites, trade, sell, or self-promote

3. Don't request or link to specific pirated titles, including DMs

4. Don't submit low-quality posts, be entitled, or harass others



Loot, Pillage, & Plunder

📜 c/Piracy Wiki (Community Edition):


💰 Please help cover server costs.

Ko-Fi Liberapay
Ko-fi Liberapay

founded 1 year ago
MODERATORS
 

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?

all 32 comments
sorted by: hot top controversial new old
[–] [email protected] 5 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago

That is unfortunately not available in the Linux client.

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 1 points 1 year ago

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?

[–] [email protected] 4 points 1 year ago

Im using gluetun + qbittorrent in docker containers. I was just following recommendations and it works amazingly well

[–] [email protected] 3 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago (1 children)

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?

[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago

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.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 1 points 1 year ago (1 children)

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

[–] [email protected] 1 points 1 year ago

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.

[–] [email protected] 1 points 1 year ago (1 children)

Are you leaking data via IPv6? That's a known issue at least with the default Wireguard configs, not sure about OpenVPN.

[–] [email protected] 1 points 1 year ago (1 children)
[–] [email protected] 1 points 1 year ago (1 children)

In ipleak.net, your ipv4 address will be VPN IP and your IPv6 will be your own.

[–] [email protected] 1 points 1 year ago (1 children)

Hm, I don't see any IPv6 addresses anywhere, even on https://ipv6.ipleak.net/

[–] [email protected] 1 points 1 year ago

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 ::/0 to allowed IPs on the Wireguard profile.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Intended.

You bound torrent client to tun0 You bound VP to tun0

If VPN is on, torrent client connects using VPN. If VPN is off, torrent client cannot connect to VPN or internet.

This is what should happen. It would be more helpful if you told us what you want to do. Do you want the torrent client to keep downloading but no longer behind the VPN? Because most people don’t want that. Which is why they set it up your way. Just in case the VPN accidentally goes down, you dox yourself.

Also a point I haven’t seen made, but a website is not torrent traffic. You could be behind a VPN through your browser but not through your torrent client (Apple’s Private Relay does this, only blanking you from websites). So the fact your torrent client stopped and the web was working seems to point to everything working as it should. You shouldn’t lose any internet unless it’s also bound to tun0.

Also, what did you use to create the tun0 interface to bind your client and VPN to?

[–] [email protected] 0 points 1 year ago (3 children)

In addition to binding, you must also turn off dht and local peer discovery.

[–] [email protected] 9 points 1 year ago* (last edited 1 year ago)

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.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

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.

[–] [email protected] 2 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago (1 children)

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?

[–] [email protected] 1 points 1 year ago

I'm using the Torrent Address Detection tool, which I assume is checking the IP broadcast by my torrent client.

[–] [email protected] -3 points 1 year ago (1 children)

After you disconnect the VPN the interface likely goes down so qbit falls back to the actual connection I think.

[–] [email protected] 13 points 1 year ago (3 children)

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.

[–] [email protected] 5 points 1 year ago

You have some configuration wrong somewhere. It shouldnt connect to anything

[–] [email protected] 2 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

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.