Easy Qubes firewall for VMs connected to sys-whonix

Community Guides
1

I’ve noticed that the rules set in the Qubes firewall for VMs connected to sys-whonix are completely ignored. All traffic goes through. The Whonix wiki warns about it:

Easy solution: create named disposable sys-whonix-fw based on Debian or Fedora (just like sys-firewall or sys-vpn-fw), then connect your VMs to sys-whonix-fw insteaad of sys-whonix. Now all traffic with be filtered by the Qubes firewall.

EDIT: This even allows for filtering .onion addresses in the Qubes VM firewall (if you don’t mind painstakingly typing an Onion v3 address, since copypasting to dom0 is disabled and discouraged).

1 Like
2

Easy problem - now sys-whonix sees all traffic as originating from the
same IP, which has potential for playing not nicely with stream
isolation.
IsolateClientAddr will be completely broken.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes
3

Good point.

Would this be fixed by creating multiple sys-whonix-fw? Like sys-whonix-fw1, sys-whonix-fw2, etc.

4

@unman

According to this, the situation with IsolateClientAddr in Qubes-Whonix is complicated. At least to me, it is not quite clear if Qubes-Whonix benefits from it at all. What do you think?

You also say:

originating from the same IP

but the firewall forwards traffic, i.e. it is not output chain. So, what do you mean?

5

you could do this, but it will become unwieldy. If you insist I’d
suggest mirage-fw to lighten the load.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

6

Is that not dealing with the specific case of apt and tinyproxy? (The
issue is exactly the same.)

nft list table qubes shows:

chain postrouting {
  type nat hook postrouting priority srcnat; policy accept;
  oifgroup 2 accept
  oif "lo" accept
  masquerade
}

QED

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.
7

Is that not dealing with the specific case of apt and tinyproxy? (The
issue is exactly the same.)

It seems so. And then the question is how is any other HTTP activity different. IOW, if there is no stream isolation for apt, meaning there probably isn’t any for anything else, why should we be careful not to break it.

What is QED?

8

Quod erat demonstrandum.

9

@OvalZero

Thanks.

10

The Whonix folk have no firewall between whonix-workstation and
whonix-gateway, so the issue does not arise. Each qube connecting to
whonix-gateway as netvm will present a separate source IP.
I provide a packaged TorVM at Index of /4.2 that hacks the
nftables to provide a firewalled Tor gateway that supports Qubes firewall.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

11

The Whonix folk have no firewall between whonix-workstation and
whonix-gateway, so the issue does not arise. Each qube connecting to
whonix-gateway as netvm will present a separate source IP.

I understand that. My confusion/reading of the situation is this:

Their doc kind of explains that in Qubes-Whonix there is no IsolateClientAddr at all and the same (or similar) effect is achieved through what you are saying: different source IP addresses (for different client qubes using sys-whonix).

You explain that putting a firewall between client and gateway would result in the same source IP address, i.e. “the Qubes effect” from above will be no more.

Is that correct? If not - what is correct?

I provide a packaged TorVM at Index of /4.2 that hacks the
nftables to provide a firewalled Tor gateway that supports Qubes firewall.

I can’t find it. Could you share a direct link?

12

https://qubes.3isec.org/4.2/pool/main/3/3isec-tor/

13

@kenosen

Thank you.

14

No it’s saying in the context of the Qubes OS template updates proxy, TemplateVMs’ connections don’t benefit from IsolateClientAddr. That’s because - from the perspective of the tor daemon - the “client” opening (to be torified) TCP connections to distro servers is sys-whonix running tinyproxy, not the TemplateVM.

15

Exactly right.
And this is the same context if you intervene a firewall between the
qubes and sys-whonix.
As you’ll see from my TorVM I replicate firewall rules from the firewall
table in to the qubes table on the gateway. That works fine in the
context of Qubes networking/firewall.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

16

Thank you guys for explaining.

If TorVM improves things (along the lines of allowing qubes firewall), why isn’t it submitted to be integrated in Whonix? Or is it?

17

I still can not use this setup. I cloned sys-firewall changed its netvm as sys-whonix, and named sys-whonix-fw. Then applied firewall rules to my client qube (anon-email) as qvm-firewall anon-email .... So the network chain looks like this:

  • anon-email ← sys-whonix-fw ← sys-whonix ← sys-firewall ← sys-net

But when I start my anon-email qube (based on whonix-workstation-17), I can not connect to my mail server, there is no connection at all. I have read and understood IsolateClientAddr problem but still want to apply this setup.

18

I noticed that many times I tinker with Qubes networking, things don’t work until I restart the system. I don’t know why this is. I’m sure it’s possible to run some command in dom0 that would have the same effect.