After I upgraded my Qubes R2 system to Qubes R3.0 in place (still using
my own Fedora 21 template), DNS did not work from one of my AppVMs. On
further investigation, the DNAT rules for DNS were missing from
"iptables -S -t nat" on the FirewallVM. After adding some debug code to
the scripts involved, I saw the following behavior:
1. systemd starts qubes-network.service, which entails
calling /usr/lib/qubes/init/network-proxy-setup.sh, which
calls /usr/lib/qubes/qubes-setup-dnat-to-ns. At this
point, /etc/resolv.conf contains the addresses of the FirewallVM itself.
AFAICT, these remain from the last run of the TemplateVM, since its
uplink is this same FirewallVM. This results in circular DNAT rules.
2. systemd starts qubes-misc-post.service, which entails
calling /usr/lib/qubes/init/misc-post.sh, which
calls /usr/lib/qubes/setup-ip, which
calls /usr/lib/qubes/qubes-setup-dnat-to-ns. At this
point, /etc/resolv.conf correctly points to the NetVM, but the COMMIT
command fails (possibly related to the fact that #1 is running
concurrently) and the circular DNAT rules are left in place.
How is this supposed to work? Is it possible something was left in the
wrong state from the in-place upgrade, or is the above behavior just a
bug? I see some possibly related issue reports
(
https://github.com/QubesOS/qubes-issues/issues/1067,
https://github.com/QubesOS/qubes-issues/issues/1284), but they don't
appear to point to a solution to the above.
As a workaround, I've disabled the qubes-network service in the
FirewallVM using qubes-manager with no apparent ill effects.
Thanks,
Matt