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

[vishnus]

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?

[audetto]

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.

[mihneadb]

I also have trouble getting this working with 20.04.

[piotr-dobrogost]

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 #59 for a script removing ~. from all other links to make sure all DNS queries are being routed through VPN link only.

[TinCanTech]

OpenVPN does not support dhcp-option DOMAIN-ROUTE

[piotr-dobrogost]

@TinCanTech
Why do you think so? See #28

[TinCanTech]

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!

[tomeon]

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

[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.