Why we do it this way

The whole reason this book exists comes down to one upstream rule: the network only forwards traffic for MAC addresses it has been told about. Bridge a VM with an arbitrary MAC straight onto the public interface and its packets are silently dropped. So you can't treat public IPs the way you'd treat a home LAN — you have to play by the provider's rules.

That's why there are three methods rather than one:

• A single extra IP with a reserved MAC — cheapest and simplest when you just need one or two public-facing VMs. You reserve a MAC for the IP in the provider's panel, and the VM uses it.
• A subnet routed to the host — cleaner once you need several IPs, because the whole block is routed to your server and you stop doing the per-IP MAC dance.
• A vSwitch — the most flexible, and the one that scales to a multi-node cluster (which is exactly where the cluster book picks up).

And why put pfSense in front at all? Because it gives you a single, controlled place to do NAT, routing, and firewalling for everything behind it. The VMs live on a private network; pfSense is the one box that translates between "private lab" and "the public internet."

The mindset: this is the same "one edge, one door" idea the rest of the lab leans on, just one layer lower. Funnel all the VMs' connectivity through one gateway you understand, rather than scattering public IPs across VMs and hoping. Pick the method that matches how many IPs you need — and don't over-engineer with a vSwitch if a single reserved MAC will do.