I’m pretty sure that if apps wanted to use/access other interfaces, they could. That’s why you need to bind qBittorrent to your VPN interface correctly so it doesn’t use other interfaces accidentally and leak your IP.
Is this still an issue?
Yes, but tbf if you are worried about apps that can run arbitrary commands, then the app can run iwconfig (iw dev on fedora)and get the MAC address of the wifi you are connected to (and other info like the name). So your location could also be inferred from this, but with more effort (and I guess you could make the MAC address of your wifi change regularly)
Thanks so much for this. I followed these directions and the ones at WireGuard on Linux terminal (advanced) to set up a few multihop config files.
My main priority is NO LEAKS, so I set my browser homepage to Connection check | Mullvad VPN and everything looks good right now.
My question is…are there any disclaimers for this method like there should be with the GUI clients? Like, are there any “if you do ______ then you will potentially leak your ip” scenarios? Or, as long as the wg icon is showing connected in my gnome options menu, is this a true killswitch like on android?
I sometimes need to switch servers when there is a latency issue or when a site is broken. Can I safely use wg-quick down and wg-quick up without risk of a leak?
ALSO: Does anyone know what features are missing when you use mullvad this way? I know DAITA requires the mullvad gui, but is there anything else?
Browser side checks don’t reveal the complete picture. And in some cases, paint the wrong picture.
Android’s killswitch is under the control of the end-user. These are named “Always-on VPN” and “Block connections without VPN” (in English), and both must be turned ON for your VPN app, from Android’s VPN settings.
Note that, on Android (and on most OSes), some high privileged apps (mostly OEM and Google apps), which are typically pre- installed (some you can disable but none can you uninstall), do retain the capability to bypass the “killswitch”. A network monitor project I co-develop keeps track of such bypasses in AOSP here: Show Android components that can bypass VPN even in lockdown mode · Issue #224 · celzero/rethink-app · GitHub
And even if (hypothetically) AOSP never allowed such a bypass, the OEMs can change that behaviour for their Android distribution (unfortunately, as of Android 16, as part of its compatibility requirements, Google doesn’t enforce OEMs confirm to “Block connections without VPN” (ref / mirror).
Not quite sure, as it depends on the commands being run by wg-quick on up and down on your setup. Which setup guide are you using?
They’ve recently added “light weight” anti-censorship measures, too. That said, I consider custom features such as DAITA a form of lock-in. I’d not worry about it too much, if I were you.
thanks for your reply. your help on this forum is invaluable.
what is a better way to check for leaks?
i am using wireguard-tools installed on fedora workstation. then i followed the guide for mullvad cli wireguard setup.
Looks like their guide covers setting up “killswitch” (I haven’t personally reviewed it), so you should be okay exec’ing wg-quick up/down, if you’ve set that up as instructed.
Client-side tests; but these may involve either running tests others have written or authoring your own (even rudimentary tests are effective; like privsec.dev has done).