Check Point Firewall

The Check Point Management Server should accept API access from the Collector IP address.

You can set up the access from Manage & Settings > Blades > Management API > Advanced Settings.

If Check Point MDS is added as data-source, vRealize Network Insight fetches data from all the user-defined domains and the global domain.

vRealize Network Insight uses Check Point public Web API for fetching the data from the Check Point management server. If the VSX gateway is attached to the management server, we use SSH-based CLI commands to fetch the VSX-managed Virtual System VS routing table to support display of the VS gateway in the VM-VM path.

vRealize Network Insight requires read-only privileges for the Web-API access for fetching most of the Check Point data. There are few exceptions as follows:

• If a non-VSX physical gateway is attached to the management server, the user should have read-write access privileges for the Web API. This is required to fetch the gateway routes for using the run script Web API for the VM-VM path computation.
• If a VSX gateway is attached to the management server, the user should have the SSH access with the same password. In addition, the user should have access to the CLI command vsx_util view_vs_conf. This command is used to fetch the VSX gateway routes for the VM-VM path computation.
• For MDS server IP as data-source, the user should have the Web API access to all domains including the MDS domain and the global domain. It is required to fetch rules, policy packages and other data from all the domains.

You can perform a query for all the Check Point entities that are supported by vRealize Network Insight. All the entities are prefixed by Check Point. Some of the queries for Check Point are as follows:

Table 1.

Entities in Check Point	Keywords	Queries
IPset	Check Point Address Range Check Point Network	vm where Address Range = <> vm where Address Range = <> Check Point Address Range where Translated VM = <>
Grouping	Check Point Network Group	Check Point Network Group where Translated VM = <> vm where Network Group = <>
Service/ Service Group	Check Point Service Check Point Service Group	Check point service where Port = <> Check point service where protocol = <>
Access Layer	Check Point Access Layer	Check Point Policy where Access Layer = <>
Domain	Check Point Domain	check point domain where ip address = <> check point policy where domain = <> check point access layer where domain = <>
Gateways and Gateway Cluster	Check Point Gateway Check Point Gateway Cluster	Check Point Gateway Cluster where Policy Package = <>
Policy Package	Check Point Policy package	Check Point Policy where Policy Package = <> Check Point Policy Package where Rule = <>
Policy	Check Point Policy	Check point policy where source ip = <> and Destination IP = <> Rule where source ip = <> and Destination IP = <> (will display other rules- nsx, redirect along with check point policies in the system)

A sample Check Point Manager dashboard is shown as follows:

In a VM-VM topology diagram, you can see the Check Point Service VMs on a host to signify the Check Point rules applied on the particular traffic. The VSX-managed Virtual System (VS) gateway can be seen in the VM-VM path as a physical gateway. The list of applicable Check Point policies is displayed when you click the gateway icon.

Note: For the VM-VM path, vRealize Network Insight does not support the VSX cluster containing Virtual Switch and Virtual Router.

Here are some scenarios for which the system events are generated for Check Point:

• The NSX fabric agent is not found on the ESX for the Check Point gateway.
• The Check Point service VM is not found.
• The Check point gateway sic status is not communicating.
• The discovery and update events features for the Check Point entities like address range, networks, policies, groups, policy package, service, service group, and so on