Skip to main content
Ask Ubuntu

Return to Question

Edited to answer questions by mpboden
Source Link
UbuntuUser
UbuntuUser
  • 287
  • 1
  • 4
  • 13

Regarding that use-vc option, for some reason when I read the details on that I saw TCP and read TLS, so that explains why it didn't work. TCP and TLS aren't the same thing but when you have researched something long enough, with no results, small distinctions like that start to blur!

Regarding that use-vc option, for some reason when I read the details on that I saw TCP and read TLS, so that explains why it didn't work. TCP and TLS aren't the same thing but when you have researched something long enough, with no results, small distinctions like that start to blur!

Edited to answer questions by mpboden
Source Link
UbuntuUser
UbuntuUser
  • 287
  • 1
  • 4
  • 13

EDIT to answer questions asked - I went back to using the static resolv.conf because it was the only way I could be certain traffic would go out the VPN but as noted above DNS requests are going out on port 53. not port 853. With that in mind, this is the output of resolvectl status:

Global
       Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
     DNS Servers: 9.9.9.9 149.112.112.112 1.1.1.1 1.0.0.1

Link 2 (enp0s10)
Current Scopes: DNS
     Protocols: +DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 192.168.1.1
    DNS Domain: localdomain

Link 3 (tun0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

Link 4 (wlp5s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

This is the output of ip a (with MAC addresses redacted):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.120/24 metric 100 brd 192.168.1.255 scope global dynamic enp0s10
       valid_lft 6592sec preferred_lft 6592sec
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet 10.12.216.2/24 scope global tun0
       valid_lft forever preferred_lft forever
4: wlp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

I am not certain about netplan or systemd, but I ASSUME netplan because there is a file /etc/netplan/00-installer-config.yaml which contains the following:

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s10:
      dhcp4: true
  version: 2

However please remember what I said about resolv.conf being made into a static file.

The VPN is OpenVPN, it connects to an OpenVPN server at a distant location. To make it work I have to run this at every startup:

/usr/sbin/openvpn --client --config /etc/openvpn/client/xBuQqzYnLLTezXRvrOofMBGgYAEgcY.ovpn

For security reasons I don't really want to post that entire .ovpn file and I am not sure it would be helpful anyway, but here is the top part with some redactions:

client
dev tun
proto udp
remote (redacted)
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name (redacted)
cipher AES-256-CBC
auth SHA256
auth-nocache
askpass (redacted)
verb 3
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
redirect-gateway
dhcp-option DNS 10.12.216.2

After that are the various keys and certificates.

I really don't think the issue is in the .ovpn configuration, I think it is that if you use the default symlinked resolv.conf it tries to go to the router first (192.168.1.1). In case you are wondering what that version of resolv.conf looks like, it is

nameserver 127.0.0.53
options edns0 trust-ad
search localdomain

Which I believe is the default on all Ubuntu versions. Now what exactly 127.0.0.53 is I am not sure, I gather it is some kind of local DNS server or maybe a proxy or something, but all I do know is that it tries the router's DNS server first and that is exactly what I don't want happening.

EDIT to answer questions asked - I went back to using the static resolv.conf because it was the only way I could be certain traffic would go out the VPN but as noted above DNS requests are going out on port 53. not port 853. With that in mind, this is the output of resolvectl status:

Global
       Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
     DNS Servers: 9.9.9.9 149.112.112.112 1.1.1.1 1.0.0.1

Link 2 (enp0s10)
Current Scopes: DNS
     Protocols: +DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 192.168.1.1
    DNS Domain: localdomain

Link 3 (tun0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

Link 4 (wlp5s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

This is the output of ip a (with MAC addresses redacted):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.120/24 metric 100 brd 192.168.1.255 scope global dynamic enp0s10
       valid_lft 6592sec preferred_lft 6592sec
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet 10.12.216.2/24 scope global tun0
       valid_lft forever preferred_lft forever
4: wlp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

I am not certain about netplan or systemd, but I ASSUME netplan because there is a file /etc/netplan/00-installer-config.yaml which contains the following:

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s10:
      dhcp4: true
  version: 2

However please remember what I said about resolv.conf being made into a static file.

The VPN is OpenVPN, it connects to an OpenVPN server at a distant location. To make it work I have to run this at every startup:

/usr/sbin/openvpn --client --config /etc/openvpn/client/xBuQqzYnLLTezXRvrOofMBGgYAEgcY.ovpn

For security reasons I don't really want to post that entire .ovpn file and I am not sure it would be helpful anyway, but here is the top part with some redactions:

client
dev tun
proto udp
remote (redacted)
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name (redacted)
cipher AES-256-CBC
auth SHA256
auth-nocache
askpass (redacted)
verb 3
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
redirect-gateway
dhcp-option DNS 10.12.216.2

After that are the various keys and certificates.

I really don't think the issue is in the .ovpn configuration, I think it is that if you use the default symlinked resolv.conf it tries to go to the router first (192.168.1.1). In case you are wondering what that version of resolv.conf looks like, it is

nameserver 127.0.0.53
options edns0 trust-ad
search localdomain

Which I believe is the default on all Ubuntu versions. Now what exactly 127.0.0.53 is I am not sure, I gather it is some kind of local DNS server or maybe a proxy or something, but all I do know is that it tries the router's DNS server first and that is exactly what I don't want happening.

Source Link
UbuntuUser
UbuntuUser
  • 287
  • 1
  • 4
  • 13

How can I force Ubuntu 22.04 SERVER to use ONLY the DNS servers listed in /etc/systemd/resolved.conf (NOT my router's DNS) AND use DNS-over-TLS?

I have added these lines to /etc/systemd/resolved.conf in a Ubuntu 22.04 SERVER install with NO DESKTOP - I emphasize that because I can't use the normal desktop method of setting network options in Ubuntu:

DNS=9.9.9.9 149.112.112.112 1.1.1.1 1.0.0.1
DNSOverTLS=yes

This works fine EXCEPT that all connections are supposed to be going through a VPN tunnel which is identified as tun0. So with the above configuration in place, if I do

sudo tcpdump -ni tun0 -p port 53 or port 853

in one terminal window and try to ping google.com from the other, I see several requests but they are all going out on port 853. Great, so DNS-over-TLS is working. The problem is that if instead I run

sudo tcpdump -ni enp0s10 -p port 53 or port 853

I see lines showing that it is also trying to go to my router at 192.168.1.1, still trying to use port 853 but it looks like it makes four attempts to go there. This is NOT great. I don't want it trying to use my router's DNS, all that traffic should be going through the tunnel.

I tried an alternate approach which was to temporarily rename /etc/resolv.conf (which is a symlink to somewhere else) and replaced it with a version that is an actual text file (not a symlink) in which I put these lines:

nameserver 9.9.9.9
nameserver 149.112.112.112
nameserver 1.1.1.1
options use-vc edns0 trust-ad
search localdomain

Other than the nameserver links the only thing I changed was adding "use-vc" in the options line because I read that was SUPPOSED to enable DNS-over-TLS. When I do that I get no traffic going to the local network interface when I do a DNS request, BUT the requests go out tun0 using port 53, not port 853, so then it is NOT using DNS-over-TLS. So the use-vc option is not being honored.

I have been reading pages for the last five hours and I can't find a solution to this, primarily because most pages on the subject either assume you are running a desktop version of Ubuntu or they appear to be for different versions of Ubuntu where things are done a little differently. How can I make it so DNS requests only go out tun0, but still use DNS-over-TLS?