table ip qubes {
chain dnat-dns {
type nat hook prerouting priority dstnat; policy accept;
ip daddr 10.139.1.1 udp dport 53 dnat to 192.168.1.1
ip daddr 10.139.1.1 tcp dport 53 dnat to 192.168.1.1
ip daddr 10.139.1.2 udp dport 53 dnat to 192.168.1.1
ip daddr 10.139.1.2 tcp dport 53 dnat to 192.168.1.1
}
}
I have tried with both qubes that use sys-firewall and with a new test qube that I just created with the network being from sys-net and Firefox works correctly in all of the qubes.
Apparently it looks like it’s solved. Thank you. I hope this solution is not just temporary.
Also, do you think I should keep the sys-net and sys-firewall like they are now or I should delete them, create new ones, and do this process from zero? Because I didn’t download anything dangerous from those qubes, I just tested if the default page of the browser and random google searches loaded or not. Is it dangerous or I don’t have to worry?
Your sys-firewall is disposable so you can leave it as it is.
As for your sys-net - it depends on your threat model, it could be dangerous in theory but the chance is very slim.
You need to find the reason why the firewall DNS rules are not configured properly.
How is your network settings are configured in sys-net?
Do you use NetworkManager?
Do you connect to WiFi or using Ethernet?
Do you connect to your network automatically in sys-net on start or manually?
Yes, I use NetworkManager Applet. I use Wi-fi. And I connect automatically since I have made the sys-net permanent.
What setting do you think I should change?
It should work in your setup.
If I could see the sys-net logs then I could find something related to the problem there.
But right now I’m not sure where the problem is.
I couldn’t find relevant information there.
I wanted to check at what point do you get the network settings with DHCP - before or after qubes-network.service is started but there is no info about DHCP in the log.
This could be debugged further but it’ll take too much time.
For a quick fix you can try to set the DNS server in NetworkManager manually to 192.168.1.1.
I think the issue you’re describing is not uncommon and I also believe this could be the reason behind multiple GitHub issues with strange connection problems.
I have the same issue.
Unfortunately, I couldn’t help pushing this forward on GitHub as they discriminate Tor users. Getting an account took days and that one was shadowbanned for no good reason right away. None of my comments show up so I will contribute to this thread here now instead.
It is not resolved and I think this is an issue across both Debian and Fedora sys-* VMs based on reading this issue and others, while I only can speak for Debian myself. I also think this has been reported multiples times over the past years:
[#5648](https://github.com/QubesOS/qubes-issues/issues/5648)
[#5706](https://github.com/QubesOS/qubes-issues/issues/5706)
I believe this might be behind mysterious reports of DNS resolution failing such as these to name a few examples:
[#8535](https://github.com/QubesOS/qubes-issues/issues/8535)
[#8752](https://github.com/QubesOS/qubes-issues/issues/8752)
My AppVMs are unable to resolve domains. sys-firewall can't either while sys-net can just fine. I think I noticed this mostly after restarts of the two sys-* VMs as others have described before, but I also had it a few times directly after booting.
When I execute sudo nft list table qubes in sys-net, the dnat-dns chain is pretty much empty. Executing sudo /usr/lib/qubes/qubes-setup-dnat-to-ns fills it with the following rules and everything works afterwards:
ip daddr 10.139.1.1 udp dport 53 dnat to 192.168.178.1
ip daddr 10.139.1.1 tcp dport 53 dnat to 192.168.178.1
I'm on 4.2-rc5.
Maybe someone can contribute this over on GitHub and maybe UndeadDevel is active in the forum and sees this to determine if his issue (8752) is the same.