On 21/09/2007, at 11:09 AM, Josh wrote:
Hello there.
We have a bunch of obsd firewalls, 8 at the moment, all working
nice and so forth. But we
need to add about another 4 in there for new connections and
networks, which means more
machines to find room for.
So basically I have been asked to investigate running all these
firewalls in two big boxes, with lots
of NIC's, with a bunch of openbsd vritual machines on them. One
main box for the primary firewalls,
one for the secondary. Each virtual machine getting its own
physical NIC.
Personally I dont really like the idea, I can see things going
wrong, lots of stuff balancing on a
guest os and box.
Can someone please inform me if this is a really bad idea or not,
ideally with some nice reasoning?
I'm going to vote this idea as "really bad" for two reasons.
Considering the technology out there at the moment, I'm going to
guess you're looking at vmware.
As everyone keeps saying, the security and reliability of your
systems now inherits these characteristics from the VM host, and in
some cases, the other guests. I personally can't trust the host after
having worked on OpenBSD drivers (mpi and vic) inside virtual
machines. In the mpi case I do know they took shortcuts in their
emulation of that hardware which required extra tweaks in my driver.
Even worse though, when I was working on vic I used to be able to
crash the host by getting something wrong in the guest.
I don't want a bug in one of the VMs bringing the whole lot down.
Secondly, the performance of your guests aren't going to be as good
as the performance of OpenBSD running directly on the same hardware.
If you look at the path an arbitrary packet takes on the way out of
an OpenBSD firewall its loosely something like (this path be
accurate, but that's not the point): routing table, pf, enqueue,
driver, hardware. If you look at that same packet in a VM: routing
table, pf, enqueue, driver, virtual machine, vm input, vm routing, vm
enqueue, vm driver, hardware. The amount of work per packet increases
so the time taken to deal with a packet goes up, which means that the
hardware can't deal with the same number of packets that a real
OpenBSD install can deal with.
Just my two cents,
dlg