On Sat, Nov 15, 2025 at 06:56:46PM +0000, H. Hartzer wrote: > Hi misc@, > > I have been working with VMM more lately. It's a real joy to use. Very > simple. > > I'm wondering what a recommended approach would be for potentially > untrusted VMs. It's commonplace, in VPS hosting, to restrict the VM to > its own IPs at the host level. Wouldn't want one server to spoof IPs of > another. > > In this case, I am working with IPv6 and the host has its own /64. I am > wanting to issue /112s to each VM. > > My first test was to put each VM on its own veb and route the /112 out > of the physical ethernet interface. This seems like it would work, in > theory, but the host doesn't respond to icmp6 "who-has"-style requests > for a VM's IP. Thus, the upstream router doesn't know to address traffic > to the host's MAC, and for it to forward it on.
if you only have one tap and one vport interface in the veb, then you don't need the veb or vport. just put the l3 config on the tap interface instead of the vport. network interfaces (like tap) are connected to the ip stack by default. adding an interface to a veb disconnects it from the stack, but then you're adding a vport to connect the tap interface back to the ip stack. i like to think of tap interfaces as a crossover cable between the vm and the hosts ip stack. > I know another approach is to put all on the same bridge interface with > he physical NIC. This is probably more performant. depends on what you want the vm to talk to. i argue this is less important than getting the safety right first though. > I guess in that case, with all VMs on the same veb, I would create tap > interfaces in advance and use pf to filter on the tap interfaces? Or > would that not quite work with the nature of veb? it's ok, there's just a bunch of caveats with running pf against l3 traffic going over a veb, so you need to be careful when you enable it the most important thing to keep in mind is that pf should not run against the same packet twice in the same direction, which happens if you're firewalling on normal veb ports (like tap or a physical interface) and also on vport interfaces (which are special). either skip filtering on vport, or put the veb in another rdomain so pf can tell that the states on the veb are in a different context to ones in the rest of the system (which the vports are considered part of). > VMM does provide a handy way to lock the MAC address at that layer, > which is nice to have that attack surface already covered. this is the other thing to keep in mind. pf does not do much to help constrain/isolate other layer 2 traffic. "locked" can prevent spoofing, but it doesnt provide isolation. > Appreciate any advice you can offer. > > -Henrich >
