Hey fellas,
just came across this sub to discuss my torrenting issue.
I am using linux, have a mullvad subscription and use qbittorrent. Because I read something about VPN-killswitches not being 100% reliable, I also bound the network interface from my mullvad-VPN to the qbittorrent-client.
Now something, what is kind of weird. I started a testrun over night with some legal torrents. In the morning I saw, that the downloads where finished and also seeding. The mullvad client said, that it was connected. But when I wanted to make a “torrent-IP-leak-test” online, I realized, that I couldn’t open any website, because the “website couldn’t be found” (firefox btw).
So I tried to ping 8.8.8.8, which worked, so I assume it must be something wrong on a DNS-level. In terminal I also checked if the Mullvad network interface was still connected, and it was. After I made a simple reconnect to the VPN-server via the MV-client, everything was normal again.
My first guess was, that this issue possibly occurs, because my ISP does an automatic reconnect in the middle of the night.
Now I’m wondering if that setup still can be considered safe. Did you experience similar problems? Is it a threat to privacy?
Using Debian if that’s important.
~sp3ctre
+++EDIT+++
Observation 1: The source of the issue must be the automatic reconnect in my router (required from ISP) in the middle of the night. It encountered too, when I chose another reconnect-time. A manual reconnect in the router interface led to the same issue. Interestingly, pulling the plug from the router doesn’t lead to it.
Observation 2: Since I wasn’t able to check my external IP without being able to DNS-resolve these “ip-check-websites”, I decided to go the direct way via IP of the website (found via who.is), which worked for some websites. Turns out, at least my IP-address seems not to leak (its my VPN-IP). These special torrent-IP-check-websites won’t work at all, if the DNS can’t be resolved at the beginning of the process (when putting the test-torrent into the list).
I will try if it makes any difference, when I turn of my alternative-DNS in the router. Will also try some other VPN-servers.
You must log in or register to comment.
You might want to investigate vopono which allows specific applications to run in a separate network space. This you could for example run Firefox or qbittorrent in a separate virtual network that can only communicate via Mullvad VPN tunnel but not see anything outside it. This is great for desktop use. Another great option is gluetun which allows other docker containers to be bound to a VPN tunnel.
Even if Mullvad did erroneously allow applications to access your physical network connection for a moment, because you bound qbittorrent explicitly to the network device of the Mullvad VPN, qbittorrent will never use the physical connection.
You can check this out easily by disconnecting Mullvad and trying to torrent something on qbittorrent and also browsing the Net: you’ll notice the browser gets through just fine but qbittorrent will not.
Mullvad leaking would be a problem if what you’re worried about is loss of privacy or government surveillance, not for torrenting if your torrent server is correctly bound to the VPN device.
Yeah, I tried that with disconnecting and the torrents stopped immediately, which is good.
Just wondering, why I cannot open any websites in the morning, while the torrents are still working…leaves a bad feeling, but maybe I’m also overreacting about this.
It might be a DNS problem.
I vaguely remember that Mullvad has a setting to make sure that DNS queries go via the VPN but maybe that’s not enabled in your environment?!
Another possibility is that Mullvad going down and then back up along with your physical connection when your ISP forces a renewal of the DHCP is somehow crapping up the DNS client on your side.
If you have the numerical IP address of a site, you can try and access the site by name in your browser when you have problems in the morning and then try it by nunerical IP address - if it doesn’t work by name but it does by numerical IP it’s probably a DNS issue.
PS: you can just run the “ping” command from the command line to see if your machinr can reach a remote machine (i.e. “ping lemmy.dbzer0.com”) and don’t need to use a browser (in fact for checking if you can reach machines without a webserver, the browser won’t work but the ping command will).
Thought so too. As described above, I tried pinging 8.8.8.8., which worked out. Didn’t try reaching 8.8.8.8. via browser though.
I also have an alternative privacy-friendly DNS set up in my router. Not sure, if that can be a problem. Normally, the DNS of Mullvad is used.
But another question is: Could that be a privacy-risk? Torrenting works without DNS-resolving, doesn’t it?
Well, if the trackers are specified as names (and a quick peek at some random torrent shows that most if not all all), those do have to be resolved to IP adresses and if that DNS query is happening outside the VPN then your ISP as well as the DNS server being queried can see you’re interest in those names (and it wouldn’t be hard to determine with a high probability that you are indeed torrenting something, though WHAT you are torrenting can’t really be determined by you merely accessing certain servers which have torrent trackers active, unless a specific server only tracks a single torrent, which would be pretty weird).
Things like peers aren’t DNS resolved since they already come as IP adresses.
So when it comes to torrenting as far as I know all that the DNS can leak is the information that you ARE torrenting but not specifically WHAT you are torrenting.
It’s more in things were you’re constantly doing DNS queries, such as browsing, that DNS leaking can endanger you privacy: if for example somebody is going to “hotsheepbestialityporn.com”, somebody at their ISP could determine that person’s very specific sexual tastes from seeing the DNS queries for hotsheepbestialityporn.com coming in the open from their connection.
Interesting!
So if I get it right: Only when starting a torrent, some DNS needs to be resolved? And when the torrent is already running not?
So in my case a possible DNS leak occurs somewhere in the middle of the night. Not right from the beginning.
Look, I’m extrapolating from the general rule to the specific case of torrenting.
The general rule is that, because the IP protocol requires numerical addresses to connect to a remote machine, if what you have is a site name you have to translate that name into a numerical address before you can actually establish a connection, and a DNS query is how you translate site names into their numerical IP addresses.
Now, if you look at the contents of a tracker, what you see are not numerical addresses but site names, so those must be translated into numerical addresses before your client can connect to those trackers, hence DNS queries are done to do that translation.
Meanwhile, if you look at the “peers” section in an active torrent in your torrenting program, you see that they all have numerical IP addresses, not site names. This makes sense for two reasons:
- Most of those machines are user machines, and usually users don’t just buy a domain to have site names for the machines they used only as clients (i.e. browsing, torrenting and so on) since that is not at all needed. Site names are required for machines which serve stuff (literally, “server machines”, such as machines hosting websites) to arbitrary clients that by their own initiative connect to that machine - they’re meant as a human readable memorable alias for the numerical IP address of a machine, which people can enter in appropriate fields of client applications to connect to that site (i.e. putting “lemmy.dbzer0.com” in your browser rather than having to remember that its IP address is “51.77.203.116”)
- As I said, IP connections require IP numerical addresses to be established. For performance reasons it makes sense that in the torrent protocol the information exchanged about peers and between peers is always and only the machine’s numerical IP address since with those there is no need to do the additional step which is the DNS query before they can be used by the networking layer to open TCP/IP or UDP/IP connections to those peers.
Hence my conclusion is that the torrenting protocol itself will only deal with site names (which require DNS queries before network connections can be made to them) for the entrance into the protocol (i.e. start up and connect to trackers) and then deal with everything else using numerical IP addresses only, both because almost no peer will actually have a site name and because it’s low performance and doesn’t make sense to get site names from peers and have to resolve those into numerical addresses when then peer itself already knows its numerical address and can directly provide it. Certainly that’s how I would design it.
Now, since I didn’t actually read the protocol or logged the network connections in a machine torrenting to see what’s going one, I’m not absolutely certain there are now DNS queries at all after the initial resolution of the trackers of a torrent. I am however confident that it is so because that makes sense from a programming point of view.
I understand the basic concept of DNS but I am just a little unsure in which part of the process it takes effect. Thanks for your point of view!
Possible but very, and I mean VERY low chances that it will happen. And mullvads killswitch should be reliable. Killswitch is the problem in shitty vpns - mullvad is not one of them.
Yeah, it may be good. Unfortunately unpredictable things can happen…
Mullvad pussied out a few years ago and blocked port forwarding for torrents. Is be surprised if you got a good outcome using mullvad
It may not be ideal for torrenting, but it works for me I think. Maybe that’s a topic for another thread.
were you actually leaking something? Like did you check? Because web browsers generally use DOH now. Are you using librewolf by chance? I think it uses Quad9 by default.
And Mullvad is very good with its killswitches. They talk about random software/OS bullshit they have to deal with quite frequently.
I am using the normal version of firefox.
I am currently not aware of a (torrent) leak-checking method, without using the browser. How would be your approach?
And Mullvad is very good with its killswitches.
Yeah, I heard good things about it. Just wanting to make sure, things are going well.
Tools like
https://ipleak.net/provide torrent leak checkers. You need a browser to view the results, but they provide a magnet link you use in your torrent client to assess what information it is giving out.In theory if everything is set up right it should show exclusively IP/location information associated with your VPN
Personally I’d vnstat to check what interface peer connections are bound to.
Following this thread, let us know if you have a resolution op.
Yeah, I will investigate it further. Do you have similar issues?
I use mullvad and qbittoerrent as well, but I’m not savvy enough to have noticed any leakage. Hence my interest.
Just go to ipleak.net and run torrent leak test if you suspect any torrent ip leaks.
Yeah, did that. Couldn’t DNS-resolve the website because of the issue, but going via direct IP of the “check-website” (found via who.is) made me at least check my IP, which turned out to be the VPN-IP. Torrent-IP-Checking won’t work, because torrents seem to need at least DNS-resolving at the beginning of download.
What’s your browser’s DNS setting? Ping is using the system wide settings and some browsers (FF) might use DNS via HTTP. Idk if mullvad are providing the latter or where you set your DNS server when connecting.
I guess I can rule that one out. FF has DNS-over-HTTPS but it’s turned off. The DNS from Mullvad is usually used in my case…
Well, if it’s not DNS then most probably the routing might have been set wrong. Faulty netfilter rules are less likely but possible.
