Qubes Firewall does not support local services for proxy VMs

[3hhh]

This affects both 3.2 and 4.0rc1 differently due to different qubes-firewall mechanics.
I'll focus on 4.0rc1 here:

Typical scenario:
User sets up e.g. a DNS server in a proxy VM to handle parts of the DNS traffic passing through locally (could be any other service as well).

Unfortunately enabling the qubes-firewall for that proxy VM has no effect. Traffic to local services is always blocked by the following iptables rule:

> iptables -L -vn
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
[...]
   45  2803 REJECT     all  --  vif+   *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
[...]

Expected: The qubes-firewall manages traffic to local services by e.g. creating dynamic iptables rules based on the firewall settings of the VMs further upstream. Users might be required to pass related settings to Qubes.

Current workaround: Implement the firewall rules yourself using the VM configuration service. (https://www.qubes-os.org/doc/vm-interface/) Just e.g. allowing all DNS traffic to local services is insufficient as it'll break the Qubes firewall settings.

[marmarek]

In default configuration, proxy vm forward dns traffic - it do not handle it locally(*). If you want to setup local dns server, you also need to add appropriate rule to INPUT chain.

[marmarek]

In default configuration, proxy vm forward dns traffic - it do not handle it locally(*). If you want to setup local dns server, you also need to add appropriate rule to INPUT chain.

[3hhh]

Related discussion: https://groups.google.com/forum/#!topic/qubes-users/tbqh8d8pCG0

From my point of view this is not a doc task, but a missing feature.

You can allow local DNS, but that then allows it for all downstream VMs and bypasses the qubes-firewall settings (which might disallow DNS for them).
Reason: Traffic isn't checked against the nft FORWARD chains anymore.

[3hhh]

Related discussion: https://groups.google.com/forum/#!topic/qubes-users/tbqh8d8pCG0

From my point of view this is not a doc task, but a missing feature.

You can allow local DNS, but that then allows it for all downstream VMs and bypasses the qubes-firewall settings (which might disallow DNS for them).
Reason: Traffic isn't checked against the nft FORWARD chains anymore.

[3hhh]

I thought about this for a while and now see why this is a doc issue (but probably in a different way than you guys were thinking):

Qubes should simply not support it and the doc should mention that very clearly.

I'd suggest something such as:

Qubes does not support running any networking services (e.g. VPN, local DNS server, ...) in a VM that is used to run the qubes-firewall service and will never do so for good reasons. In particular if you want to ensure proper functioning of the qubes firewall please do not tinker with iptables or nftables rules in such VMs.

Instead, Qubes users are meant to deploy a network infrastructure such as
sys-net -- sys-firewall-1 -- [custom VM with your network services such as VPN or local DNS] -- sys-firewall-2 -- [client VMs]
(you only need sys-firewall-1 if you have clients connected there as well or want to manage your custom VM traffic flows)

Users can then tinker with whatever they want in the [custom VM].
So whenever you connect clients to network VMs, make sure that the last VM in line is a dedicated default Qubes firewall VM.

This ensures that

1. firewall changes done in your custom VM cannot render the qubes-firewall ineffective.
2. changes to the qubes-firewall by the Qubes maintainers cannot lead to unwanted information leakage in combination with user rules deployed in your custom VM.
3. a compromise of your VPN client, DNS server, ... does not compromise the Qubes firewall.

(The text is from me, I just used quotes to mark it differently.)

Documenting something like that should close this issue.

@andrewdavidwong Sorry for the confusion.

[3hhh]

I thought about this for a while and now see why this is a doc issue (but probably in a different way than you guys were thinking):

Qubes should simply not support it and the doc should mention that very clearly.

I'd suggest something such as:

Qubes does not support running any networking services (e.g. VPN, local DNS server, ...) in a VM that is used to run the qubes-firewall service and will never do so for good reasons. In particular if you want to ensure proper functioning of the qubes firewall please do not tinker with iptables or nftables rules in such VMs.

Instead, Qubes users are meant to deploy a network infrastructure such as
sys-net -- sys-firewall-1 -- [custom VM with your network services such as VPN or local DNS] -- sys-firewall-2 -- [client VMs]
(you only need sys-firewall-1 if you have clients connected there as well or want to manage your custom VM traffic flows)

Users can then tinker with whatever they want in the [custom VM].
So whenever you connect clients to network VMs, make sure that the last VM in line is a dedicated default Qubes firewall VM.

This ensures that

1. firewall changes done in your custom VM cannot render the qubes-firewall ineffective.
2. changes to the qubes-firewall by the Qubes maintainers cannot lead to unwanted information leakage in combination with user rules deployed in your custom VM.
3. a compromise of your VPN client, DNS server, ... does not compromise the Qubes firewall.

(The text is from me, I just used quotes to mark it differently.)

Documenting something like that should close this issue.

@andrewdavidwong Sorry for the confusion.

[andrewdavidwong]

@3hhh, please feel free to submit a PR to qubes-doc.

[andrewdavidwong]

@3hhh, please feel free to submit a PR to qubes-doc.