I don’t know this will be fitted in any categories, but serious question: what’s your Qubes network design?
Let me go first:
Whonix-ws > Whonix-gw > firewall2 > OpenProxy > Firewall3 > sys-net
AppVM > sys-firewall > sys-net
Mostly as follows:
Whonix WS → Whonix Gateway → Mullvad SOCKS5 Proxy → Mullvad Multihop with WireGuard → Internet
In terms of VM naming. it goes as follows:
[Whonix WS VMs] → sys-whonix → sys-mullvad → sys-firewall → sys-net
I have a Debian 11 DisposableVM Template connected with a SOCKS5 Proxy directly to sys-mullvad in case it’s necessary to use a non-Tor Disposable browser.
The rest of my traffic goes through a dedicated sys-mullvad-au VM with Multihop Australian Servers for activity relating to my personal identity.
For the network that I been using now is RiseupVPN.
Here is the diagrams:
Whonix-ws > Whonix-gw > Firewall2 > sys-riseupvpn > firewall3 > sys-net
AppVM > sys-firewall > sys-riseupvpn1 > firewall4 > sys-net
I really wonder what are the reasons for - and what are you expecting from - such network setusp… 
I keep it simple:
appVM → VPN → sys-net
because the VPN VM can act as a firewall as well.
in practice if the VPN is not connected (Like at Home), then it’s just a firewall - no matter how I named the VM itself…
for browsig in a dispVMs it’s more simple:
dispVM → sys-net.
because I do not have any firewall rules for general browsing, so putting a firewall in between do not add any benefits at all.
appVM → sys-ips → sys-net
You are going full risk at this, aren’t you?
Please explain what “full risk” are you referring to.
And please also explain what you think about how a simple packetfilter would save you from that risk - whatever it is.
Thanks.
Redundant vpn firewalls make sense whenever the appVM firewall rules include URLs, since the qubes-firewall service in the vpnVM can fail if DNS is not resolved. For this reason, I try to avoid using URL based firewall rules.
With the Mullvad SOCKS5 proxy, for example, one only needs a single appVM rule restricting access to 10.x.0.1. In this case, the following setup works perfectly, no redundant firewalls needed, the vpnVM firewall is sufficient.
appVM > vpnVM > sys-firewall
However, if for some reason I wanted to include a URL in my appVM rules, I would structure it as follows:
appVM > redundant-firewallVM > vpnVM > sys-firewall
and I would occasionally check systemctl status qubes-firewall in the redundant-firewallVM.
that’s simply not supported by a simple packet filter.
It may ‘works’, as what happens is the DNS resolution happen the time you inster the rule.
But as the end result is always an IP address in the packet filter, so it is rarely what you really meant… (given the fact that a URL usually resolves multiple and/or different IP address by every query)
so it only ‘works’ in case of a simple websites with static IP bindings that never (or rarely) changes.
Just to be clear about the case I had in mind. The Firewall rules tab of the Qubes settings GUI supports URL based firewall rules, which can unfortunately cause the qubes-firewall service to fail in the downstream vm (whenever DNS is not resolved).
What you guys done are sometimes nonsense to have vpnVM as your firewall if the attack still going on to your Qubes.
Does my topology makes more sense ?
appVM → sys-ips → sys-net
Suricata and NFQUEUE in sys-ips
+
Per Qube Firewall settings allowing only given website and protocol.
I am testing it with Hail Marry attack and Cobalt Strike. + custom trials and errors. Metasplot also.
So far no exploit, bug problem hole.,. what ever 
where ‘supports’ only means it is allows you to enter DNS name instead of the IP, but the warning is on the documentation states what I described:
Note that if you specify a rule by DNS name it will be resolved to IP(s) at the moment of applying the rules , and not on the fly for each new connection. This means it will not work for servers using load balancing, and traffic to complex web sites which draw from many servers will be difficult to control.
Internet < SIEM ← VPN ← everything to connect through here < branch out to infrastructure labs, pentest lab and a personal VM to play in
Indeed, this is exactly the reason having a redundant-firewallVM makes sense whenever one uses a URL rule in the appVM. Without the redundancy, the qubes-firewall service could enter a failed state in the vpnVM.
In 4.1 Qubes exports the resolved DNS entries so that you can theoretically pin the entries to the IPs that they were originally resolved to. That should then fix all the loadbalancing, cloud etc. issues.
unfortunately zenmap has not yet been ported to python3, and python2 is EOL. It’s no longer in the debian repos as of debian 11 (bullseye), for example. Zenmap and Ndiff are python2 only · Issue #1176 · nmap/nmap · GitHub
whereas nmap is a recommended package in the minimal templates doc…
Curiously, how do you prevent VPN leaks? I have firewall rules set up in my VPN proxy VM (primarily blocking IPs that are not associated with the VPN servers).
Qubes documentation seems to warn against running network services (ex. VPN) in VMs that run the Qubes firewall service (ex. sys-firewall). Not surprisingly, they suggest compartmentalizing the two functions. They also seem to recommend a second firewall be used between the client (appVM) and proxy (VPN) for other reasons.
Or perhaps I am misunderstanding something? The term “firewall” is used loosely at times. Either way, even if the potential benefit is a toss up, it seems that firewalls based on a minimal templates don’t impact resources too much to worry about it…
[source: Firewall | Qubes OS]
Another discussion about this topic:
