Hello everyone,
I am using Whonix 17 in the KVM environment, and it works very well.
Later, I installed virtual Fedora KVM.
Whonix.Workstation: 10.152.152.11/18
VM Fedora: 192.168.122.139/24
I am trying to connect from Whonix.Workstation to Debian via SSH, but I am receiving an error: Connection refuced
I changed the Fedora IP address to 10.152.152.12/18, but there is still no connection.
It’s a big mystery 
How can I resolve this unexpected issue?
Try normal connectivity test first before trying to use SSH.
See documentation:
Ok, please tell me what you mean by a “normal connectivity”?
If you are trying to SSH into a local VM on your network, you can’t do it in Workstation.
Workstation has no access to your LAN.
You will have to expose your local VM SSH port to the internet to be able to connect to it through the workstation.
[quote=“chadsec, post:4, topic:22017”]
Workstation has no access to your LAN.[/quote]
Of course, I understood this from the very beginning.
[quote=“chadsec, post:4, topic:22017”]
You will have to expose your local VM SSH port to the internet[/quote]
Sorry, but I am not allowed to connect my VM to the Internet.
I need to configure my VM to connect only to Workstation.
To do this, I will probably need to make some changes to my Workstation settings.
But unfortunately, I don’t know what these settings are.
Then what’s the point of asking ?
You can’t expose your LAN to Whonix-workstation without major risky modifications that are unsupported by Whonix.
It’s highly not recommended to do this nor do we support helping with such things, you are on your own.
I agree with you, however this method of yours:
– this method of yours is even more risky, because the data from my confidential VM is will sent to the aggressive Internet.
But my local network is not aggressive, but safe for my data.
This isn’t a discussion about the safest way, I am telling you, you cannot access your LAN through Whonix workstation, this is by design.
You could make Whonix workstation access your LAN but it will require major modifications both in VM and in the VM settings and network configuration.
All of which is unsupported by Whonix. We cannot help you with this.
Hence, the only feasible (and supported) way is if the endpoint you wish to SSH into, is accessible through the internet.
May I ask , why do you even want to SSH into another VM, within Whonix ? Why can’t you just SSH on your host ?
Any other internet connection other than SSH.
clarification:
You run a command such as:
ssh example.com
In that case…
Note: Opening of Ports not required. With certainty.
Do you mean…
Custom Operating System such as Fedora → Whonix-Workstation → Whonix-Gateway?
It’s most likely possible to do this secure but in practice this is undocumented.
Ok, ok, let me answer chadsec first:
I understand you. Well, then I simply ask you to consider this issue for a possible change in Whonix policy to improve its capabilities in the future.
Please familiarize yourself with this typical situation.
There works a VM Windows on the local network, which processes confidential data using unique applications that which are missing for Linux OS.
Windows is a weakly protected OS, so it cannot be given access to the Internet even through a Whonix.Gateway.
The only way to protect Windows from confidential data leakage is to transfer its data to the Internet through an intermediate protective link: Whonix.Workstation + Whonix.Gateway, by first putting this data in Whonix.Workstation.
However, Windows cannot connect to Whonix.Workstation and also vice versa due to Whonix strict policy.
This is a typical situation that is often encountered by users who work on the Internet and want to have reliable protection for their confidential data.
Please consider this petition to solve this problem in the future, and then Whonix will become even better 
Patrick, maybe my answer to chadsec is useful for you as well? If not, please specify.
I am not a developer, @Patrick is.
From what I understand, you have a local VM, you want to SSH into, while being inside Whonix-Workstation.
Currently, this is impossible to do unless you do major configuration edit in how Whonix is networked… But assuming you do this , then there’s no point in using Whonix. You could just install any Linux distro in a VM, torify everything and still be able to access your LAN.
Does this make sense?
There is no feature in Whonix-Workstation (yet? [1]) that blocks
Transparent Proxy Leaks.
The following:
A) Windows → Whonix-Gateway
is equally good as in theory:
B) Windows → Whonix-Workstation → Whonix-Gateway.
[1] I am not sure such a feature would be even possible, secure.
It’s not a policy. I am not against that. It’s just complicated to configure that, because (Linux) networking is complicated. (If it was easy, there would be no reason to ask.)
To add to this: if OP decided to do this. He would need to break the link between Whonix-workstation and Whonix-gateway… which means he would have to both configure stuff inside of the workstation’s VM to work again somehow, and also configure the VM’s (virtualbox) settings to make Whonix-workstation use NAT.
Essentially making Whonix, … not Whonix lol
Was I wrong in saying this is unsupported by Whonix ?
No NAT needed.
eth0: Whonix-Workstation and Whonix-Gateway are connected by an internal network.
eth1 (hypothetical): Whonix-Workstation could get another virtual network card and have another internal network to another VM.
Plus some changes in Whonix-Workstation Firewall - Whonix (or turning it off).
Not wrong at time of writing. It’s unsupported in so far that it is unsupported.
This is however not a part of Declined Feature Requests.
Before turning to you for help on the forum, I tried two solutions to this problem:
You have added even more doubts about solving this problem using SSH.
Well, that leaves us with using KVM’s capabilities for data exchange: the 9p and virtiofs drivers. I tested them as well.
Unfortunately, the 9p driver is outdated and unreliable.
The virtiofs driver has another drawback: it is impossible to connect to the shared directory from two VMs at the same time.
In addition, these drivers have a common drawback: they do not encrypt own connections that transit through the host. Therefore, additional encryption tools must be used, which significantly complicates the system.
Therefore, the best, simplest, and most reliable solution is SSH, which does not work here.
Now I don’t know what to do 