qdm12 / gluetun

VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.
https://hub.docker.com/r/qmcgaw/gluetun
MIT License
6.74k stars 333 forks source link

Bug: Mullvad+Wireguard DNS Leak without manually providing the DNS address provided by Mullvad #2023

Open inkwell84 opened 6 months ago

inkwell84 commented 6 months ago

Is this urgent?

None

Host OS

Synology

CPU arch

x86_64

VPN service provider

Mullvad

What are you using to run the container

Portainer

What is the version of Gluetun

latest

What's the problem πŸ€”

I installed Gluetun with latest build during last week of November. (Mullvad + Wireguard). I confirmed no DNS leaks by going to the Mullvad leak test web page using Firefox installed on docker and run through Gluetun. Today for the heck of it, I checked this again, and sure enough there was a DNS leak. I rebooted, still there. Went into the Gluetun support docs, found the instructions to manually provide a DNS address (-e DNS_ADDRESS), and inserted the DNS address provided by mullvad (with all the wireguard/server config infos). Voila. No longer a DNS leak.

I suggest adding the {-e DNS_ADDRESS= } instruction to the Mullvad basic setup page so other users will be able to avoid having an active DNS leak.

Thanks.

Share your logs (at least 10 lines)

Not needed, see my writeup for more info.

I installed Gluetun with latest build during last week of November. (Mullvad + Wireguard). I confirmed no DNS leaks by going to the Mullvad leak test web page using Firefox installed on docker and run through Gluetun. Today for the heck of it, I checked this again, and sure enough there was a DNS leak. I rebooted, still there. Went into the Gluetun support docs, found the instructions to manually provide a DNS address (-e DNS_ADDRESS), and inserted the DNS address provided by mullvad (with all the wireguard/server config infos). Voila. No longer a DNS leak.

I suggest adding the {-e DNS_ADDRESS= } instruction to the Mullvad basic setup page so other users will be able to avoid having an active DNS leak. 

Thanks.

Share your configuration

Not needed, see my writeup for more info.

I installed Gluetun with latest build during last week of November. (Mullvad + Wireguard). I confirmed no DNS leaks by going to the Mullvad leak test web page using Firefox installed on docker and run through Gluetun. Today for the heck of it, I checked this again, and sure enough there was a DNS leak. I rebooted, still there. Went into the Gluetun support docs, found the instructions to manually provide a DNS address (-e DNS_ADDRESS), and inserted the DNS address provided by mullvad (with all the wireguard/server config infos). Voila. No longer a DNS leak.

I suggest adding the {-e DNS_ADDRESS= } instruction to the Mullvad basic setup page so other users will be able to avoid having an active DNS leak. 

Thanks.
notDavid commented 6 months ago

Note that the other issue is, Mullvad blocks public DNS servers like 1.1.1.1 and 9.9.9.9, so if you set dot=on, you will have no DNS resolution either... (and i think this is also the default?).

qdm12 commented 6 months ago

@inkwell84 if you look in the details the "Leaking DNS servers" part of the Mullvad page, it should show Cloudflare DNS servers close to your VPN IP (not your ISP DNS server). Sure, your data goes (aka leaks) to Cloudflare DNS servers, but imo that's better than handing it to the VPN provider (mullvad or other):

Another test you can run is:

docker exec -it gluetun /bin/sh
# Pick a random number
x="$RANDOM"
wget -qO- "https://0.$x.bash.ws"
wget -qO- "https://bash.ws/dnsleak/test/$x?json"
exit

And that should log out only Cloudflare servers near your VPN server location.

Maybe a nice future addition to have this built-in Gluetun somehow πŸ€”

@notDavid

Mullvad blocks public DNS servers

It doesn't for me, I use the default DoT settings (Cloudflare) with Mullvad and it works fine πŸ€”

notDavid commented 6 months ago

It doesn't for me, I use the default DoT settings (Cloudflare) with Mullvad and it works fine πŸ€”

Odd. I'll do some testing and report back. EDIT: you're correct, it works... not sure what went wrong earlier.

Sure, your data goes (aka leaks) to Cloudflare DNS servers, but imo that's better than handing it to the VPN provider (mullvad or other)

Note that I strongly disagree; Mullvad can see all the IP addresses you connect to anyway, which already gives them 95% of the info even without the possibility of being able to log your DNS queries.

Now, you are giving away your DNS requests to a third party - one that is not as committed to privacy as Mullvad, and who's primary selling point is not privacy.

But foremost, i think that users should be made aware of this choice and decide this themselves instead of leaking by default.

inkwell84 commented 6 months ago

Agree with David on all points.

On Tue, Jan 2, 2024 at 02:30 David @.***> wrote:

It doesn't for me, I use the default DoT settings (Cloudflare) with Mullvad and it works fine πŸ€”

Odd. I'll do some testing and report back.

Sure, your data goes (aka leaks) to Cloudflare DNS servers, but imo that's better than handing it to the VPN provider (mullvad or other)

Note that I strongly disagree; Mullvad can see all the IP addresses you connect to anyway, which already gives them 95% of the info even without the possibility of being able to log your DNS queries.

Now, you are giving away your DNS requests to a third party - one that is not as committed to privacy as Mullvad, and who's primary selling point is not privacy.

But foremost, i think that users should be made aware of this choice and decide this themselves instead of leaking by default.

β€” Reply to this email directly, view it on GitHub https://github.com/qdm12/gluetun/issues/2023#issuecomment-1873691050, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMZ5V7P6NMC4OEBR6VFCD5DYMOZTBAVCNFSM6AAAAABBGDXPUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGY4TCMBVGA . You are receiving this because you were mentioned.Message ID: @.***>

Wheelz0 commented 4 months ago

@inkwell84 if you look in the details the "Leaking DNS servers" part of the Mullvad page, it should show Cloudflare DNS servers close to your VPN IP (not your ISP DNS server). Sure, your data goes (aka leaks) to Cloudflare DNS servers, but imo that's better than handing it to the VPN provider (mullvad or other):

* there is a large amount of users using public DNS servers like Cloudflare

* your origin is still hidden by the VPN IP

* A dns server like Cloudflare could theoretically store your VPN-IP + DNS queries

* Mullvad has your payment info + VPN-IP already, so handing them your DNS queries puts a lot of eggs in the same basket privacy/trust wise

Another test you can run is:

docker exec -it gluetun /bin/sh
# Pick a random number
x="$RANDOM"
wget -qO- "https://0.$x.bash.ws"
wget -qO- "https://bash.ws/dnsleak/test/$x?json"
exit

And that should log out only Cloudflare servers near your VPN server location.

Maybe a nice future addition to have this built-in Gluetun somehow πŸ€”

@notDavid

Mullvad blocks public DNS servers

It doesn't for me, I use the default DoT settings (Cloudflare) with Mullvad and it works fine πŸ€”

I am having the same issue and running that check just gives me my ISP's.

Solverz-0 commented 2 months ago

Note that I strongly disagree; Mullvad can see all the IP addresses you connect to anyway, which already gives them 95% of the info even without the possibility of being able to log your DNS queries.

Now, you are giving away your DNS requests to a third party - one that is not as committed to privacy as Mullvad, and who's primary selling point is not privacy.

But foremost, i think that users should be made aware of this choice and decide this themselves instead of leaking by default.

100% agree with this. You can "fix" this by setting DNS_ADDRESS to the VPN Servers DNS (if one is provided), but this will mean you are bypassing the local unbound server of this container sadly. I think being able to set DOT_PROVIDERS to custom IP Addresses is the correct solution in this case.