Hi,
thank you for the positive feedback, I really appreciate it.
I spent the past couple of days digging into the "rules distribution" mechanism in the various QubesDB. It really took some time to find a better way to handle and separate the rules for each domain at every 'step' of their network path.

https://github.com/lsd-cat/qubes-core-admin/commit/0cf04fb290469340a59a013531bba6e06e8a0169

The idea here is that each appvm will have a separate QubesDB folder on the untrusted qdb of each netvm. This is for easier cleaning and reloading, and can be used in the future when displaying the forwarding chain at each step like we were discussing with Marek in the first emails. A practical example follows.

Assume the following network path:

*internet/lan* <-> sys-net (10.137.0.5) <-> sys-firewall (10.137.0.6) <-> sys-vpn (10.137.0.13) <-> sys-tor (10.137.0.14) <-> personal (10.137.0.10)

And the following rule:
# qvm-firewall personal add action=forward forwardtype=external proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24

Here are the QubesDB entries that are automatically added, to be consumed from the core-agent-linux:

In sys-net:
key = /qubes-firewall-forward/personal/10.137.0.6/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24

In sys-firewall:
key = /qubes-firewall-forward/personal/10.137.0.13/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24

In sys-vpn:
key = /qubes-firewall-forward/personal/10.137.0.14/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24

In sys-tor:
key = /qubes-firewall-forward/personal/10.137.0.10/0000
value = action=forward forwardtype=external proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24

Although this mechanism seems complex, I was not able to think of a simpler solution. Furthermore I think it is important to know which appvm is requesting the forwarding at every step, both for debugging and auditing purposes. Lastly, the next hop ip address has to be determined automatically anyway and writtem somewhere so there it is.

I am also thinking about adding a couple of flags to let the nodes know which one is the first and which one is the last since especially the last needs additional rules for the external forwarding.

One more thing, maybe between internal hops it makes sense to randomize the forwarded ports? This way we can prevent forwarding from different appvm which shares the same network path or even just one hop from overlapping, at least internally. Does it makes sense for you?

Cheers
Giulio