I need to be able to determine and or separate network traffic from non Whoinix VMs for analysis or separation of access based on source IP or other VM specific method that can be pined as static to each VM in question.
Initial goals:
for network resources define permissions/access based on VM IP
analyze traffic differences between multiple VMs to compare results
I have looked into outbound NAT or other networking based configurations and I am coming up short on a path forward.
For clarity, I do not need inbound access, etc. Simply a unique IP on the greater LAN for each VM that would not involve a complex setup such as 802.1x.
An alternate option is to have a router preform NAT between the VM and either sys-firewall or sys-net, etc. This is a bit heavy and resource intensive compared to a rule in the correct location.
Any guidance is appreciated to help me find the right path.
Both sys-firewall and sys-net masquerade forwarded traffic, so your
router idea wont fly.
How will the unique IPs be allocated to sys-net from the greater LAN,
and propagated to the individual qubes?
You can provide alternate nftables rules, and rewrite the routing
tables, but this isnt easy, and effectively subverts the Qubes networking
model.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
One way you can do it, although not pretty, is run proxies (or tunnels) on the LAN for the specific qubes. An HTTP proxy, or SOCKS5 proxy, or Wireguard could work. One way this could look is a qube, immediately upstream to a qube you want to isolate, that sends all traffic through a Wireguard to exit the Wireguard tunnel somewhere on your LAN.
There is no way to do what you’re asking that is elegant, simple (relatively simple), and also has reasonable gaurantees of efficacy. The easiest way would be an HTTP proxy on the LAN and qube-specific firewall rules to only access that proxy and different sets of credentials to use the proxy. However, you probably want to observe more traffic than HTTP. Or maybe an HTTP proxy fits nicely with your constraints and goals.
The proxy approach works very well in some circumstances. The Wireguard approach works best if you want to isolate and observe non-HTTP traffic.
I am looking into options outside Qubes. Elegant does not look like a path.
An external solution may be the simple route. An stunnel from a VM that has a NAT at the other side before sending traffic to the LAN or a destination may get me where I want to be.
Like you, I am hoping to see some elegant solution. My use is to allow tighter firewalling for LAN vs WAN routable VMs.
My own untested ideas, which would require a separate hardware interface, were either:
abandon having a separate but shared NATing sys-firewall, and reimplement sys-net, using ‘ip alias’ to create multiple external IP addresses, directing via each alias according to originating source for each connection. Maybe MirageOS would be useful to keep the total mass under control.
(very DANGEROUS, scary, unadvisable…) to try mangling packet TTL for each qube. I am assuming the Qubes networking does not prevent this by setting a cap on TTL. Individual qubes could subvert simple decrements by setting their own source TTL. Not scalable to many VMs. Could create horrific network storms if used in the wild, outside of Qubes. Would break traceroute, if a fixed value is set.
Hoping for something better.
(side note: I recently discovered that the extremely elegant FireHOL firewalling software is still usable - it would be ideal for managing such a setup… I thought it was iptables-only and had been abandoned.)
My intent is, in part, to isolate or wall off network access based on the idea of a source (vm) security zone. Then allow or deny service and data access based on the VM’s security zone is attempted from. A crude idea now. My hope is to isolate beyond a host to the network and data that resides in a network service.
If there is a cleaner way to do this beyond source IP that is standard across most services, that may be the better path.
One ACL type I am looking at in the file level is tags applied based on source and grant or deny file access based on the same tagging. Think NextCloud Flow.
My thought is maybe a stunnel system with iptables masquerading as an intermediary hop to get some type of POC working.
Ultimately, if a solution that can be configured through Salt Stack, Puppet, etc. could make use of system, file and so on an automated and user invisible solution I would be off to a good start.
I do not see a way for this to be done directly. I might be wrong.
I might also be looking at this from a less or unproductive angle. I am hoping to find how a device, Qubes VM or otherwise, might be differentiated by the context of it’s own (mis)configuration, function and or network location at time of access for effective policy enforcement of an individual user and the services and data that are requested.
But that (in a classic XY problem) was what you first asked for.
I find it difficult to follow what you say here.
Does use of client certificates not already provide policy enforcement
from individual qubes to specific services and data?
In Qubes you could add in use of detailed qvm-firewall rules to restrict
access to network resources to some qubes.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.