Note: from an infosec view, there is no reason why virtual firewalls are less secure than physical firewalls. Many hybrid environments have physical FWs in the data centres and virtualised FWs in the cloud.
“Yes”
Increased flexibility with scaling up resources
It’s simpler to add memory to a busy FW with many states, or disk space for caching, and so on. In non-HA setups, hot-add can be very advantageous.
Hardware failures become commodity hardware failures
Broken rack mounting ear? That’ll be £149 please! No more – hardware costs are now the same as those for bare metal servers you’re running your hypervisor on.
Speed and cost
The “go to market” is way faster. POC testing makes more sense with VMs too, avoiding annoying vendor hardware trials.
“No”
TCP segmentation offloading (TSO)
The blog’s homepage is 2.4MB in size, but 1492 bytes is a very common MTU for IP packets on the Internet. TCP will carve up the web page into a bunch of segments that eventually must be reassembled.
This can be expensive on the CPU, so often you want to do it on the NIC. While some hypervisors support this, you may struggle with others. CPU priority is a workaround.
Receive segment coalescing (RSC) offloading
This is a network stack performance optimisation to reduce the number of header checks done in a TCP transmission by whacking together many segments and doing fewer checks on bigger coalesced packets. The idea again is to reduce host CPU usage, but can in fact lead to performance degradation on guests. It’s not clear if FreeBSD’s netvsc driver supports Hyper-V vSwitch RSC. So turn this off for now, but bear in mind the higher risk of running a firewall on a box with other busy guests fighting for CPU.
Small sites with just a few servers
Obviously single points of failures arise if a remote site is dependent on a server that may go down for upgrades, patching and so on, which also runs the only entry point to that network (the virtualised firewall).