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