- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- CloudGuard NGTX on VMWare ESXi
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CloudGuard NGTX on VMWare ESXi
HI All,
I haven't found a suitable post on the topic of Check Point Sandblast on VMWare ESXi, so here's the question.
In the Gateway Performance Data Sheet of CloudGuard Network Security for VMWare ESXi I only find the performance data for the NGTP version. Is it also possible to run NGTX with acceptable performance on an ESXi server?
For current inquiries we have an internet connection of 100Mbit available.
If so, which ESX configuration (CPU, RAM, disk) would you recommend?
Greetings Stefan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Theoretically sure - How many users will this gateway be protecting?
Note for NGTX license: NGTX cloud inspection quota is 10k files/vcore/month
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Note that hypervisors are really, really bad at arbitrating I/O access, and ESXi isn't an exception. If you want to run a firewall in a VM, you should look into VT-d (a type of IOMMU) to pass a whole physical network card to the VM. I mostly deal with Hyper-V and bhyve lately, so I don't know exactly how this would be set up in ESXi. Specifically, this helps latency. If you can't give a whole network card to the firewall VM, stick with paravirtualized network interfaces (vmxnet3 on ESXi).
For core count, it depends on the processors you use on your VM host. Ideally, you should go for fewer cores with a high turbo and high TDP, then pass some number of cores to the firewall VM. I'm not sure if there are VM-specific licenses, but for open server licenses, the license core count only controls how many cores can contribute to handling traffic. I would give it one or two more cores to ensure it has capacity to handle an interactive shell session or whatever even when fully loaded. Note that you should probably reserve a lot of capacity for this VM on the host to be sure a few other VMs going wild doesn't keep your firewall VM from getting compute time.
RAM isn't restricted by license or anything. For a firewall, I would generally start at 4 GB per core plus 3 GB (so two cores would be 4+4+3 for 11 GB total). This should be fully-reserved, not whatever ESXi calls dynamic memory ballooning. You can always adjust it later after seeing the firewall under load (if 'free -h' shows swapping, add RAM; if you see lots in "Available" after a month up, you can reduce RAM).
My physical firewalls mostly have 480 GB SSDs or 500 GB spinning drives. You can get away with 240 GB, you just won't have as much space for Gaia snapshots. Firewalls don't need a lot of storage performance. They only really hit their disks during boot and policy push. A set of SATA SSDs is fine, and NVMe would be wasted. Note that ESXi snapshots are different from Gaia snapshots, and they slow storage access pretty dramatically. If you want to be able to use ESXi snapshots, you may need faster storage than you think (either a wider SATA array, or NVMe).
![](/skins/images/A53DAF99EDBAFE11A1FC6E62F510C235/responsive_peak/images/icon_anonymous_message.png)