Do We Need Firewall-qube After Sys-VPN? (Qubes-vpn-support)

Continuing the discussion from Secure VPN VMs in Qubes OS:

The official Firewall documentation recommends to have separate VPN and firewall VMs.

sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes]

I have successfully set up a Mullvad vpn Qube using Qubes-vpn-support (that I have read many recommendations on searching the forum) and Wireguard (does Mullvad even still support openvpn? I can’t find configurations files for it). The GitHub page, however, states that no “separate firewall VM” is required. Does it refer to what’s called “sys-firewall-2” in the documentation? Or have I misinterpreted? How can this be, given the three arguments the documentation makes in favour of such a model? If the answer is in the Readme’s “firewall notes” I’m not able to link the dots…

Secondary question: what’s the best way to change the vpn server in such a setup? Since I’m still not capable to drift too far away from the guide, what I have thinked of is to copy a new .conf file to the vpn qube and use

sudo cp mullvad-us1.conf /rw/config/vpn/vpn-client.conf

again, like I did in the setup. Is there a better way?

A post was split to a new topic: How to Easily Change VPN Server w/ sys-vpn?

Let’s discuss this one in this other thread to keep the forum organized: How to Easily Change VPN Server w/ sys-vpn? (feel free to suggest another title)

I’ve also made the current title into a question. Feel free to change it if you disagree.

I think what Tasket means is that there are already firewall rules defined in the VPN qube that stop any non-vpn traffic going through to sys-net. So if that’s all you wanted to achieve you’re fine connecting sys-vpn to sys-net.

If you want to limit what comes out of or into the VPN tunnel, then put a firewall “in front” of it - i.e. between the VPN qube and the AppVM.

If you have any qubes that have network access that won’t use the VPN, you might want to limit what they do by putting a firewall between them and sys-net. You may also consider putting a firewall between sys-net and sys-vpn if you are worried that your sys-vpn may be compromised.

1 Like

@Newb asked:

does Mullvad even still support openvpn?

Yes

@Newb asked:

states that no “separate firewall VM” is required. Does it refer to
what’s called “sys-firewall-2” in the documentation?

Yes

However I would still recommend to have a dedicated firewall, especially
if you find yourself wanting to switch between VPNs without restarting
your qubes.

sys-net <-> sys-clearnet-firewall <-> sys-vpn1 <-> sys-vpn-firewall

If all of your online app qubes are connected to sys-vpn1 (the case
without an additional firewall), you now have to switch them all from
sys-vpn1 to sys-vpn2. However, if you use an additional firewall you
simply switch the netvm property of that firewall to sys-vpn2 and
everyone connected to sys-vpn-firewall now goes through sys-vpn2.

If you base your firewall qubes on debian-minimal and only install
qubes-core-agent-networking and qubes-core-agent-passwordless-root …
you can get away with assigning as little as 200MB RAM to them. If you
never invoke XTerm and therefor X you can even make it work with 150MB.
So there is only a very tiny penalty for using the additional firewall.

3 Likes

Shouldn’t we worry about that by default? I think that what I’m still struggling to understand is: do I only need a firewall if I need to enforce some network rule or does it also provide an additional layer of security?

My idea was to directly change the vpn configuration of the vpnqube, is there a security rationale in doing it your way or is it only about practicality?

I’ll try to set that up, thank you

A firewall VM will only enforce network rules. If you want to make sure access to your local network is restricted or that your VPN traffic isn’t leaking out of the tunnel, then a firewall VM is your friend. But it doesn’t do anything else.

I’m very happy to be corrected on this though!

The only additional security feature I can think of would be if there was a network-based vulnerability that affected your sys-net template but not your sys-firewall one. Then maybe the firewall VM would stop it.

Let’s think it through:

sys-net is a HVM with direct access to PCI devices (e.g. WiFi) and
naturally an internet connection. It will see all traffic. It can
also enforce firewall rules like any other proxy qube that has
qubes-core-agent-networking installed.

Your sys-vpn’s job is to create an encrypted tunnel to a specific server
and route all traffic through that tunnel… so now ideally sys-net only
sees encrypted traffic to your VPN provider and nothing else.

To make sure your sys-vpn doesn’t leak clearnet traffic when the VPN
tunnel is not active you define firewall rules for sys-vpn to make sure
sys-vpn can only ever connect to the VPN server.

If you connect your sys-vpn directly to sys-net, it is now sys-net’s job
to enforce those rules. Is that a good idea? No it’s not. sys-net should
be extremely untrusted. It’s an internet connected qube that can also be
directly accessed via the PCI bus. If an attacker would manage to
compromise your sys-net they could easily disable iptables (aka the
firewall) in sys-net and now it no longer enforces the rules of all the
qubes directly connected to it.

If you however have a sys-firewall qube between sys-net and sys-vpn,
that firewall qube will enforce the rules for sys-vpn. Even if your
sys-net get’s compromised it will only ever see encrypted traffic to
your VPN provider because that’s the only traffic sys-firewall will let
through.

2 Likes

This makes it super-clear, thank you!

So, to return to the original question, my understanding is that Qubes-vpn-support makes it so that a firewall is not required (but still useful) between sys-vpn and any appvm connected to it. My understanding is also that sys-vpn is not as untrusted as sys-net.

By the way, I tried setting up a firewall between sys-vpn and appvms based on debian minimal + qubes-core-agent-networking and qubes-core-agent-passwordless-root as you suggested, but it doesn’t work with 200mb ram: i get “failed to start: internal error: libxenlight…”. It works with 300mb. It’s not super-important to have it super-lightweight, but I thought I’d report on it.

Weird. For me it even runs and does it’s job with only 150 MB … as
long as I don’t start XTerm or any other X app on it.

What exactly does the error message say?

dom0 libvirtd[2932]: 2021-08-05 07:17:38.922+0000: 2963: error : libxlDomainStart:1308 : internal error: libxenlight failed to create new domain 'trial'
dom0 qubesd[2839]: Start failed: internal error: libxenlight failed to create new domain 'trial'
dom0 libvirtd[2932]: 2021-08-05 07:17:38.922+0000: 2963: error : libxlDomainStart:1308 : internal error: libxenlight failed to create new domain 'trial'
dom0 qubesd[2839]: Start failed: internal error: libxenlight failed to create new domain 'trial'

150MB works for me.

What is your “Minimal qube memory:” value in Qubes Global Settings?