Troubleshooting Specific Problems

Cannot Establish SIC Trust for VSX Gateway or VSX Cluster Member

When creating a VSX Gateway Physical server that hosts VSX virtual networks, including all Virtual Devices that provide the functionality of physical network devices. It holds at least one Virtual System, which is called VS0. or VSX Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. Cluster Member Security Gateway that is part of a cluster., you cannot establish SIC Secure Internal Communication. The Check Point proprietary mechanism with which Check Point computers that run Check Point software authenticate each other over SSL, for secure communication. This authentication is based on the certificates issued by the ICA on a Check Point Management Server. trust. SmartConsole Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on. shows an error message:

Certificate cannot be pushed. Connection error with wait agent.

Possible Causes	How to Resolve
Check that you have network connectivity between the VSX Gateway and Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. by pinging from the VSX system (a ping from the Management Server to the VSX Gateway will not work because of the default security policy Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. installed on the VSX Gateway / VSX Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Member). Make sure the context is `vrf 0` first.	On all applicable machines, re-check the cables, routes, IP addresses and any intermediate networking devices (routers, switches, hubs, and so on) between the Management Server and the VSX Gateway.
Check that all the Check Point processes on the VSX Gateway(s) are up and running by running `cpwd_admin list` and making sure each line has a non-zero value in the `PID` field.	If the VSX Gateway just rebooted, the Check Point processes might still be coming up.
Check that the CPD process is listening to the trust establishment port.	Run the "`netstat -an \| grep 18211`" command on the VSX Gateway, and make sure that output looks like this: `tcp 0 0 0.0.0.0:18211 0.0.0.0:* LISTEN`

Possible Causes

How to Resolve

Check that you have network connectivity between the VSX Gateway and Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. by pinging from the VSX system (a ping from the Management Server to the VSX Gateway will not work because of the default security policy Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. installed on the VSX Gateway / VSX Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Member).

Make sure the context is vrf 0 first.

On all applicable machines, re-check the cables, routes, IP addresses and any intermediate networking devices (routers, switches, hubs, and so on) between the Management Server and the VSX Gateway.

Check that all the Check Point processes on the VSX Gateway(s) are up and running by running cpwd_admin list and making sure each line has a non-zero value in the PID field.

If the VSX Gateway just rebooted, the Check Point processes might still be coming up.

Check that the CPD process is listening to the trust establishment port.

Run the "netstat -an | grep 18211" command on the VSX Gateway, and make sure that output looks like this:

tcp 0 0 0.0.0.0:18211 0.0.0.0:* LISTEN

SIC Trust Problems with New Virtual Devices

When creating a new Virtual System Virtual Device on a VSX Gateway or VSX Cluster Member that implements the functionality of a Security Gateway. Acronym: VS., Virtual Router Virtual Device on a VSX Gateway or VSX Cluster Member that functions as a physical router. Acronym: VR. or Virtual Switch Virtual Device on a VSX Gateway or VSX Cluster Member that functions as a physical switch. Acronym: VSW., you cannot establish SIC trust.

Possible Causes	How to Resolve
Time or time zone mismatch between the Management Server and the VSX Gateway. For proper SIC operation, the time, date and time zone must be synchronized between the Management Server and Gateways/ VSX Cluster Members. Execute the "`/bin/date -u`" command on all machines, to obtain the correct UTC/GMT time. The machines can be in different time zones, as long as their UTC/GMT times match.	Change the time, date and time zone on the Management Server and/or the VSX Gateway, so that their UTC/GMT times match. Refer to your operating system documentation for the exact commands needed to accomplish this.

Possible Causes

How to Resolve

Time or time zone mismatch between the Management Server and the VSX Gateway.

For proper SIC operation, the time, date and time zone must be synchronized between the Management Server and Gateways/ VSX Cluster Members.

Execute the "/bin/date -u" command on all machines, to obtain the correct UTC/GMT time. The machines can be in different time zones, as long as their UTC/GMT times match.

Change the time, date and time zone on the Management Server and/or the VSX Gateway, so that their UTC/GMT times match. Refer to your operating system documentation for the exact commands needed to accomplish this.

Install Policy Error Using VSX Creation Wizard

After completing the VSX creation wizard, a failure occurs and the following message appears in the Operation Report window:

Error: Default policy installation failed on VSX. Install policy manually using SmartConsole.

Possible Causes	How to Resolve
Missing or invalid license on the Management Server. Execute `cplic check` on the Management Server to make sure that you have the required licenses.	Obtain and install the appropriate licenses.
Missing or invalid VSX Gateway / VSX Cluster licenses. Run the "`vsx stat`" command on the VSX Gateway, and make sure that the number is greater than 0 (zero) in the output: `Number of Virtual Systems allowed by license:`	Obtain a VSX and install a valid license for each VSX Gateway / VSX Cluster Members.
Time or time zone mismatch between the Management Server and the VSX Gateway. For proper SIC operation, the time, date and time zone must be synchronized between the Management Server and the VSX Gateway / VSX Cluster Members. Execute the `/bin/date -u` command on all machines, to obtain the correct UTC/GMT time. The machines can be in different time zones, as long as their UTC/GMT offsets match.	Change the time, date and time zone on the Management Server and/or the VSX Gateway / VSX Cluster Members, so that their UTC/GMT offsets match. Refer to your operating system documentation for the exact commands needed to accomplish this.

Possible Causes

How to Resolve

Missing or invalid license on the Management Server.

Execute cplic check on the Management Server to make sure that you have the required licenses.

Obtain and install the appropriate licenses.

Missing or invalid VSX Gateway / VSX Cluster licenses.

Run the "vsx stat" command on the VSX Gateway, and make sure that the number is greater than 0 (zero) in the output:

Number of Virtual Systems allowed by license:

Obtain a VSX and install a valid license for each VSX Gateway / VSX Cluster Members.

Time or time zone mismatch between the Management Server and the VSX Gateway.

For proper SIC operation, the time, date and time zone must be synchronized between the Management Server and the VSX Gateway / VSX Cluster Members.

Execute the /bin/date -u command on all machines, to obtain the correct UTC/GMT time. The machines can be in different time zones, as long as their UTC/GMT offsets match.

Change the time, date and time zone on the Management Server and/or the VSX Gateway / VSX Cluster Members, so that their UTC/GMT offsets match.

Refer to your operating system documentation for the exact commands needed to accomplish this.

Internal Host Cannot Ping Virtual System

After defining a Virtual System with an internal VLAN interface, an internal host on that VLAN cannot ping the Virtual System internal or external IP address.

Possible Causes	How to Resolve
A policy allowing the communication was not installed on the Virtual System. Note that after creating a Virtual System, it has a Default Policy that blocks all traffic.	Install a policy on the Virtual System that enables the traffic. In SmartConsole Logs & Monitor view, analyze the logs to make sure that the Virtual System allows the traffic.
There is the VLAN configuration problem on a switch, or physical cable problem.	Check the switch configuration. Make sure that VLAN tag configured on the switch is the same as used for the Virtual System VLAN interface. Check the cables, and make sure that you have plugged the cable from the switch to the correct port on the VSX Gateway / VSX Cluster Members.
Incorrect routing on adjacent routers or hosts.	Check the routing tables on intermediate routers and hosts. You can use the `tcpdump` command on the applicable VLAN interface on the VSX Gateway / VSX Cluster Members to make sure that the traffic arrives to and leaves the VSX Gateway / VSX Cluster Members.
Incorrect IP address or net mask defined on the Virtual System VLAN interface.	Check the IP address and the net mask assigned to the Virtual System internal VLAN interface.

Re-establishing SIC Trust with Virtual Devices

In the event you encounter connectivity problems due to the loss of SIC Trust for a specific Virtual Device Logical object that emulates the functionality of a type of physical network object. Virtual Device can be on of these: Virtual Router, Virtual System, or Virtual Switch. (Virtual System or Virtual Router), you can use the procedure below to manually re-establish the SIC trust.

To manually re-establish SIC Trust with a Virtual Device:

Follow the instructions in the sk34098.

On the VSX Gateway or each VSX Cluster Member:

Connect to the command line the VSX Gateway or each VSX Cluster Member.
Log in to the Expert mode.

Examine the VSX configuration to determine the ID of the Virtual Device:

vsx stat -v

Reset the SIC with the specified Virtual Device:

vsx sic reset <VSID>

On the Management Server:

Connect to the command line the Management Server.
Log in to the Expert mode.

On the Multi-Domain Server Dedicated Check Point server that runs Check Point software to host virtual Security Management Servers called Domain Management Servers. Synonym: Multi-Domain Security Management Server. Acronym: MDS., change the context to the applicable Target Domain Management Server that manages the Virtual Device:

mdsenv <IP Address or Name of Domain Management Server>

Determine the SIC name of the Virtual Device:

cpca_client lscert -stat valid -kind SIC | grep -i -A 2 <Name of Virtual Device Object>

Revoke the SIC certificate of the Virtual Device:

cpca_client revoke_cert -n <CN=...,O=...,>

Connect with SmartConsole to the Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server. or Main Domain Management Server that manages the VSX Cluster.
From the Gateways & Servers view or Object Explorer, double-click the Virtual Device object.
Click OK.

This action creates a new SIC certificate for the Virtual Device and saves it on the VSX Gateway or each VSX Cluster Member.