DNS server falling back to tethered connection for no apparent reason

voxell · 2024-11-04 23:51:41

I've been using 1.1.1.1 and 8.8.8.8 as my DNS literally everywhere, but after some time of use it falls back to the tethered connection:

Last time I solved this by modifying the nmcli connection dns parameter then rebooting the computer, but for some reason it happened again after some time of use.

❯ ping discord.com
PING discord.com (195.175.254.2) 56(84) bytes of data.
From 195.175.254.2.static.turktelekom.com.tr (195.175.254.2) icmp_seq=1 Destination Port Unreachable
From 195.175.254.2.static.turktelekom.com.tr (195.175.254.2) icmp_seq=2 Destination Port Unreachable
From 195.175.254.2.static.turktelekom.com.tr (195.175.254.2) icmp_seq=3 Destination Port Unreachable
From 195.175.254.2.static.turktelekom.com.tr (195.175.254.2) icmp_seq=4 Destination Port Unreachable

^ this is not the output of a 1.1.1.1 or 8.8.8.8 DNS.

any help troubleshooting this?

$ resolvectl
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
  Current DNS Server: 8.8.8.8
         DNS Servers: 1.1.1.1 8.8.8.8
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google

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

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

Link 4 (enp5s0f3u1)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 8.8.8.8

$ ip a
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
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 8c:8c:aa:e1:80:bd brd ff:ff:ff:ff:ff:ff
    altname enp3s0
3: wlp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b6:56:5f:d1:28:bc brd ff:ff:ff:ff:ff:ff permaddr d8:f3:bc:ba:da:41
4: enp5s0f3u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether c2:1b:b9:41:3d:2e brd ff:ff:ff:ff:ff:ff
    inet 192.168.169.27/24 brd 192.168.169.255 scope global dynamic noprefixroute enp5s0f3u1
       valid_lft 1848sec preferred_lft 1848sec
    inet6 fe80::1fab:9ae9:d3d:3992/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

$ ip r
default via 192.168.169.55 dev enp5s0f3u1 proto dhcp src 192.168.169.27 metric 100
192.168.169.0/24 dev enp5s0f3u1 proto kernel scope link src 192.168.169.27 metric 100

Last edited by voxell (2024-11-04 23:54:41)

Strike0 · 2024-11-05 07:02:14

There may be two reasons: 1. the tethered dhcp gets refreshed and with it the dns of it gets added. 2. The dns gets intercepted by the router.

Are you still using networkmanager? If yes, see example 12 of https://man.archlinux.org/man/nmcli-examples.7.en how to troubleshoot (1) before/after it happens.
For (2) the route is to use encrypted dns. There are different methods, one being a vpn configured to discard dhcp dns. For browsing another is to use a webbrowser that allows overriding dns-settings (chromeedit: chromium and firefox have options for it). Simple test: when it happens, activate dns in the browser accordingly, restart it and try discord again.

Last edited by Strike0 (2024-11-05 07:12:17)

mithrial · 2024-11-05 07:09:44

Your ISP probably does something nefarious to maybe block access or redirect requests to these public DNS servers.
The response IP is not for discord.

You could try Dns-over-tls which can't be hijacked, although it could be denied like China does.

Last edited by mithrial (2024-11-05 07:10:34)

-thc · 2024-11-05 08:49:50

Let's check the basics first.

This line

resolv.conf mode: foreign

should read "stub" instead. Did you tamper with the symbolic link ("/etc/resolv.conf") or the file ("/run/systemd/resolve/stub-resolv.conf")?

voxell · 2024-11-05 12:09:22

-thc wrote:

Let's check the basics first.
This line
resolv.conf mode: foreign
should read "stub" instead. Did you tamper with the symbolic link ("/etc/resolv.conf") or the file ("/run/systemd/resolve/stub-resolv.conf")?

i remember trying to get internet working on the installation, i've come across that symlink and read that it is indeed a symlink and should not be tampered. i dont think i tampered with it but lets proceed as if i did.

voxell · 2024-11-05 12:10:24

Strike0 wrote:

There may be two reasons: 1. the tethered dhcp gets refreshed and with it the dns of it gets added. 2. The dns gets intercepted by the router.
Are you still using networkmanager? If yes, see example 12 of https://man.archlinux.org/man/nmcli-examples.7.en how to troubleshoot (1) before/after it happens.
For (2) the route is to use encrypted dns. There are different methods, one being a vpn configured to discard dhcp dns. For browsing another is to use a webbrowser that allows overriding dns-settings (chromeedit: chromium and firefox have options for it). Simple test: when it happens, activate dns in the browser accordingly, restart it and try discord again.

I'd like all my connections, including dns would go through the vpn.

mithrial · 2024-11-05 12:15:22

Does your VPN support this? Some are configured that only specific IPs are routed through the VPN and others not (Split-VPN). Could that be something?

Otherwise, you have to give more information about your networking setup.

You can revert the resolv.conf to the stub resolver with

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

voxell · 2024-11-05 12:24:21

mithrial wrote:

Does your VPN support this? Some are configured that only specific IPs are routed through the VPN and others not (Split-VPN). Could that be something?
Otherwise, you have to give more information about your networking setup.
You can revert the resolv.conf to the stub resolver with
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

How exactly can I look up whether my VPN supports this? I am using ProtonVPN TCP with openvpn.

-thc · 2024-11-05 12:29:19

voxell wrote:

i've come across that symlink and read that it is indeed a symlink and should not be tampered. i dont think i tampered with it but lets proceed as if i did.

Post the directory listing and the contents:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

voxell · 2024-11-05 12:30:48

-thc wrote:

voxell wrote:
i've come across that symlink and read that it is indeed a symlink and should not be tampered. i dont think i tampered with it but lets proceed as if i did.
Post the directory listing and the contents:
ls -l /etc/resolv.conf
cat /etc/resolv.conf

I recovered the symlink using the ln -sf command above

❯ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 37 Nov  5 15:17 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
❯ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

It used to say:

# Generated by NetworkManager
nameserver 1.1.1.1
nameserver 8.8.8.8

Last edited by voxell (2024-11-05 12:32:46)

voxell · 2024-11-05 12:33:58

voxell wrote:

mithrial wrote:
Does your VPN support this? Some are configured that only specific IPs are routed through the VPN and others not (Split-VPN). Could that be something?
Otherwise, you have to give more information about your networking setup.
You can revert the resolv.conf to the stub resolver with
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
How exactly can I look up whether my VPN supports this? I am using ProtonVPN TCP with openvpn.

quote from the official protonvpn website https://protonvpn.com/support/dns-leaks-privacy:

All Proton VPN apps include DNS leak protection designed to prevent websites and the like that you visit on the internet from identifying your real DNS address.

Last edited by voxell (2024-11-05 12:34:11)

-thc · 2024-11-05 12:36:06

voxell wrote:

It used to say:

# Generated by NetworkManager
nameserver 1.1.1.1
nameserver 8.8.8.8

Tell NetworkManager to leave /etc/resolv.conf alone - create a drop-in file under "/etc/NetworkManager/conf.d":

# dns.conf
[main]
dns=systemd-resolved

-thc · 2024-11-05 12:43:08

voxell wrote:

quote from the official protonvpn website https://protonvpn.com/support/dns-leaks-privacy:
All Proton VPN apps include DNS leak protection designed to prevent websites and the like that you visit on the internet from identifying your real DNS address.

This is just sales pitch talk and concerns ProtonVPN's own apps.

How do you connect to your VPN?

voxell · 2024-11-05 12:52:13

-thc wrote:

voxell wrote:
quote from the official protonvpn website https://protonvpn.com/support/dns-leaks-privacy:
All Proton VPN apps include DNS leak protection designed to prevent websites and the like that you visit on the internet from identifying your real DNS address.
This is just sales pitch talk and concerns ProtonVPN's own apps.
How do you connect to your VPN?

I followed the arch wiki guide https://wiki.archlinux.org/title/Proton … nVPN_setup on how to use protonvpn and downloaded the protonvpn TCP .ovpn files from protonvpn accounts page

❯ ls
jp.ovpn  nl.ovpn  protonvpn.stuff  us.ovpn

I just run

sudo openvpn us.ovpn

to connect after I tether my connection.

Last edited by voxell (2024-11-05 12:53:17)

voxell · 2024-11-05 12:55:50

Strike0 wrote:

There may be two reasons: 1. the tethered dhcp gets refreshed and with it the dns of it gets added. 2. The dns gets intercepted by the router.
Are you still using networkmanager? If yes, see example 12 of https://man.archlinux.org/man/nmcli-examples.7.en how to troubleshoot (1) before/after it happens.
For (2) the route is to use encrypted dns. There are different methods, one being a vpn configured to discard dhcp dns. For browsing another is to use a webbrowser that allows overriding dns-settings (chromeedit: chromium and firefox have options for it). Simple test: when it happens, activate dns in the browser accordingly, restart it and try discord again.

I am suspecting the DHCP refreshing too, as both the wifi connection from my phone is rather unstable, and the usb connection I use also is. They may not be the main culprit here, but some sort of new connection is happening.
Even if I use just 1 phone to connect, I get more than 1 "Wired connection" 's in my nmcli connection list.

❯ nmcli connection
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  1395f17f-0426-3b5f-90ee-b6168573e724  ethernet  enp5s0f3u1
lo                  a6c27dbf-307b-4329-bc9e-b4d9e24e0353  loopback  lo
tun0                5fea19f5-8733-4c00-87a5-ffa6b76823da  tun       tun0
Wired connection 2  ab72ba2b-ab59-3110-9752-44edaa6335aa  ethernet  --

I deleted all "Wired connection *" connections just yesterday and it appeared yet again.

Last edited by voxell (2024-11-05 12:57:31)

Strike0 · 2024-11-05 14:42:59

Such re-connection issues, physical or logical, happen with tethering. Still, it's different paths to fix the dns issue for normal connection vs vpn. In your original post #1 you did not use vpn already. So, let's assume you do now, you can still start the vpn connection and get the dns server info via the example 12 quoted above. The point is that the providers ovpn profile should include a directive to pull their dns servers and you should see them via the nmcli commands. The point is proton's marketing sentence mentions "their app", hence it's unclear to us if their ovpn profiles use them too.

To fix the original issue (dns changing without vpn), it's important we know how your systems dns is managed now. If you added the directive -thc said in #12 to have systemd-resolved manage it, you should be able to simply switch to encrypted dns as described here: https://wiki.archlinux.org/title/System … S_over_TLS

voxell · 2024-11-05 14:46:40

Strike0 wrote:

Such re-connection issues, physical or logical, happen with tethering. Still, it's different paths to fix the dns issue for normal connection vs vpn. In your original post #1 you did not use vpn already. So, let's assume you do now, you can still start the vpn connection and get the dns server info via the example 12 quoted above. The point is that the providers ovpn profile should include a directive to pull their dns servers and you should see them via the nmcli commands. The point is proton's marketing sentence mentions "their app", hence it's unclear to us if their ovpn profiles use them too.
To fix the original issue (dns changing without vpn), it's important we know how your systems dns is managed now. If you added the directive -thc said in #12 to have systemd-resolved manage it, you should be able to simply switch to encrypted dns as described here: https://wiki.archlinux.org/title/System … S_over_TLS

thank you for the very detailed response, i will look into it and report back when i get the chance. the reason why i wanted not to mention any vpn settings was because the dns was reverting back regardless of the vpn being on or off. i want the workflow to be such that if i have a vpn connection, i use dns over tls, if not, always use 1.1.1.1 and 8.8.8.8

how can I figure out what exactly is handling my dns? is it systemd resolved, networkmanageerr or something else? i am not doing a grave mistake by using both am i?

Last edited by voxell (2024-11-05 14:57:07)

Strike0 · 2024-11-05 15:27:26

It's indeed very counter-productive to use more than one tool. You can have multiple installed, but only one should be used/started at a time. See the note and read a little: https://wiki.archlinux.org/title/Networ … k_managers

voxell · 2024-11-05 15:41:35

Strike0 wrote:

It's indeed very counter-productive to use more than one tool. You can have multiple installed, but only one should be used/started at a time. See the note and read a little: https://wiki.archlinux.org/title/Networ … k_managers

I did some reading, and realized networkmanager already uses systemd-resolved to do domain name resolution. So what am I doing wrong here?

❯ pacman -Q | grep network
glib-networking 1:2.80.0-3
network-manager-applet 1.36.0-1
networkmanager 1.50.0-1
❯ pacman -Q | grep systemd
openvpn-update-systemd-resolved 1.3.0-4
systemd 256.7-1
systemd-libs 256.7-1
systemd-resolvconf 256.7-1
systemd-sysvcompat 256.7-1

full pacman -Q: https://gist.github.com/Paladynee/9ddb5 … fed1751e04

Last edited by voxell (2024-11-05 15:43:39)

-thc · 2024-11-05 16:44:29

You do not need "systemd-resolveconf" - remove it.

You have to choose: If you want to keep running OpenVPN from the command line, you need "openvpn-update-systemd-resolved" to notify "resolved" about the new VPN DNS servers. If you would like to manage your VPN via networkmanger-applet you can remove it and install "networkmanager-openvpn" instead. In the applet you have to import your configuration and adjust your settings.

Strike0 · 2024-11-06 07:33:54

voxell wrote:

I did some reading, and realized networkmanager already uses systemd-resolved to do domain name resolution. So what am I doing wrong here?

Yes, but make sure you follow #12 and change systemd-resolved configuration to use encrypted dns as per #16 above. Afterwards remove the systemd-resolvconf package -thc mentions and try again without vpn. It's important to use configured dns first. Once you see the system uses your configured dns servers, continue to complete the VPN setup either for cli or networkmanager.

Arch Linux

#1 2024-11-04 23:51:41

DNS server falling back to tethered connection for no apparent reason

#2 2024-11-05 07:02:14

Re: DNS server falling back to tethered connection for no apparent reason

#3 2024-11-05 07:09:44

Re: DNS server falling back to tethered connection for no apparent reason

#4 2024-11-05 08:49:50

Re: DNS server falling back to tethered connection for no apparent reason

#5 2024-11-05 12:09:22

Re: DNS server falling back to tethered connection for no apparent reason

#6 2024-11-05 12:10:24

Re: DNS server falling back to tethered connection for no apparent reason

#7 2024-11-05 12:15:22

Re: DNS server falling back to tethered connection for no apparent reason

#8 2024-11-05 12:24:21

Re: DNS server falling back to tethered connection for no apparent reason

#9 2024-11-05 12:29:19

Re: DNS server falling back to tethered connection for no apparent reason

#10 2024-11-05 12:30:48

Re: DNS server falling back to tethered connection for no apparent reason

#11 2024-11-05 12:33:58

Re: DNS server falling back to tethered connection for no apparent reason

#12 2024-11-05 12:36:06

Re: DNS server falling back to tethered connection for no apparent reason

#13 2024-11-05 12:43:08

Re: DNS server falling back to tethered connection for no apparent reason

#14 2024-11-05 12:52:13

Re: DNS server falling back to tethered connection for no apparent reason

#15 2024-11-05 12:55:50

Re: DNS server falling back to tethered connection for no apparent reason

#16 2024-11-05 14:42:59

Re: DNS server falling back to tethered connection for no apparent reason

#17 2024-11-05 14:46:40

Re: DNS server falling back to tethered connection for no apparent reason

#18 2024-11-05 15:27:26

Re: DNS server falling back to tethered connection for no apparent reason

#19 2024-11-05 15:41:35

Re: DNS server falling back to tethered connection for no apparent reason

#20 2024-11-05 16:44:29

Re: DNS server falling back to tethered connection for no apparent reason

#21 2024-11-06 07:33:54

Re: DNS server falling back to tethered connection for no apparent reason

Board footer