It would break stream isolation of Whonix-Workstation. What is stream isolation? See:
Therefore you’d have to disable stream isolation. See:
1) VM1 would need to be connected to an internal network with VM2.
2) And VM2 connected with an internal network to VM3.
As for 2) I suggest an easier exercise first: Set up a Whonix-Custom-Workstation with another operating system (such as Debian buster). For that, you can follow this documentation:
Once you’ve mastered that exercise, try the next exercise.
As for 1) I recommend the following exercise. Set up two VMs, VM A and VM B. VM A is connected through an internal network with VM B. Probably good to use Debian stable (currently: buster) in both cases Then configure VM B to do IP forwarding. I.e. learn how VM B can do IP forwarding for VM A. In other words, how to allow VM A to connect through VM B.
VM A -> VM B -> Internet
You might not find VM specific documentation. Doing such as setup with physically separate computers, for example two separate notebooks would be a good exercise. Notebook A connected to notebook B only. Then notebook B doing IP forwarding for notebook A.
IP forwarding is off-topic in Whonix forums for now as we don’t have this documented. It’s unspecific to Whonix.
Thanks for braking it up as well as presenting reading on each step. So far I read the fist link you posted. And can see (on some level) why its not advisable to use gateway with out workstation.
What about nested virtualization? Will that also break stream isolation of Whonix-Workstation? I soposse not becous workstation is used in this configuration and the link withe gateway sould be intact. I ask because this an other option that will might achieve the same end.
For clarity the setup would look like this (using the general terminology ):
L0, -L1, -L2, -L3
L0 is host, L1 is the first operating system ruining in the first virtual box. L2 is whonix workstation that runs on a VM that runs in L1 (of coures gateway also runs in L1), and final L3 (that runs in a VM that runs in L3) is the operating system I intend to use. The lines represent a vm ruing inside the presiding operating system (left to right). By the way L1 connects directly to to the wifi adapter.
I figure this would actually work?
Essentially runing L2 (whonix workstation and gateway) in a virtual box that runs in L1. sould not be different from ruining whionix on a vm that runs in host. L3 runs in whonix workstation with out interfering withe the gateway. I cant see why the integrity of whinix workstation and whinix gateway woud be compromised in this configuration.
Would this approach work?
I guse this deviate from the topic but figured it might be unnecessary to set up a new thread. And besides it would not contain the back ground.
The solution with nested virtualization seams to solve and or make many of the issues so far easier.
Concerning streamisolation I have to read more in order to relay grasp this. But I did find a text in whonix respiratory on streamisolation. It discuses how some applications will not by default be taken in by the general stream isolation provided in whionix workstation. And in order to solve this this proxification for those application are suggested.
If I got it right user is advised use different proxies for eatch application in order to avoid the detection of a common source. Hence reconstructing stream isolation,
I relation to to the problems I accounted in the setup I describe above (Runing a operating system in a vm in whonixworksation). I figure that it in principle is that same problem: Just as whonix cant proxify some application it cant by the same principle proxify other operating systems.
Conclusively what if user would proxify the entire vm that runs in L2 (whonix workstation) in configuration I decribe abow? Would that fix the problem with broken streamisolation?
It doesn’t use the term proxification. It says using a proxifier. Not the same thing.
Usual proxy won’t help. See:
It’s only stream isolated when different applications are pointed to different Tor SocksPorts (or HttpPorts).
No, if a whole VM is routed through Tor as one, then it’s actually not stream isolated. Once you wretch something between the application (running in workstation) and Tor (running on gateway), it can no longer be stream isolated.
Just a shoot in the dark: Will using Qubes solve the problem with of using an other operating system with whonixgatway? I dont know why it would. But how knows…
I suppos this is a whonix qustion.
what I do now is that its possible to connect whonix directly to the network adapter in qubes.
So at least LO, as well as -L1 in the configuration that I would use of I where to run whonix in a VM (L0, -L1, -L2, -L3) will be excluded. That is unrelated to the issues discuses before how ever.
Any way It would be interesting to know if Qubes some how by default fixes the problem with directing the traffic of an other operating system trough whonix?
By the way if using nested virtualization like the setup discuses (L0, -L1, -L2, -L3) must open up for the possibility of using a line of VPN providers as well as different proxis in each individual machine. Probably opening up for a line of unpredictable problems. Jet kind of interesting.
All tough not stream isolation perhaps this will providing very strong security features of this applications (proxy VPN etc) are set up after tor. Perhaps as strong as some of the whonix features.
Any way there supposed to be an isue with tor becous it allows for the possibility of becoming the “end nod” and hence identifiable. Apparently whonix fix this but Is this the same issue as stream isolation? Do sent seam to be the same thing… The former problem (becoming the end node). Seams to be mutch more more serious. Perhaps thats not compromised when running an other operating system trough whonix gateway?
And maby becoming the end nod can be fixt by a succession of VPN and proxy in the VM:s in this setup: L0, -L1, -L2, -L3. Discussed earlier?
About connecting Qubes to secondary wifi adapter: Im referring to whonix gateway. I did read somewhere that this was possible (most likely in reddit). But I have not tried it my self . This might be wrong however. And on second thought it probably is.
Because whonix, in virtual box, connects to the host wifi adapter be default. And Qubes seams “simply” to be an operating system consisting of a number of VM:s runing directly on the hardware not in a virtualization software. So I presume its not reasonable to presume that whonix gateway would behave any differently during this conditions in Qubes than it dose in virtualbox?
Any way at this point Im comfortable with nested virtualization as I see no clear disadvantages (aside from the increased “attack surface” (discuses) hence the problem with connecting directly to the wifi adapter independent of host seams to be fixed.
Perhaps more important : After reading some more stream isolation it seams to be what makes whonix what it is (not some secondarily feature) and this is what unable detection of user as “end nod”?
Hench using this setup L0, -L1, -L2, -L3 (disused earlier) is in principle the same and no more secure than ruining Tor in windows?
Not exactly. VirtualBox uses whatever host internet connection there is. If LAN cable based, it uses that. If WiFi based, it uses that. If both, it uses both.
In Qubes in theory one might have two NetVMs. One using LAN. Another using WiFi. Yet another, another WiFI USB adapter. Each VM could be configured to use a different NetVM / network device. I haven’t tested this but I don’t see how that would help here.
Qubes dom0 is at time of writing based on Fedora. It doesn’t have networking by default but that’s irrelevant here. The difference is smaller than you might assume. Simplified: Qubes dom0 is the host. The VMs running inside a virtualizer named Xen.
I.e. Qubes VMs do run inside a virtualizer.
Stream isolation and proxy between workstation and gateway is similar as far as this forum thread goes. No important differences.
Using Linux, Whonix either way is better than Windows:
When using a Whonix-Workstation routed through a Whonix-Gateway there is a lot less chance of leaks, i.e. connections not going through Tor but using clearnet. At time of writing there have never been any reports of clearnet leaks.
It’s best if the VM is as restricted as possible. If code running in the VM has as little privileges as possible. Hence, there are various initiatives:
Running a virtualizer inside a VM is the opposite of that.
Doing nested virtualization however is something what very few people do. It won’t get half as much attention as Whonix itself. Expecting a VM to run another virtualizer and doing that perfectly without messing up is a real stress test. Virtualization isn’t emulation. I’d suggest to look up both, virtualization and emulation. Compare the both.
I am not sure modern virtualizers are nowadays more secure than pure emulation. (Maybe perhaps not architectural but probably more focus on virtualizer development versus new hardware virtualization features.) Emulation (such as Bochs does) isn’t really viable for Whonix since it’s too slow. Therefore I didn’t look that up. But it makes sense to understand the difference.