As mentioned a bridge is the virtual equivalent of a switch. It only really
makes sense to have more than one bridge if you have more than one
interface on your guest(s), and want to connect those interfaces to
separate networks. (Or you want some guests on a different network,
possibly bridged to a different physical interface).

If you want to provide complete network separation between guests, it's
much easier to just use the 'private' option to ifconfig when bridging the
guest's tap interface. Any bridge member set to private can not talk to any
other private bridge member. Of course this is only really applicable in
multi-tenant situations like Aryeh says. If they are all your own guests,
the fact that they can see each other on the network should hopefully be a
non-issue.

Matt

On Thu, 29 Dec 2016 at 15:26, Aryeh Friedman <aryeh.fried...@gmail.com>
wrote:

> On Thu, Dec 29, 2016 at 10:19 AM, Vincent Olivier <vinc...@up4.com> wrote:
>
>
>
> > Hi!
>
> >
>
> > > Use the same bridge but a different tap (each tap represents the
> virtual
>
> > equivalent of a NIC where the bridge is the virtual equivalent of a hub)
>
> >
>
> >
>
> > Thanks! This is very clear. For extra isolation, could I use a new bridge
>
> > too or is that useless?
>
> >
>
>
>
> Yes but it only makes sense in a multi-tenant (aka cloud provider) setup
>
> because any attacker on a VM should be assumed to able to get into the host
>
> due to knowing your password (which typically is not all that different on
>
> the two machines unless you randomly generated it).
>
>
>
> --
>
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>
> _______________________________________________
>
> freebsd-virtualization@freebsd.org mailing list
>
> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>
> To unsubscribe, send any mail to "
> freebsd-virtualization-unsubscr...@freebsd.org"
>
>
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Reply via email to