DNS leaks can't be solved.

[Ergus]

Hi:

I am using vopono to connect to protonvpn and I have tried everything but https://www.dnsleaktest.com/ shows my isp in spite of protonvpn has protection to prevent that. So it seems like vopono is not setting the dns in the namespace.

--dns option does not change the dns

and adding block-outside-dns to the .ovpn hangs when trying to connect.

When I use openvpn normally without vopono there is not any leak.

[jamesmcm]

Can you check the content of /etc/netns/NAMESPACENAME/resolv.conf when running?

I remember having issues with the ProtonVPN DNS when writing the sync code - https://github.com/jamesmcm/vopono/blob/master/src/providers/protonvpn/openvpn.rs#L39

[Ergus]

Hi:

The file content seems to be fine at least the values seems to be set, but I am not sure if they are fine...

With vopono I get:

But when using network Manager I get:

In this case I use the same server (Config nl-free-09.protonvpn.com.tcp.ovpn) but I get very different inets and subnets... Is this intended??

[jamesmcm]

That inet stuff is fine, and it seems alright using the internal DNS server (i.e. that will only be accessible within the tunnel).

Just to check if you run bash within the namespace and then run dig google.com for example - what DNS servers does it use?

[Ergus]

Interesting, bash seems to show the right dns server with dig... But dnsleaktest.com from firefox (from the namespace of course) still shows the one from my ISP. It is using the vpn because the ip is one from proton, not my public one but the Standard test shows the same than without the namespace.

OTOH I still tried to add block-outside-dns to the config and vopono hangs during startup.... So we are missing something here :(.

The hang happens in the call to start ip netns exec vopono_proton_japan openvpn --config /home/user/.config/vopono/proton/openvpn/japan-jp-free.ovpn --machine-readable-output --log /etc/netns/vopono_proton_japan/openvpn.log --auth-user-pass /home/user/.config/vopono/proton/openvpn/auth.txt

It uses the 100 of the cpu and I can't stop ip with C-c ... So I have to close the terminal. In that case the interface is not deleted and I have to remove it manually.

[jamesmcm]

Apparently block-outside-dns should only affect Windows clients anyway. It might be blocking on missing credentials?

In any case, can you try with Chromium or another browser? In case it's due to Firefox doing DNS over HTTPS or some other setting?

[Ergus]

Apparently block-outside-dns should only affect Windows clients anyway. It might be blocking on missing credentials?

But in any case it shouldn't block vopono right?

In any case, can you try with Chromium or another browser?

I just tried Chromium and midori with exactly the same result: right ip wrong dns in the test.

In case it's due to Firefox doing DNS over HTTPS or some other setting?

I actually disabled DNS over HTTPS on firefox; same result. And also tried with private windows (just in case)

[jamesmcm]

I just tested this with the Japan free OpenVPN server and it worked fine for me with google-chrome-stable:

[Ergus]

I just tested this with the Japan free OpenVPN server and it worked fine for me with google-chrome-stable:

Hi is this from proton? or someone else?

If it is a proton one. Did you do anything special? Because I can't solve this. I have the same issue with any browser I use except lyx and elinks. So maybe there is something wrong in my environment?? Something that should be documented maybe?

[jamesmcm]

Yeah, I just used vopono sync, chose the free one and logged in. Then ran google-chrome-stable with vopono.

Maybe try to check if anything is overriding the DNS somehow?

[Ergus]

Yeah, I just used vopono sync, chose the free one and logged in. Then ran google-chrome-stable with vopono.

Maybe try to check if anything is overriding the DNS somehow?

I just tried with google-chrome-stable and I have the same result. I am starting to think that maybe this is related with networkmanager?

Are you using networkmanager??

[Ergus]

I found another hint. I rebooted the system to an old debian installation and there vopono seems to work very fine and there are not dns leaks....

The debian installation uses the same environment I have (i3wm+networkmanager and even the same .bashrc and all home files .) so maybe this has nothing to do with network manager. The only difference is the os (Debian vs Arch). So probably there is something in arch that makes the gui applications to bypass the terminal environment during dns search for requests...

[jamesmcm]

It's strange, I use NetworkManager myself, and have openresolv installed but it's not an issue at all.

I don't see anything weird on the Wiki page either - https://wiki.archlinux.org/title/Domain_name_resolution

[Ergus]

I had systemd-resolvconf but I just switched to openresolv, restarted and the issue is still there... I ran out of ideas

[Ergus]

BTW In firefox I tried about:networking#dns but there is not info about how firefox searches for a DNS either

[ghost]

I'm experiencing the same issue with mullvad.

However only with Firefox. No issue when I use dig to check which DNS server I'm using.

[fosspill]

I'm having this issue as well. Both with ungoogled-chromium and firefox. If I use the config files and connect with wg myself it works fine, however.

[niki-on-github]

Maybe it has something to do with the nsswitch.conf setting. See dns-leaks-with-network-namespaces. Since vopono does not generate a custom nsswitch.conf config the default file will be used. Depending on the configuration of the distributions this could maybe cause such problems.

[jamesmcm]

Thanks, I can try to test it by switching to systemd-resolved.

[jamesmcm]

If you're using systemd-resolved, it'd be great if you could try vopono 0.9.0 now thanks to PR #144 from @niki-on-github

[masaeedu]

For posterity (in case this debugging information ever gets turned into a FAQ) the issue in my case turned out to be a running instance of nscd, as suggested in the excellent Stack Exchange answer here:

nscd

If you are not using systemd-resolved, there is one other way in which glibc may apparently ignore your /etc/resolv.conf and /etc/nsswitch.conf setup. This is when nscd is running. glibc will try to reach nscd at /var/run/nscd/socket before it starts loading NSS modules. In NixOS, this is used to avoid needing to pollute the global state configuration of NSS modules into the direct runtime environment of every process; it relies on nscd loading all of the NSS modules and other processes resolving via nscd. In some other systems, nscd may be used to provide caching of resolution.

There are several workarounds:

1. You can unshare the filesystem namespace and bind mount something, e.g. /var/empty, over /var/run/nscd. This will disable nscd for just one process. Note that this has to be done separately from the netns configuration; it will not persist merely by calling ip netns exec.

2. You can use firejail to leverage the power of seccomp-bpf to disallow access to /var/run/nscd/socket. This might look something like this:

   firejail --noprofile --blacklist=/var/run/nscd/socket --netns=${NAMESPACE} --dns=${NAMESERVER} [command]
   
   

3. In many cases, you can just disable nscd globally, as it is not generally needed. This is not generally recommended on NixOS, but is reasonable on most Linux based operating systems.

For my purposes I just turned off nscd, ~~and I suspect (but have not confirmed) that these days this workaround is acceptable even for people using NixOS~~ (see edit below). If not, it might be necessary to do the unshare FS namespace + replace /var/run/nscd gymnastics proposed in solution 1.

EDIT: It turns out I was wrong, nscd is still essential for for Nix-based tools to be able to resolve mDNS queries. See output below:

~ via 🐍 v3.10.12
❯ sudo systemctl stop nscd

~ via 🐍 v3.10.12
❯ # try resolving with normal getent

~ via 🐍 v3.10.12
❯ getent hosts xyz.local
192.168.1.105   xyz.local

~ via 🐍 v3.10.12
❯ # try resolving with nixpkgs getent

~ via 🐍 v3.10.12
❯ , getent hosts xyz.local
Warning: Nix-index database is older than 30 days, either obtain a prebuilt database from https://github.com/Mic92/nix-index-database or try updating with `nix run 'nixpkgs#nix-index' --extra-experimental-features 'nix-command flakes'`.

~ via 🐍 v3.10.12 took 2s
❯ echo $?
2

~ via 🐍 v3.10.12
❯ systemctl start nscd

~ via 🐍 v3.10.12 took 8s
❯ , getent hosts xyz.local
Warning: Nix-index database is older than 30 days, either obtain a prebuilt database from https://github.com/Mic92/nix-index-database or try updating with `nix run 'nixpkgs#nix-index' --extra-experimental-features 'nix-command flakes'`.
192.168.1.105   xyz.local

So I guess I need to go back to running nscd (or their new and improved nsncd) on the host system but simultaneously obscure it within the namespace created by vopono.