Local dns server gets precedence over the vpn dns server
sum32 opened this issue · 8 comments
My issue is that the vpn provided dns server is not always used while I am on the vpn.
I use this vpn client settings
setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
dhcp-option DOMAIN-ROUTE .
/etc/resolv.conf: symbolic link to /run/systemd/resolve/stub-resolv.conf
When I start openvpn it is almost perfect:
cat /etc/resolv.conf:
nameserver 192.168.0.1
nameserver 10.8.0.1
search lan
I just want nameserver 192.168.0.1 and search lan to disappear while using vpn and then come back when turn it of. Could this be achieved by this tool?
One example which would go through the 192.168.0.1 is if I run "host something.com"
however, browsing and using curl for unknown domains seams to go through the 10.8.0.1 server somehow. Thanks!
--------------------- EDIT
Also, I do not have network manager or anything fancy just systemd-networkd and systemd-resolved with this interface config:
cat /etc/systemd/network/20-wired.network
[Match]
Name=eth0
[Network]
DHCP=yes
[DHCP]
RouteMetric=10
Can confirm... this does not set the default DNS server, it only adds the VPN DNS server as a secondary.
@sum32 @ehidle
What OS, what version of systemd, what is the output of resolvectl status (or systemd-resolve --status) when vpn is up? See https://unix.stackexchange.com/q/328131/5355
@piotr-dobrogost resolvectl status shows the ATT router as still being the DNS server. This is on Ubuntu 20.04 with systemd 245.
@ehidle Could you please paste the complete output of the command?
@ehidle Could you please paste the complete output of the command?
resolvectl status:
https://paste.ubuntu.com/p/nwtGJxNvhx/
resolv.conf:
https://paste.ubuntu.com/p/P7cpQtZwmf/
example CLI nslookup showing incorrect server being used:
Can confirm... this does not set the default DNS server, it only adds the VPN DNS server as a secondary.
Well, with systemd-resolved there's no such thing as the default DNS server at least not in the sense of global DNS servers listed in the /etc/resolv.conf. The whole idea is to be able to have DNS servers defined per interface and decide DNS servers on what interface(s) should be used to resolve each DNS query. The logic for deciding this – called routing – is described at https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
There we read
In order to preferably route all DNS queries not explicitly matched by routing domain configuration to a specific link, configure a "~." route-only domain on it.
and as visible in the result of resolvectl status the script did its work right as there's DNS Domain: ~. set on VPN's interface (tun0). The problem comes from the fact that this special route-only domain is also set on another interface (enp5s0). So according to this statement
This will ensure that other links will not be considered for these queries (unless they too carry such a routing domain). (emphasis mine)
DNS queries are being sent to DNS servers specified for both interfaces.
The issue of "~." domain being erroneously set for interface other than VPN is a well-known quirk of Network Manager which was fixed in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/687
For many examples of various VPN tools failing to configure systemd-resoved properly (to avoid leaking DNS requests outside of VPN tunnel) see systemd/systemd#6076
I just want nameserver 192.168.0.1 and search lan to disappear while using vpn and then come back when turn it of. Could this be achieved by this tool?
This is currently outside update-systemd-resolved's scope. However, you could implement your own up and down scripts that do what you describe (and also call out to update-systemd-resolved, as AFAIK OpenVPN only supports specifying a single up or down script).
Future work on update-systemd-resolved may include support for user-specific hook scripts/actions that could be used for the needs you describe.
NetworkManager release 1.26.6 contains a fix for the wildcard-routing-domain-on-all-interfaces issue.
If you are using NetworkManager, suggest you update to 1.26.6 or above. If you aren't using NetworkManager, or if the problem persists, please reopen this issue.