Internet works, but no internet on VM. Maybe dnsmasq problem, eth0 disappeared

Dear community

How can I reset to default network interfaces and DNS?

I don’t know what specifically caused my problem, maybe NextDNS, a VPN, or when I used a static IP for OpenWRT flashing, but my internet is weird.

Meaning, I have internet access, I can browse the web, ping command works with IPs and domains, if I check what my DNS are on a website, I see my ISP DNS. All good, I want my router to give me DNS settings, in fact on my laptop I have not set up any custom DNS.

I suspect the issue is from dnsmasq which I had to use once to restore a OpenWRT router recently.

The terminal command nslookup google.com says

[user@pc ~]$ nslookup google.com
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; no servers could be reached

I suppose I don’t have to connect to 127.0.0.1, correct?

Also resolvectl returns:

[user@pc ~]$ resolvectl
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 127.0.0.1
       DNS Servers: 127.0.0.1
        DNS Domain: home

Link 2 (wlp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
Current DNS Server: fe80::e68f:34ff:fee4:2224
       DNS Servers: 192.168.255.1 fe80::e68f:34ff:fee4:2224
        DNS Domain: station

Looking at my network list, I no longer see eth0, only wifi. Where has it gone?

Why am I troubleshooting? Because I have no internet in VM in Gnome Boxes (tried VirtManager, too) and the VMs I launched said that they configured the network, but internet within the VM does not work, even if the VM shows everything is ok.

I have no NextDNS or VPN installed right now.

Can someone suggest me where to look and which commands to use in order to reset the default fedora configuration? I have also tried to delete /etc/systemd/resolve.conf file but it has not been created back by the system.

STOP grasping at straws!

Does the host have proper internet? I suspect not since you apparently are not getting proper dns response.

If the HOST does not have good internet then the VMs certainly will not and the host must be fixed. Doing things with the VMs when the host is the problem can only make things worse.

This may easily be the cause.
Please show the output of ip a and ip r so we can see both the device configs and the routing.

How did you set the fixed IP and how was that config removed? Dns is not required for flashing the router but it is for internet access. When using the internet most routers provide an automatic IP and dns server info via dhcp. If that is broken then connecting to the internet may be problematic. The 2 commands given above is a good starting point.

Thank for replying Jeff.

I used dnsmasq when debricking the router, see the commands here: https://openwrt.org/toh/xiaomi/ax3600#tftp_recovery

I have not done anything after those commands, meaning I did not restore configurations, I was not aware something needed to be restored :sweat_smile:

Host seems having internet, as I am writing to you from the host.

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: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 8c:c6:81:90:71:da brd ff:ff:ff:ff:ff:ff
    inet 192.168.255.10/24 brd 192.168.255.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 172194sec preferred_lft 172194sec
    inet6 fe80::5b80:5331:d331:1a63/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

ip r

default via 192.168.255.1 dev wlp1s0 proto dhcp src 192.168.255.10 metric 600 
192.168.255.0/24 dev wlp1s0 proto kernel scope link src 192.168.255.10 metric 600 

Check the output:

grep -v -r -e "^#" -e "^$" /etc/systemd/resolved.*
grep -v -e "^#" -e "^$" /etc/resolv.conf
grep -e ^hosts: /etc/nsswitch.conf
resolvectl --no-pager status
resolvectl --no-pager query example.org
systemctl status systemd-resolved.service
journalctl --no-pager -b -u systemd-resolved.service

I do not see virbr0 in the output from ip a. For me that shows up when I have at least one of the VMs booted.

I don’t understand why dnsmasq may have been needed to work directly with a router, since your host machine should have been connected to the router. With that said, it may be an issue for the VM depending upon how the network is configured on the VM.

On my system I see this with ip a. The first is before I start a VM and the second is after I start one VM. I use VMM (virtual-machine-manager) to manage my VMs.

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
<trimmed>  

2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 70:85:c2:93:f7:2c brd ff:ff:ff:ff:ff:ff

3: wlp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
<trimmed>  

 $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
<trimmed>  

2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 70:85:c2:93:f7:2c brd ff:ff:ff:ff:ff:ff

3: wlp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
 <trimmed>  

4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:77:64:e8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:c9:2e:5c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fec9:2e5c/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Note the system creates the virbr0 device as soon as I start the VM.

The routing on the host after starting the VM

$ ip r
default via 192.168.4.1 dev wlp5s0 proto dhcp src 192.168.4.111 metric 600 
192.168.4.0/22 dev wlp5s0 proto kernel scope link src 192.168.4.111 metric 600 
192.168.124.0/24 dev virbr0 proto kernel scope link src 192.168.124.1 

I was not running any VM, should I? I am trying to solve host internet situation

This, plus the title seems to indicate the host is OK but the VMs are not.

If that statement is correct, then certainly you should pick one of the VMs, power it on, then work on solving the internet problem there. It seems quite possible that installing dnsmasq may have broken the ability for the normal and previously working network configs to function.

Have you tried removing dnsmasq from the host and resetting all the configs that may have been altered back to default?

The commands given by @vgaetera above may provide clues, especially if run on both the host and on one of the VMs.

grep -v -r -e "^#" -e "^$" /etc/systemd/resolved.*
no such file or directory

grep -v -e "^#" -e "^$" /etc/resolv.conf
search home
nameserver 127.0.0.1

grep -e ^hosts: /etc/nsswitch.conf
hosts (in red): files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

resolvectl --no-pager status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
DNS Domain: home

Link 2 (wlp1s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.255.1
DNS Servers: 192.168.255.1 fe80::e68f:34ff:fee4:2224
DNS Domain: station

resolvectl --no-pager query example.org
example.org: 2606:2800:220:1:248:1893:25c8:1946 – link: wlp1s0
93.184.216.34 – link: wlp1s0

– Information acquired via protocol DNS in 901us.
– Data is authenticated: no; Data was acquired via local or encrypted transport: no
– Data from: cache

systemctl status systemd-resolved.service

systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Wed 2024-01-31 15:55:19 CET; 24min ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
writing-network-configuration-managers
writing-resolver-clients
Main PID: 1312 (systemd-resolve)
Status: “Processing requests…”
Tasks: 1 (limit: 18410)
Memory: 6.9M
CPU: 824ms
CGroup: /system.slice/systemd-resolved.service
└─1312 /usr/lib/systemd/systemd-resolved

gen 31 16:18:58 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 16:18:58 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.
gen 31 16:19:00 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 16:19:00 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.
gen 31 16:19:05 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 16:19:05 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.
gen 31 16:19:16 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 16:19:16 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.
gen 31 16:19:31 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 16:19:37 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.

journalctl --no-pager -b -u systemd-resolved.service

gen 31 15:55:19 dora systemd[1]: Starting systemd-resolved.service - Network Name Resolution…
gen 31 15:55:19 dora systemd-resolved[1312]: Positive Trust Anchors:
gen 31 15:55:19 dora systemd-resolved[1312]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
gen 31 15:55:19 dora systemd-resolved[1312]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
gen 31 15:55:19 dora systemd-resolved[1312]: Using system hostname ‘dora’.
gen 31 15:55:19 dora systemd[1]: Started systemd-resolved.service - Network Name Resolution.
gen 31 15:55:26 dora systemd-resolved[1312]: wlp1s0: Bus client set search domain list to: station
gen 31 15:55:26 dora systemd-resolved[1312]: wlp1s0: Bus client set default route setting: yes
gen 31 15:55:26 dora systemd-resolved[1312]: wlp1s0: Bus client set DNS server list to: fe80::e68f:34ff:fee4:2224
gen 31 15:55:27 dora systemd-resolved[1312]: wlp1s0: Bus client set DNS server list to: 192.168.255.1, fe80::e68f:34ff:fee4:2224
gen 31 15:55:28 dora systemd-resolved[1312]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 127.0.0.1.
gen 31 15:55:29 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 15:55:29 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.
gen 31 15:55:44 dora systemd-resolved[1312]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 127.0.0.1.
gen 31 15:55:44 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 15:55:44 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.
gen 31 15:55:44 dora systemd-resolved[1312]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1.
gen 31 15:55:44 dora systemd-resolved[1312]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1.

(it continues like this)

@computersavvy I would like to remove dnsmasq and reset the configs, but I don’t know how to do both.

I think something not correct is going on…

Restore the default configuration:

sudo dnf -y reinstall systemd-resolved
sudo ln -f -r -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl --now disable dnsmasq.service
sudo systemctl restart systemd-resolved.service

If the issue persists, fix SELinux labels:
Systemd-resolved fails on initial load - #10 by grumpey

1 Like

It works!! Thank you a ton :smiley: :smiley: