This is all more or less based on an excellent blog post by Micah Lee.
I’ll try to explain again with more detail:
sys-net is a HW VM that “has” the PCI devices needed to connect to
networks (i.e. Ethernet, WiFi). In my case this VM is also disposable.
sys-clearnet is a proxy qube that has sys-net as a netvm (get’s its
connection from sys-net) and functions as a firewall. What that means
is: it will enforce the firewall settings of qubes connected to it.
sys-njalla is also a proxy qube getting it’s conenction from
sys-clearnet. It is the one connecting to the VPN . In the firewall
rules for this qube I specified the IP addresses and port of the VPN
servers. This means that sys-clearnet enforces that sys-njalla cannot
contact any other servers then the VPN servers. This is to make sure
that every qube that uses sys-njalla as netvm only gets a connection
when sys-njalla is actually connected to the VPN.
sys-vpn is another firewall proxy qube that all other qubes connect
to. It doesn’t implement VPN but it gets its connection from sys-njalla
which does implement the VPN. I just called it this way to distinguish
easily between clearnet and VPN based connections. So if you want your
app qube to use ‘clearnet’ you connect to sys-clearnet and if you want a
‘VPN’ connection you connect to sys-vpn. sys-vpn enforces the firewall
rules configured for the app qubes.
So: if sys-njalla is the only qube connected to sys-clearnet, then
sys-clearnet and sys-net will only ever see encrypted traffic to/from
Njalla’s VPN servers. Traffic that get’s blocked by sys-vpn will never
even reach sys-njalla and therefore never reach the VPN servers.