> On Jul 2, 2025, at 14:09, Michael van Elst <mlel...@serpens.de> wrote: > > br...@biology.nmsu.edu (Brook Milligan) writes: > > The tap MAC address isn't used in this case, it doesn't have to match.
Good to know. > The bridge itself isn't connected to the host network. You need to > add a host interface to it. Then the bridge will forward traffic > between the tap interface and the host interface. Sorry, I didn’t mention that ixg0 was the host interface. It was on the bridge. > You can also configure a vether interface and add that. This > creates a more isolated guest network together with the host. > This can then be routed to the host network (with or without NAT). The key is that the host needs an address on the bridge in the guest’s subnet so it can route packets. Giving tap0 an IP address works for this. Adding a vether interface to the bridge and giving that an IP address also works. I’m guessing that the latter is better practice, but would appreciate confirmation. Either is enough for the host and guest to communicate directly. Beyond that, the host needs to route packets appropriately, e.g., with npf and NAT (if necessary). >> Also, the host has no route pointing to the tap0 interface. Should = >> there be one? If so, how should it be created? Should there be an IP = >> address on the host tap0 interface? > > Neither. An IP address on the tap interface was used in the past > for the vether scenario above. I’m not sure what “neither” refers to. In my experience testing this, some interface attached to the bridge (either tap or vether) needs an IP address for routing. Thanks for your help. It looks like this is working now. Suggestion: fix Chapter 30 of the Guide to indicate that the tap or preferably (?) the vether interface needs an IP address assigned to it. That was the critical missing information for me. Cheers, Brook
