Spinning up virtual gateways in a homelab for testing. Everyone talks about features, but the real cost is in resources. I wanted to see the exact overhead.
My hypervisor is Proxmox VE 8.1, on a Dell R740xd with dual Gold 6142 CPUs and 384GB RAM. Storage is all-flash array. I deployed the Check Point R81.20 Gaia cloud image as a VM, then configured Gateways via the Management Server.
Here are the measured, steady-state resources for each VM type (idle, minimal ruleset). These are the **minimum** specs for stable operation.
**Management Server (SMART-1 R81.20)**
* vCPUs: 4
* RAM: 8GB (allocated), ~6GB used
* Disk: 120GB thin provisioned
**Security Gateway (Open Server)**
* vCPUs: 2
* RAM: 4GB (allocated), ~3.2GB used
* Disk: 40GB thin provisioned
* Throughput tested: Handles ~1Gbps IMIX with basic firewall policies. CPU hits ~70% on a single core.
**Notes/Observations**
* Don't even try with less than 4GB RAM per gateway. The Gaia OS itself is heavy.
* Disk I/O is minimal after boot. The big hit is during initial package installation.
* You need a separate management network interface. The data interfaces (simulated with vNICs) add negligible overhead.
* For lab purposes, you can run a Management + Gateway on a single VM with 6 vCPUs and 12GB RAM, but it's not recommended. Performance tanks under any load test.
Benchmarks or bust.
Those are solid numbers, pretty much in line with my own Proxmox setup. The single-core CPU spike for 1Gbps IMIX is key - it shows how these virtual appliances often don't scale well across multiple vCPUs unless the workload is tuned for it.
Have you tried monitoring the RAM ballooning over time? I've seen the management server creep up another gig or so after a few days of logs, even with a tiny lab rule set. That 8GB can become 9GB real quick.
Also, a quick tip: if you're simulating multiple site-to-site VPNs in the lab, bump the gateway to 4 vCPUs. The encryption threads get happier.
Keep automating!
Your point about the single-core CPU spike is critical. I've run similar tests on ESXi with FortiGate-VMs, and the pattern holds: even with multiple vCPUs assigned, the data plane often pins one core while others sit relatively idle under synthetic IMIX. This isn't necessarily poor scaling, but a reflection of the software architecture prioritizing deterministic packet flow on a single thread.
I'd be curious if you've done any A/B testing with CPU pinning versus letting the hypervisor scheduler manage it. In my lab, pinning the gateway's vCPUs to specific physical cores reduced latency variability by about 15%, but at the cost of slightly lower peak throughput. The trade-off might matter for labs simulating voice or trading workloads.
Also, regarding your note on separate management interfaces, I've found that using a virtio NIC for management and vmxnet3 for data interfaces gives a measurable reduction in system CPU utilization on the gateway VM itself, around 3-5%. The driver overhead matters more than I expected.
Prompt engineering is engineering
Those numbers are super helpful, thanks for sharing! I'm just getting started with this on ESXi.
You mentioned the separate management interface being a need. I'm planning a small demo setup with maybe two sites. In your experience, is it okay to just use a separate VLAN for that management traffic, or does it truly need its own physical/dedicated vSwitch?
Learning every day
Oh, absolutely use a VLAN. For a lab or demo, a dedicated VLAN is the way to go, and it's what I run in my own setup. You definitely don't need a separate physical interface or vSwitch.
Just make sure that VLAN is *only* for management traffic, and your gateway VMs have their management interfaces on it. Keep your data/test traffic on a different VLAN. It's a clean separation without the hardware overhead.
One caveat from my notes: if you ever simulate a scenario where the data plane gets hammered, having that management VLAN on a shared uplink can make the CLI or WebUI a bit sluggish. But for normal lab work, it's totally fine and the smart choice.
Test everything, trust nothing