[BUG] DNS leaking with systemd-resolved about linux-cli-community HOT 7 OPEN

Hey Rafficer, thanks for taking the time to look into this and verify that openvpn-systemd-resolved causes the issue.

Progress

After further research, I found that it more specifically involves the libnss-resolve (alias for libnss-systemd) package which openvpn-systemd-resolve depends on. Upon installation, it makes the following file change:

# /etc/nsswitch.conf
< hosts:          files mdns4_minimal [NOTFOUND=return] dns
---
> hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

Reverting the change to remove resolve [!UNAVAIL=return] and restarting the systemd-resolved service can prevent DNS leaks. Here's a rough outline of the steps I've tried.

1. Install ProtonVPN and prereqs. Do protonvpn init.
2. sudo apt install openvpn-systemd-resolve. This installs libnss-resolve/libnss-systemd too.
3. sudo protonvpn c -f
4. Go to dnsleaktest.com. DNS requests should be leaking.
5. sudo protonvpn d
6. Edit /etc/nsswitch.conf as shown above, removing resolve resolve [!UNAVAIL=return].
7. sudo systemctl restart systemd-resolved
8. sudo protonvpn c -f
9. Go back to dnsleaktest.com. DNS requests should no longer be leaking.
10. sudo protonvpn d
11. Restore /etc/nsswitch.conf file to original config.
12. sudo systemctl restart systemd-resolved

Unfortunately, I've had mixed success with this. Sometimes DNS leaks after removing the nsswitch section, sometimes it doesn't. More digging needs to be done, but I hope this is at least a start.

Arguments for systemd-resolved support

1. It is common for users of OpenVPN to have the openvpn-systemd-resolved package installed to work with their own personal OpenVPN setups. Otherwise, DNS wouldn't work at all. As this is a common configuration for Ubuntu users, I believe the PVPN CLI should support it.
2. Common configuration or not, DNS Leak Protection is an option that the PVPN CLI provides. If I took the CLI at its word, I wouldn't know that my DNS queries were leaking anyway. It should at least detect this unsupported configuration and warn the user that DNS Leak Protection may not be effective. Even better, the CLI could run its own leak test after connecting.
3. ProtonVPN is a major VPN provider and among the higher priced players. Granted, it does have the infrastructure and Windows/macOS/Android/iOS clients to match; support for other platforms is phenominal, but most Linux users can manage with a CLI only. I'd be surprised if ProtonVPN didn't have the resources to make a desktop client for the most commonly used privacy-conscous platform. I admire the amount of work and attention to detail you've put into making this CLI tool. Despite the couple of bugs here and there, it's incredible! But you shouldn't have to do this alone. IMO, an important application such as this should be backed up by at least a small team. Surely there is someone at ProtonVPN that can offer some insight into this sytemd-resolved issue.

There is a mass exodus of users looking to switch away from another major VPN provider, so now may be a good time for the folks at ProtonVPN to step on the gas for Linux support, one of the things the competitor -- to its credit -- does well. I'm new to ProtonVPN and trying a couple of other services too. ProtonVPN stands out as my favorite with the exception of this DNS leak issue.

Again, thanks so much for all of the hard work you've put into this! I hope my findings and comments are helpful to you.

from linux-cli-community.

I tried this on a fresh install and the issue isn't present there. I'm not quite sure what I'm doing differently. 😔

Update: The difference seems to be the presence of the openvpn-systemd-resolved package.

from linux-cli-community.

Thanks for this extensive explanation. I can also only replicate this with the openvpn-systemd-resolved package installed. I assume this gets installed by the other VPN clients?

As ProtonVPN-CLI doesn't require to have systemd installed, I'm not sure if this should be handled in the program. I'm also not sure how to properly handle this. As a default installation doesn't experience this, I don't think it's right to work around the errors introduced by another package.

from linux-cli-community.

I also toyed with adding a few lines to the template.ovpn file, but didn't get too far. Feels closer, though.

script-security 2
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
down-pre
dhcp-option DOMAIN-ROUTE .

Checking systemd-resolve --status, I now have DNS Domain: ~. on the physical and tun0 interfaces. Not sure how to prioritize tun0.

from linux-cli-community.

Hey Rafficer, thanks for taking the time to look into this and verify that openvpn-systemd-resolved causes the issue.

Progress

After further research, I found that it more specifically involves the libnss-resolve (alias for libnss-systemd) package which openvpn-systemd-resolve depends on. Upon installation, it makes the following file change:

# /etc/nsswitch.conf
< hosts:          files mdns4_minimal [NOTFOUND=return] dns
---
> hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

Reverting the change to remove resolve [!UNAVAIL=return] and restarting the systemd-resolved service can prevent DNS leaks. Here's a rough outline of the steps I've tried.

1. Install ProtonVPN and prereqs. Do `protonvpn init`.

2. `sudo apt install openvpn-systemd-resolve`. This installs `libnss-resolve`/`libnss-systemd` too.

3. `sudo protonvpn c -f`

4. Go to dnsleaktest.com. DNS requests should be leaking.

5. `sudo protonvpn d`

6. Edit `/etc/nsswitch.conf` as shown above, removing resolve `resolve [!UNAVAIL=return]`.

7. `sudo systemctl restart systemd-resolved`

8. `sudo protonvpn c -f`

9. Go back to dnsleaktest.com. DNS requests should no longer be leaking.

10. `sudo protonvpn d`

11. Restore `/etc/nsswitch.conf` file to original config.

12. `sudo systemctl restart systemd-resolved`

Unfortunately, I've had mixed success with this. Sometimes DNS leaks after removing the nsswitch section, sometimes it doesn't. More digging needs to be done, but I hope this is at least a start.

Arguments for systemd-resolved support

1. It is [common](https://askubuntu.com/questions/1032476/ubuntu-18-04-no-dns-resolution-when-connected-to-openvpn) for users of OpenVPN to have the `openvpn-systemd-resolved` package installed to work with their own personal OpenVPN setups. Otherwise, DNS wouldn't work at all. As this is a common configuration for Ubuntu users, I believe the PVPN CLI should support it.

2. Common configuration or not, DNS Leak Protection is an option that the PVPN CLI provides. If I took the CLI at its word, I wouldn't know that my DNS queries were leaking anyway. It should at least detect this unsupported configuration and warn the user that DNS Leak Protection may not be effective. Even better, the CLI could run its own leak test after connecting.

3. ProtonVPN is a major VPN provider and among the higher priced players. Granted, it does have the infrastructure and Windows/macOS/Android/iOS clients to match; support for other platforms is phenominal, but most Linux users can manage with a CLI only. I'd be surprised if ProtonVPN didn't have the resources to make a desktop client for the most commonly used privacy-conscous platform. I admire the amount of work and attention to detail you've put into making this CLI tool. Despite the couple of bugs here and there, it's incredible! But you shouldn't have to do this alone. IMO, an important application such as this should be backed up by at least a small team. Surely there is someone at ProtonVPN that can offer some insight into this sytemd-resolved issue.

There is a mass exodus of users looking to switch away from another major VPN provider, so now may be a good time for the folks at ProtonVPN to step on the gas for Linux support, one of the things the competitor -- to its credit -- does well. I'm new to ProtonVPN and trying a couple of other services too. ProtonVPN stands out as my favorite with the exception of this DNS leak issue.

Again, thanks so much for all of the hard work you've put into this! I hope my findings and comments are helpful to you.

I am also facing this issue and this workaround seems to have fixed it for me too. Since this ticket is almost a year old, is there any update on this?

from linux-cli-community.

The Linux clients are currently being rewriten, so no new commits will be made to fix this.

from linux-cli-community.

The Linux clients are currently being rewriten, so no new commits will be made to fix this.

The new linux beta-client does not support headless servers.
Untill it does, we still need to use this client.

Unless Im mistaken, is it not possible to use NetworkManager on a headless server setup?

It wasnt untill i started working on a different bug, that I realised my DNS queries were going to my ISP DNS, via enp0s10.

The client said i had "DNS Leak Protection".. I took it at its word.
I am paying for a VPN with DNS leak protection.
systemd-resolved users are not getting this, and this bug has been known about for quite some time.

Im really sorry to say, that I shall be looking for a new VPN provider.

from linux-cli-community.