How easy is it to adapt corridor and allow non torrified VMs like Kicksecure to connect too? Think dealing with captive portals. Per vm network granularity may be bluntly possible by excluding the kvm user group from networking restrictions o ensure no other non tor traffic form the host may happen. This should allow updates via apt-tor to work too.
Corridor on the host not easy at all.
OK I guess next best thing is to permit only debian-tor and kvm groups to connect on the host. Same trick you use for GW.
Not easy either.
On Whonix-Gateway this is possible and for Tor and linux user group
debian-tor because Tor is just a normal application.
For Whonix-Host for KVM this might not be possible by simply only allowing kvm groups to connect to the internet because KVM isn’t an application. It’s inside the kernel and works differently.
For first iteration just a “simple” Whonix host firewall. It doesn’t get any less secure than previously Debian Host + Whonix-Gateway + Whonix-Workstation.
corridor and/or kvm-only outgoing traffic can be considered in a later release.
<devices> <interface type='bridge'> <mac address='00:16:3e:5d:c7:9e'/> <filterref filter='clean-traffic'> <parameter name='IP' value='10.0.0.1'/> </filterref> </interface> </devices>
In this particular example, the clean-traffic network traffic filter will be instantiated with the IP address parameter 10.0.0.1 and enforce that the traffic from this interface will always be using 10.0.0.1 as the source IP address, which is one of the purposes of this particular filter.
That might be helpful. To write iptables rules to express “traffic from Whonix-Gateway is allowed” is would be helpful to have a stable IP or better stable interface name on the host from which traffic is being sent.
IP address might be non-ideal for multiple Whonix-Gateway use case.
“helpful” could mean “required” if there is no other way to distinguish Whonix-Gateway traffic vs other host traffic.
In the case of Whonix GW we already have a static IP configured on eth0 10.0.2.15 so it might be redundant here?
However this is useful for the case of Kicksecure VM which has DHCP to connect on “default”.
Can iptables on the host be configured to to allow outgoing for the Ranges that libvirt uses for its NAT networks?
Sure, you can try the “iprange” module; use it with -m (match) like that: -m iprange --src-range 192.200.300.100-192.200.300.200 for example. Narrow it further with -i [interface] | -o [interface] and -p tcp | -p udp
Oh yes almost forgot, use it in the nat table PREROUTING chain for more versatility: iptables -t nat -A PREROUTING -m iprange --src-range [ip ranges here] --j [ACCEPT, DROP, FORWARD, JUMP etc]
caveats are that make sure the ranges and subnets do not criss cross otherwise iptables becomes confused