i am currently running this setup
sys-whonix → firewall qube (to hold firewall rules) → sys-vpn → work
if i have firewall rules in sys-vpn set to only be able to access the vpn servers, does it imply that work and all other qubes connected to sys-vpn are essentially firewalled?
it makes sense but qubes is a confusing os, essentially why i’m asking
also is there any way for sys-vpn to bypass whonix? internet connection seems too fast sometimes
I don’t understand your setup. Is it sys-net -->sys-whonix → firewall → sys-vpn → work? If so, it’s not good… You should always have a firewall just before Sys-Net.
Your setup has to be, like this: sys-net → sys-firewall → sys-whonix → sys-vpn → work
or
sys-net → sys-firewall → sys-vpn → sys-whonix → work
Anyway, you must ALWAYS have a firewall after a sys-net.
@Tezeria The link you posted explains the reasons sys-firewall may not be necessary.
So just look at the documentation
And search in the forum, you could find easily why firewall is so important. 
I was under the impression that it was only necessary in front of qubes with qubes firewall rules, like a VPN using the qubes firewall as a killswitch. If one had only, say, sys-whonix → sys-net, I didn’t think it was necessary because sys-whonix (trusted) would handle firewall rules for preceding qubes, and sys-net (untrusted) wouldn’t need to handle any firewall rules.
Are you sure it’s trusted? How are you sure? 
You can’t be sure, that’s why Qubes-OS uses virtualization
Qubes doesn’t remove the need for trust. Sys-net is considered untrusted because it has a lot of exploitable buggy software and hardware in the network stack, so allowing it to handle firewall rules isn’t recommended because any compromise would have the option to disable firewall rules. In this you are right.
Sys-whonix, however, is considered* trusted presumably because it handles TOR connections, a sensitive task. Sys-whonix is not significantly less trusted than sys-firewall. Neither have much user stuff going on by default (sys-whonix marginally more so by having TOR-related controls). It also defaults to black in the default install, which would seem to indicate it’s considered trusted by the project as well. If it were ever compromised, it could compromise all TOR traffic as well, meaning it’s a fairly sensitive VM that should* also be trustworthy enough for firewalling. *Ultimately it’s up to each user to decide what to trust, but there’s no inherent risk or reason not to trust sys-whonix that I’m aware of (if it’s used properly).
Regardless, there would still be no need for a firewallVM in between sys-whonix and sys-net because the qube only handles firewall rules for the qubes directly connected downstream. If you don’t trust sys-whonix, you would need a firewall in between sys-whonix and your AppVM(s) connected to it downstream. (And you also should use a completely different approach to accessing TOR.)
ok, i’m a little late to this discussion, but i think it is an important one. and i very much agree with the OP. I cannot fathom why people think sys-firewall is some kind of default protection. it isn’t. in fact it ships with very little protection at all.
I made a sys-vpn that goes outside my sys-firewall like the OP. so sys-firewall connects to the VPN qube, which connects to sys-net.
My vpn qube specifies to only allow outgoing connections to the precise wireguard ip address that the vpn qube is configured for.
I would love to hear (and am completely open to) why I shouldn’t do this. And please don’t tell me “the documentation says…” unless the documentation says something real. The absolute worst thing about Qubes isn’t the finicky hardware issues or the consumption of massive amounts of RAM.
The worst thing is that the documentation is absolutely terrible, wavering between contradictory statements because it wavers between technical advanced user advice and poorly explained newbie user advice. At least whonix and tails consistently stick with newbie advice in their docs.
So yes, I’m no Qubes expert, but I’d like to hear a good explanation of why me and skeeyee shouldn’t do it this way. because it seems like a pretty damn good way of doing it when not on my home network without having to set every darn qube to connect to the VPN qube.
Instead, I just connect sys-firewall to the vpn qube and EVERY QUBE Is now tied to one vpn adress with no dns leaks.
I very much hope skeeyee and I get a thorough answer.
The sys-net is considered as untrusted and you shouldn’t trust it with firewall task, because when sys-net is compromised, then the firewall rules for the qubes connected to it could be disabled.
But if you don’t want to use firewall for the qubes connected to sys-net, then you don’t need to have sys-firewall between sys-net and these qubes.
This setup:
sys-net <-> sys-vpn <-> sys-firewall <-> work
Will be fine if you don’t want to configure a killswitch for your sys-vpn qube, but if you want to configure a killswitch, then you need to use this setup:
sys-net <-> sys-firewall1 <-> sys-vpn <-> sys-firewall2 <-> work
The same goes for sys-whonix.
If you want to configure a killswitch for your sys-whonix qube so that it only could connect to your selected Tor Entry Guards or Tor Bridges, then you need to use this setup:
sys-net <-> sys-firewall1 <-> sys-whonix <-> sys-firewall2 <-> work
It would be really helpful and a great contribution to the project if you
could suggest improvements to the documentation.
You dont need to be an expert to help - just explaining where things
are unclear would be a start.
The documentation is a community effort. Please help us improve it by
submitting a pull request.
Or you can PM me and I’ll talk to the team.
I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.Hi unman – many thanks for this response. I was thinking about opening an issue or something on this as I was finding a lot of non-qubes forums making similar commentary. I’ll pm and also try and make edit suggestions. I do believe in this project very much and I hope to be helpful and not a complainer. Thank you for your suggestion!
Thanks for this suggestion. I had wondered about the ```
sys-net ↔ sys-firewall1 ↔ sys-vpn ↔ sys-firewall2 ↔ work configuration, so i’m glad to hear that this would work!
However, I think you are using a different sense of “work” than the OP. You are speaking of a work qube, yes? and the OP is speaking of their work internet connection, I believe.
What I guess I’m still not clear on (and suspect there’s a good reason) is WHY there needs to be a buffer between sys-net and a vpn qube? For example, my vpn qube effectively has a kill switch inasmuch as it has firewall settings that force all traffic to go through the wireguard ip address before it hits sys-net and vice-versa…
I’ve checked this and there are no dns leaks anyhow.
Is the issue that some kind of exploit could be run on the wireguard software in the vpn qube? or that the encryption of the vpn needs a buffer in-between the raw traffic of the qube?
Put differently, why can’t the firewall qube be a vpn qube, especially if the vpn qube is a simple wireguard configuration? (Thanks to all who have insights here!)
I think that OP meant for work to be a work qube based on this comment:
Since otherwise it would mean that work connection (e.g. sys-net) is connected to sys-vpn, which is unlikely.
Even if you checked and there were no leaks right now, it doesn’t mean that there won’t be any leaks in the future, for example, something could break during update or there could be a new software bug that would cause a leak. Or there could be some vulnerability in the VPN software or some other system software that could allow for attacker to control your sys-vpn firewall rules.