update-systemd-resolved icon indicating copy to clipboard operation
update-systemd-resolved copied to clipboard

Ubuntu 20.04 - DNS pushed by the ovpn server shown in status, but not reflecting in resolv.conf

Open vishnus opened this issue 5 years ago • 6 comments

Hi there,

The ovpn server's DNS push is reflecting fine in systemd-resolved --status:

`Link 17 (tun0)
      Current Scopes: DNS        
DefaultRoute setting: yes        
       LLMNR setting: yes        
MulticastDNS setting: no         
  DNSOverTLS setting: no         
      DNSSEC setting: no         
    DNSSEC supported: no         
  Current DNS Server: 192.168.0.2
         DNS Servers: 192.168.0.2

Link 3 (enx8c04ba783dde)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

Link 2 (wlo1)
      Current Scopes: DNS    
DefaultRoute setting: yes    
       LLMNR setting: yes    
MulticastDNS setting: no     
  DNSOverTLS setting: no     
      DNSSEC setting: no     
    DNSSEC supported: no     
  Current DNS Server: 1.1.1.1
         DNS Servers: 1.1.1.1
          DNS Domain: ~.`

But the /etc/resolv.conf still shows only 127.0.0.53. and dig to an internal domain doesnt work.

Symlink is to stub-resolv.conf: /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

I've disabled the dns in NetworkManager.conf also, and set the vpn's dns priority as -42. Still doesnt seem to work.

Finally I disabled systemd-resolved service and switched to coredns, but then the connection itself is failing with this error: WARNING: Failed running command (--up/--down): external program exited with error status: 1 Exiting due to fatal error

How can we solve this in Ubuntu 20.04 without having to disable this service? What could be the issue here?

vishnus avatar May 17 '20 12:05 vishnus

I think the issue is different. The problem for me is that the tun0 DNS does not have

DNS Domain: ~.`

and so it is not used. If you try to connect via NetworkManager, then the DNS Doman of the tunnel is set. I am not sure how it works, but it makes it the "default" or something similar.

This script sets the DNS for the tunnel, but does not make them the default.

audetto avatar Jun 04 '20 07:06 audetto

I also have trouble getting this working with 20.04.

mihneadb avatar Jun 16 '20 14:06 mihneadb

If you try to connect via NetworkManager, then the DNS Doman of the tunnel is set. I am not sure how it works, but it makes it the "default" or something similar.

This is the effect of not checking “Use this connection only for resources on its network” option for VPN link in NetworkManager. For more details see https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/

This script sets the DNS for the tunnel, but does not make them the default.

To make it the default you have to add the following line to your .ovpn config file for vpn:

dhcp-option DOMAIN-ROUTE .

However, the same might be already set for other links in which case DNS queries would be send to all DNS servers specified for links with this setting. See https://github.com/jonathanio/update-systemd-resolved/issues/59 for a script removing ~. from all other links to make sure all DNS queries are being routed through VPN link only.

piotr-dobrogost avatar Oct 18 '20 18:10 piotr-dobrogost

OpenVPN does not support dhcp-option DOMAIN-ROUTE

TinCanTech avatar Oct 19 '20 00:10 TinCanTech

@TinCanTech Why do you think so? See https://github.com/jonathanio/update-systemd-resolved/issues/28

piotr-dobrogost avatar Oct 19 '20 08:10 piotr-dobrogost

Openvpn --dhcp-option is primarily intended for Windows. However .. It turns out that OpenVPN for Windows does not allow dhcp-option DOMAIN-ROUTE OpenVPN for Linux does not check the option strings in use and will allow anything. eg. dhcp-option PHEASANT PLUCKER .. So I guess you can use anything as a --dhcp-option so long as you do not use Windows -- Until today, I was unaware of this difference in behaviour -- So, Hack away!

TinCanTech avatar Oct 19 '20 14:10 TinCanTech

@vishnus @audetto @mihneadb -- does the tip about DOMAIN-ROUTE and/or the NetworkManager script from #59 address your issues?

tomeon avatar Jul 22 '23 14:07 tomeon

NetworkManager release 1.26.6 no longer assigns the ~. routing domain to all managed interfaces (see its NEWS file).

Closing this issue; please reopen if upgrading NetworkManager and/or setting dhcp-option DOMAIN-ROUTE . does not solve the problem.

tomeon avatar Sep 08 '23 13:09 tomeon