Taking a closer look out your output, there are a few things that stand out.
Your sys-net:
$ sudo iptables -t raw -L -nv
Chain PREROUTING (policy ACCEPT 24009 packets, 103M bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- vif31.0 * !10.137.0.6 0.0.0.0/0
0 0 DROP all -- vif32.0 * !10.137.0.6 0.0.0.0/0
This is odd. This tells me you have two downstream VMs connected to sys-net…but it’s as if Qubes thinks they share the same IP.
Normally we’d see two rules for each VM here:
- A rule to block packets from a VM whose source IP does not match the VM
- A rule to block packets from physical interfaces whose source IP address matches this VM
So if there are two downstream VMs on sys-net, I’d expect to see 4 rules there. So this is interesting.
Because, based on your ip route output in sys-net:
$ ip route
default via 172.16.0.1 dev wls7 proto dhcp metric 600
10.137.0.6 dev vif31.0 scope link metric 32721
172.16.0.0/21 dev wls7 proto kernel scope link src 172.16.5.4 metric 600
Qubes doesn’t indicate anything for the vif32.0 interface, meaning, it doesn’t think there is a downstream VM with domain 32 connected to sys-net.
Is there anything custom in /rw/config/qubes-firewall-user-script within sys-net, or any iptables commands in /rw/config/rc.local? The fact the iptables rules and interfaces look out of sync makes me question if something is modifying your firewall rules…or if Qubes just isn’t configuring them correctly due to some scenario.
From the ip route and raw table iptables output from sys-net, we can assume domain 31 is sys-firewall, and that the sys-firewall IP address is 10.137.0.6. From the ip route output from sys-firewall, we can assume is the IP of 10.137.0.5 is sys-net, as that’s what sys-firewall has a route to. If it’s not, that’s an issue.
From the output of sudo nft list ruleset in sys-firewall and sys-net, these appear to be the same. Was that a copy/paste issue? It appears there is only forwarding in place for 10.137.0.13, and based on the above (assuming your VM configuration hasn’t changed), I assume 10.137.0.13 is a downstream VM connected to sys-firewall. I question if the output from sudo nft list ruleset was correct for sys-net, as if it didn’t include a forwarding chain for the IP address of sys-firewall (10.137.0.6), that’s an issue.
Another observation from your sys-net NAT table:
Chain PR-QBS (1 references)
pkts bytes target prot opt in out source destination
363 26314 DNAT udp -- * * 0.0.0.0/0 10.139.1.1 udp dpt:53 to:192.168.84.120
0 0 DNAT tcp -- * * 0.0.0.0/0 10.139.1.1 tcp dpt:53 to:192.168.84.120
362 26245 DNAT udp -- * * 0.0.0.0/0 10.139.1.2 udp dpt:53 to:192.168.84.120
0 0 DNAT tcp -- * * 0.0.0.0/0 10.139.1.2 tcp dpt:53 to:192.168.84.120
The counters on this table would normally be zero within sys-net if there were no downstream VM attempting to resolve host names. Within sys-net, host name resolution will directly hit the 192.168.a.b DNS servers, and you’ve confirmed /etc/resolv.conf contains those same 192.168.a.b values. Non-zero means a downstream VM is attempting to do DNS.
Both DNS servers are being queried. At least on my own Fedora 32 VM setup, I’ve only seen the second DNS being queried when there are issues reaching the first (or the first returns ServFail.
So there are a few things that look weird that I’d want to rule out if you’re still willing to troubleshoot, just in-case there is something within Qubes at play here.
Last comment is that you’ve said:
I moved the computer to a new location and networking between qubes works perfectly now.
Can you clarify what this means? I assumed this meant a different physical location, but to the same wifi router/gateway/network. Or was this statement indicating that connecting to a different wifi network has resolved the issue?