No Internet access in Fedora 41 qubes after recent update

[Solomon1732]

Qubes OS release

Qubes OS 4.2

Brief summary

I cannot connect to websites when I use clearnet qubes. This issue does not happen in Whonix.

Steps to reproduce

Checking clearnet connections

1. Open clearnet qube (based on vanilla fedora-41-xfce vanilla template) which accesses sys-firewall.
2. Open a terminal emulator.
3. Type ping 1.1.1.1.
4. It connects.
5. Type ping 8.8.8.8 to check another IP.
6. It connects too.
7. Open clearnet qube (also based on vanilla fedora-41-xfce vanilla template) which accesses sys-firewall.
8. Open firefox.
9. Type 1.1.1.1 (should navigate to https://one.one.one.one) in the URL bar.
10. It waits for a long time
11. It prints the "Server Not Found" in the title. The webpage itself says "Hmm. We're having trouble finding that website." The URL bar shows https://one.one.one.one for 1.1.1.1.
12. Type 8.8.8.8 (should navigate to https://dns.google ) in the URL bar.
13. It waits a long time.
14. It says "Problem loading page" in the title bar. The URL bar shows 8.8.8.8. The page shows "The connection has timed out".
15. Type a https://www.wikipedia.org in the URL bar.
16. It waits a long time.
17. Same as step 11: it prints the "Server Not Found" in the title. The webpage itself says "Hmm. We're having trouble finding that website." The URL bar shows https://www.wikipedia.org

Test with Curl as a sanity check to see if it's a Firefox issue

1. Open Open a terminal emulator.
2. Run curl -IsS 'https://one.one.one.one'.
3. It waits a long time.
4. It prints "curl: (6) Could not resolve host: one.one.one.one".
5. Run curl -IsS 'https://dns.google'.
6. It waits a long time.
7. It prints "curl: (6) Could not resolve host: dns.google".
8. Run curl -IsS 'https://www.wikipedia.org'.
9. It waits a long time.
10. It prints "curl: (6) Could not resolve host: www.wikipedia.org".

Check Whonix behavior to compare

1. Open Tor in a Whonix workstation qube (dispVM based on vanilla whonix-workstation-17 and whonix-gateway-17).
2. Type 1.1.1.1 in the URL bar.
3. It reaches https://one.one.one.one without any issues.
4. Type 8.8.8.8 in the URL bar.
5. It reaches https://dns.google without any issues.
6. Type https://www.wikipedia.org in the URL bar.
7. It reaches https://www.wikipedia.org without any issues.

Expected behavior

Browse the clearnet without any issues. For example:

• 8.8.8.8 and https://dns.google should navigate to https://dns.google.
• 1.1.1.1 and https://one.one.one.one should navigate to https://one.one.one.one
• https://www.wikipedia.org should navigate to the website.

ping from the terminal should work.

Whonix 17 qubes work fine.

Actual behavior

The Fedora 41 qubes cannot resolve URLs or IPs, neither through Curl nor through Firefox.

ping works.

Whonix 17 qubes work fine.

Additional information

This has been happening since a recent Fedora 41 update from yesterday or from the day before. This is as of 22/03/2025 Jerusalem time zone, so from the 21st or 20th.

[bi0shacker001]

To be clear, 8.8.8.8 doesn't have a webserver hosted on it, and wouldn't resolve to anything. The fact that pings work mean it's a DNS issue. Check /etc/resolv.conf in the template, make sure it's configured properly

[marmarek]

Does DNS resolution work in sys-net and/or sys-firewall?

[Solomon1732]

To be clear, 8.8.8.8 doesn't have a webserver hosted on it, and wouldn't resolve to anything.

It resolves to https://dns.google/ on other machines, and like I wrote above on Whonix.

The fact that pings work mean it's a DNS issue.

Yeah, I figured, but I didn't want to say it since I'm a layman in such areas. So I focused on describing the bug instead.

Check /etc/resolv.conf in the template, make sure it's configured properly

This is what the file is in my vanilla fedora-41-xfce template

# This file intentionally left blank

Does DNS resolution work in sys-net and/or sys-firewall?

I ran curl -IsS https://one.one.one.one in both:

• sys-net: HTTP/2 200 (I think it means a success?), and a bunch of other things. It returns right away.
• sys-firewall: It waits a long time, then prints "curl: (6) Could not resolve host: one.one.one.one".

So at least this narrows the issue, I hope.

[bi0shacker001]

/etc/resolv.conf SHOULD have the qubes DNS configuration in them.
It should read

nameserver 10.139.1.1
nameserver 10.139.1.2

These are the qubes internal dns servers. I'd say try to add them back to the template manually, or edit the running qube and see if it works after, but I believe those are set by qubes scripts, so it being wrong points to a deeper problem
sys-net works because its DNS is the external one, set by NetworkManager.
EDIT: It appears I'm incorrect. Double checking my template confirms that it shows the same thing. Check in a qube which is based on the template.

[Solomon1732]

This makes sense.

Huh, ok, so in a dispVM which does use sys-firewall the two lines do show up correctly. I guess it doesn't in the template since I have it disconnected from the internet (standard for templates)? I also checked in a standalone qube I cloned a good while ago from said template (to install Calibre Reader). /etc/resolv.conf also has the same two lines in them, yet the same inability to connect to clearnet through DNS resolution.

Edit: Alright, so I did a small test. My test was this:

1. Create a new AppVM test-dns based on vanilla fedora-41-xfce template.
2. In creation, connect it to sys-whonix instead of sys-firewall.
3. Open the terminal.
4. Type curl -IsS 'https://example.com'
5. The response is HTTP/1.1 200 OK

[marmarek]

Yes, templates are supposed to not have normal network connected. But app qubes should have.

So, since it's already broken in sys-firewall, there are a couple of things to check:

1. most likely - an issue with DNS redirection rules in sys-net: check sudo nft list chain ip qubes dnat-dns - it should list a bunch of rules redirecting 10.139.1.1/1.2 to the actual DNS servers. If it isn't there, try clicking in network manager icon to disconnect and connect the network again. If still not there, check journalctl in sys-net for errors.
2. Some failure with initial firewall loading: check status of qubes-iptables service (it's legacy name, it uses nft nowadays)
3. Some issue with qubes-firewall service - check its status, if it's failed, try restarting it.

[Solomon1732]

In sys-net I ran sudo nft list chain ip qubes dnat-dns:

table ip qubes
	chain dnat-dns {
		type nat hook prerouting priority dstnat; policy accept;
		ip daddr 10.139.1.1 udp dport 53 drop
		ip daddr 10.139.1.1 tcp dport 53 drop
		ip daddr 10.139.1.2 udp dport 53 drop
		ip daddr 10.139.1.2 tcp dport 53 drop
	}
}

I admit steps 2 and 3 went over my head. Sorry.

[marmarek]

Just check systemctl status qubes-iptables and systemctl status qubes-firewall

[Solomon1732]

Oh. Also in sys-net or in another qube?