Blocking outgoing traffic in sys-* VMs

Has anyone blocked outgoing traffic from their sys-* VMs? I don’t need those VMs to ever make any connections, but they do need to have their NetVMs.

Is it safe to add an nftables chain that blocks output? Will this stop other VMs using them as the NetVM from having network access?

Where can I read about how the forwarding works when one VM uses another as a NetVM, and has anyone tried this and documented it?

you could disable sys-firewall and sys-net boot startup, and set all your qubes without a network vm.

if you need the qubes to communicate together, you could create a qube with no netvm but providing network, it will allow to connect qubes through it but it will just not be connected to anything.

Just to note for novices that when sys-net equals sys-usb, blocking shouldn’t be considered

Can you explain why.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

You misunderstood, I want my qubes to have access to the network, but the sys-* VMs should be blocked themselves because they have no reason to connect to anything as I see it.

I’ll try myself later, I think I could drop all outgoing connections that do not originate from the internal qubes range and see if anything breaks.

I do not know what the software and services in those templates connect to. They should not connect to anything ideally. I cannot use sys-firewall to limit them since they are sys-net or sys-firewall themselves thus nftables.

More

If that still does not make sense, consider cases where I only want to make outgoing connections through a VPN and leak nothing to my ISP, etc.

My question was directed at @auser, and I quoted his post. Was that not
clear?
So @auser - please explain why sys-net/sys-usb combination requires
outgoing traffic not to be blocked, as can be done for sys-net.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

I think there’s a mistake, you quoted me, and that was my reply to you. One example I gave was that any outgoing connections from sys-net/sys-firewall would escape a VPN (that is higher up the chain of NetVMs). I have not tried blocking outgoing connections from sys-net etc yet, but I will at some point.

Using nftables, the locally generated traffic is usually governed by chains attached to the OUTPUT hook, while the forwarded traffic is going thru the FORWARD-hooked chain(s).

That is, unless you proxy traffic (e.g., socks), in which case the proxy’d traffic is also going through OUTPUT too.

See the Netfilter Hooks Wiki page for a nice overview.

There was a mistake - I actually quoted @tempmail, but for some reason
discourse removed the quote from my post, and then I compounded the
mistake by saying I had quoted you.

SO, to make it clear - I normally block outgoing traffic from sys-net
and sys-firewall. @tempmail said that sys-net/sys-usb combined required
outgoing traffic not to be blocked, and I asked them for an
explanation of this claim.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

I’ve done this now by adding an output chain to the qubes table and rejecting outgoing traffic. This works fine. Do you know if Qubes OS will at any point modify it so that my chain is removed? Should I create my own table instead?