So, what is the correct way to restrict access of a whonix-based qube to specific host(s)?
You should be able to put a firewall qube between the whonix gateway and its clients. Then just use qvm-firewall as usual on the respective client qube you want to restrict.
Possibly there’s already a firewall qube in fron of the whonix hosts by default - I haven’t used it in a while.
Thanks for the link. I will look at it.
(Strangely, I didn’t receive an email notification about your reply, but luckily I noticed it in the forum.)
You should be able to put a firewall qube between the whonix gateway and its clients.
I am not sure I understand what you mean because whonix-ws clients use sys-whonix as netvm (not whonix-gw-16). Are you suggesting:
sys-whonix <-> custom-firewall-qube <-> client
Wouldn’t then firewall rules prevent the client from connecting to sys-whonix?
I hope you can clarify.
That seems to be the standard method, AFAIK.
Not unless you specifically add firewall rules to achieve that effect.
I am not sure I understand what you mean because whonix-ws clients use sys-whonix as netvm (not whonix-gw-16). Are you suggesting:
sys-whonix <-> custom-firewall-qube <-> client
Yes, that’s what I was talking about.
There’s a good point about stream isolation on the previously linked thread though.
I couldn’t get this to work.
Following the proposal, I created the chain:
sys-whonix <-> custom-firewall-qube <-> client-qube
For custom-firewall-qube I simply cloned the default firewall of Qubes OS.
To test, in client-qube I added a single firewall rule, allowing connections only to fsf.org on TCP port 443.
The result is - I can’t connect to any host whatsoever, including the whitelisted one.
DNS resolving doesn’t seem to work either (tor-resolve).
Then I tried with an IP address (resolved through another, unrestricted, qube) - still the same, no connections. nc -zv shows a timeout.
What am I missing?
Does it work if you exclude sys-whonix?
What do you mean by “exclude sys-whonix”?
Network connectivity is restored if I disable the firewall restrictions in the client-qube but that is contrary to the goal.
I thought that maybe it doesn’t work even without sys-whonix in setup:
sys-net <-> custom-firewall-qube <-> client-qube (debian-12)
I’ve tried this myself and with the setup above if I restrict firewall to fsf.org tcp 443 then it works and it resolves subdomains as well. E.g. it works if you curl https://fsf.org and if you curl https://www.fsf.org.
But in this setup:
sys-net <-> sys-whonix <-> custom-firewall-qube <-> client-qube (debian-12)
With the same firewall rules I can curl https://fsf.org but curl https://www.fsf.org is not working.
Not sure what’s happening here.
In case if you’re using Whonix Workstation qube:
sys-net <-> sys-whonix <-> custom-firewall-qube <-> client-qube (whonix-ws-17)
The DNS resolving won’t work because Whonix Workstations don’t use Qubes OS Virtual DNS servers (10.139.1.1, 10.139.1.2) and they assume that they are connected directly to sys-whonix and use the qube gateway IP (assuming it’ll be sys-whonix) as DNS server.
If you edit /etc/resolv.conf in client-qube (whonix-ws-17) and add nameserver 10.139.1.1 then it will resolve domains with dig fsf.org but internet won’t work because it’s configured to connect to sys-whonix directly. You’ll need to look for a way to fix these connections to sys-whonix through custom-firewall-qube.
Maybe just forward in custom-firewall-qube’s firewall all input requests to custom-firewall-qube from qubes connected to it to sys-whonix.
In case if you’re using Whonix Workstation qube:
Yes, that is my case.
If you edit
/etc/resolv.confin client-qube (whonix-ws-17) and addnameserver 10.139.1.1then it will resolve domains …
Why would one de-anonymize oneself this way?
You’ll need to look for a way to fix these connections to sys-whonix through custom-firewall-qube.
I don’t know how to do that. Hence this thread.
Maybe just forward in custom-firewall-qube’s firewall all input requests to custom-firewall-qube from qubes connected to it to sys-whonix.
How do you do that?
You won’t de-anonymize yourself because that’s how Virtual DNS it works.
All incoming connections to DNS port in sys-whonix are redirected to its own DNS server so when connection request from client-qube to 10.139.1.1 is received by sys-whonix it’ll redirect it to its own DNS server and not to some other external DNS server 10.139.1.1.
Well, on second thought this:
Won’t work as well, because if you do this then your Qubes OS firewall restrictions won’t work as well because Whonix Workstation don’t access the external IPs directly, they use tor proxy in sys-whonix instead.
As @adrelanos stated in the topic on Whonix forum linked in the second post in this topic, you can try to use some filtering proxy in custom-firewall-qube but it won’t be easy to do.
Anyway, I think this topic belongs to Whonix forum since it’s more about how Whonix works and not about how Qubes works.
You explain what will not work.
I hope for an explanation about what will work 
Anyway, I think this topic belongs to Whonix forum since it’s more about how Whonix works and not about how Qubes works.
It belongs here because it is about how to do it in Qubes OS. I can also see that same second post in the other forum suggests opening a thread here which is what I have done. That whonix forum thread also links to another thread on this forum and I have read everything in it. So, here we are.
Can you help?
I don’t know much about how Whonix works internally so I can’t help you with that. Only someone who know how Qubes-Whonix networking is done can help here. And it’d be easier to find such people in dedicated Whonix forum category Qubes-Whonix:
Did you consider to make use of Anonymized DNSCrypt somehow instead (me no idea how - waiting for someone to bump in)?
I have been using it for a long time:
That is for clearnet though.
For Whonix I still don’t know what to do.
Well, I probably misread you used only DNSCrypt, not Anonymized DNSCrypt. Sorry.
While the communications themselves are secure, and while the
stateless nature of the DNSCrypt protocol helps against fingerprinting
individual devices, DNS server operators can still observe client IP
addresses.
A common way to prevent this is to use DNSCrypt over Tor or SOCKS
proxies. However, Tor significantly increases the latency of DNS
responses. And public SOCKS proxies are difficult to operate, as they
can easily be abused for purposes unrelated to DNS.
Anonymized DNSCrypt is a simple extension to the DNSCrypt v2 protocol,
allowing queries and responses to be relayed by an intermediate server.
That’s why I thought it might be used/useful.
DNS filtering of particular hosts does not block connection by IP address to that same host. It blocks only resolving.
The goal is not to block resolving but to restrict connections.
Thanks for clarifying.