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).

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/