[Solved] Torrenting with mullvad - Possible leak?
[Solved] Torrenting with mullvad - Possible leak?
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 1+++
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.
+++EDIT 2+++
The Mullvad-support solved my problem. I want to share it with you:
It is probably because the NetworkManager updates /etc/resolv.conf which the Mullvad app also updates. So it overwrites the change that the app made.
The Mullvad app does not use the NetworkManager but it will use systemd-resolved if you configure that. Disconnect Mullvad and use the following commands:
sudo systemctl enable systemd-resolved
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl start systemd-resolved
sudo systemctl restart NetworkManager*
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).
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.
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.
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.
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...
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.