Corridor Setup Question

Qubes-Whonix
1

I was reading about corridor and am wondering if this is still useful (corridor wiki is old). IMO you can do the same thing with the qubes firewall cli and the setup below (assuming you are using obfs4 bridges):

sys-net → sys-firewall → sys-whonix

qvm-firewall sys-firewall del --rule-no 0
qvm-firewall sys-firewall add drop
qvm-firewall sys-firewall add --before 0 drop proto=icmp
qvm-firewall sys-firewall add --before 0 drop specialtarget=dns
qvm-firewall sys-firewall add --before 0 accept IP_ADDRESS_BRIDGE_1
qvm-firewall sys-firewall add --before 0 accept IP_ADDRESS_BRIDGE_2
qvm-firewall sys-firewall list

I tested this solution and works fine. Tor control panel is stuck at 5% using entry guards (connection failed) and back to 100% using the whitelisted bridges. Is this setup ok?

2

What does this do?

Why is this needed?

See also:

3

It deletes default rule 0 to accept all traffic (assuming is a new firewall VM with no additional firewall rules configured)

Probably not needed, but since corridor is a fail-safe to protect against potential leaks, better safe than sorry (when I used sys-vpn I configured the firewall the same way). By default, qubes firewall doesn’t block DNS or ICMP traffic.

I think this setup is easier than enabling Qubes Firewall Tab for Qubes-Whonix (it is Advanced users only and does not survive upgrade of the qubes-whonix package)

4

This is unrelated here. Actually will survive update because that was fixed in git.

Where did you read that this is required?

Shouldn’t it be either corridor or Qubes firewall? Because 1 replaces to other.

Do you mean blocking DNS / ICMP to the white listed address?

Or white listed address but DNS / ICMP would still be generally allowed?

5

It is considered by many to be best practice to delete all firewall rules before writing new rules (same way in Debian you do “ufw --force reset”). Not required, but helpful.

Yes, only one (see above). I named the VM sys-firewall but you can name it whatever you want (e.g., sys-whonix-firewall). The thing is to put a firewall VM (clone or create a new one) before sys-whonix and configure the above firewall rules in that firewall VM.

I understand corridor was designed to protect against potential leaks in Whonix workstation. This includes Ping and DNS leaks. To replace Corridor with another Firewall VM you cannot use the QVMM Firewall Tab Settings to configure rules (as recommended in the above linked wiki) you will not be protected, you must use the qubes firewall cli, otherwise DNS / ICMP would still be generally allowed.

Hope it is clear now. Any thoughts?

6

I guess the advantage of corridor is that is makes violations known in logs while using Qubes firewall simply blocks it if it ever was to happen.

I would be careful about this in context of Qubes. → Verify Changed Firewall Rules

If this is really useful, that seems at least like a usability issue. Please check that this has been reported anywhere and if not I suggest a to write a report to make sure you’re on the right track here.

Ok. So no corridor involved here.

How about blocking all UDP?

What about IPv6?

related: add IPv6 support

7

This rule has been reported here and confirmed by unman “These are good”. OP also turns on the disable-dns-server service (qvm-service sys-firewall-VM disable-dns-server on).

https://groups.google.com/g/qubes-users/c/BVEHpukTjzk

All traffic should be blocked with the above firewall rules. If ipv6 is a concern just type this: qvm-features sys-firewall-VM ipv6 “”

But I would like feedback on the above setup. Is anything else needed to block DNS leaks (i.e: disable-dns-server, or any other rule)?

8

2021, old version of Qubes, still using iptables instead of nftables, not specifically talking about qvm-firewall sys-firewall del --rule-no 0. → Not a strong enough source.

What kind of ports are required by Whonix is documented here:

Other than that, this is primarily a Qubes specific question. Whonix doesn’t influence the Net qube (firewall VM) it is connected to. No VM does. If it would, that would be a Qubes design bug.

The question is:

How to restrict connections of a VM to specific IPs only in Qubes?

Best to resolve as per Self Support First Policy for Whonix.