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.
As part of a websites DNS info they have to provide a TTL (time to live). This value can be just about anything but is often in the 30s to 5m range, and serves as an instruction on how long a client should cache the IP address locally before checking for updates.
This is because IP addresses can change, and you don’t want to experience hours of downtime for all clients every time your IP changes.
Every time your client queries your tracker for server updates (every few minutes, give or take, based on tracker preferences) it should follow your system DNS settings, which should involve checking your local cache, then going to the upstream server indicated in your system DNS settings.
If your system is set to a DNS server outside of your local network (e.g., 8.8.8.8) that request should go through your VPN
If your system is set to use a local DNS server (e.g., 192.168.X.X…), typically either done through something like a pi-hole, or if your router sets itself as the DNS server then forwards all requests, this MIGHT create a DNS leak around your VPN.
A good VPN like Mullvad should have an option to force their own DNS settings when enabled to prevent this leak.
Let’s say the torrent started with a working DNS and the issue occured some hours later. Maybe the client wants to check for IP-updates then, but won’t find any, because DNS doesn’t work anymore. It will still keep the IP-adresses resolved at the beginning, right? Because then it would make sense, that I saw some working torrents, even though the issue already appeared.