[Help Welcome] KVM Development - staying the course

KVM
546

Long standing KVM issue:

VM internal traffic is visible on the host for network sniffers such as wireshark, tshark as well as iptables (and therefore by extension also corridor)

This is an issue because of this corridor (or something similar if invented such as perhaps Whonix-Host KVM Firewall) cannot be used as an additional leak test or Tor whitelisting gateway.

Quote myself from Whonix on Mac M1 (ARM) - Development Discussion - #35 by Patrick

As hubport option might be much more secure similar and also apply to Whonix KVM.

This is very important, needs most attention to get right to avoid IP leaks.

From the UTM config files. Relevant options:

Whonix-Gateway

-device virtio-net-pci,netdev=external
-device virtio-net-pci,netdev=internal
-netdev user,id=external,ipv6=off,net=10.0.2.0/24
-netdev socket,id=internal,listen=:8010

Whonix-Workstation

-device virtio-net-pci,netdev=internal
-netdev socket,id=internal,connect=127.0.0.1:8010

Doesn’t look crazy. Related documentation:
Documentation/Networking - QEMU

But it has the same issue that KVM has. VM internal traffic is visible on the host for network sniffers such as wireshark, tshark.

This has lead in the past to a failure of configuring corridor on a Debian host with Whonix KVM.

references:

GitHub - rustybird/corridor: Tor traffic whitelisting gateway

testing on Debian host · Issue #28 · rustybird/corridor · GitHub

related:
Using corridor, a Tor traffic whitelisting gateway with Whonix ™

So it would be much better if KVM / QEMU (UTM) would hide this from the host operating system. I.e. encapsulate the internal networking better. ChatGPT says this is possible using the hubport option but ChatGPT unfortunately sometimes talkes nonsense. Could you look into it please?

ChatGPT

1 Like