Check Point CCVS cheat sheet

A Virtual System (VS) is a software-based independent security gateway instance running on a Virtual System Extension (VSX) gateway; each VS has its own Security Policy, rule base, NAT, VPN, and administrator permissions, but shares the physical hardware and OS.

VSX gateway architecture: the VSX Gateway is the physical appliance or open server; the VSX Management Server (SmartCenter) manages all VSs; each VS is a virtual instance with its own interfaces (Virtual Interfaces) mapped to physical or VLAN interfaces.

A Virtual Switch (VSW) connects VSs to each other and to the external network; VSs on the same VSW can communicate without leaving the appliance; VSW is defined in SmartConsole and mapped to a physical interface or bond.

VSX supports two deployment modes: Virtual System Extension (VSX) on a dedicated gateway, and VSX on a cluster (VSX Cluster) for high availability; VSX Cluster uses ClusterXL with Virtual IPs per VS and per interface.

Each VS has a unique VS ID (1–255) and a unique VS name; VS ID 0 is reserved for the VSX Gateway itself (the management VS); VS IDs must be unique across the VSX cluster.

Virtualization is not the same as a VS: a VS is a Check Point security gateway instance; virtualization platforms (VMware ESXi, KVM) host the VSX gateway as a VM, but VSs inside VSX are Check Point software instances.

VSX requires a VSX license per VS (or a VSX bundle); the VSX Gateway license covers the management VS and the number of VSs; adding a VS beyond the license count is blocked.

VSX gateway interfaces are divided into: Management interfaces (dedicated to the VSX Gateway management VS), Physical interfaces (assigned to VSs as Virtual Interfaces), and VSWs (virtual switches).

VSX supports IPv4 and IPv6; each VS can have its own IPv4/IPv6 addresses and routing table; the VSX Gateway has a global routing table used by the management VS and for VSW connectivity.

Prerequisites for VSX deployment: VSX license installed, VSX Gateway object created in SmartConsole, at least one physical interface free for VSX, and the VSX Gateway configured via the VSX Wizard (vsx_util) or SmartConsole.

VSX Gateway object creation: in SmartConsole, create a Gateway object, set the platform to VSX, select the VSX version, and define the management interface; then run the VSX Wizard on the gateway (vsx_util) to configure the management VS.

Adding a VS: use SmartConsole > VSX > Virtual Systems > New; assign a VS ID, name, and Virtual Interfaces; each Virtual Interface is mapped to a physical interface or VSW; then install policy to the VS.

VSX Wizard (vsx_util) commands: vsx_util (interactive menu) for initial setup, vsx_util reconfigure for re-running configuration, vsx_util add_vs for adding a VS from CLI, vsx_util del_vs for deleting a VS.

Virtual Interface mapping: a VS can have multiple Virtual Interfaces; each Virtual Interface is associated with a physical interface (or bond) and a VLAN ID (optional); the same physical interface can host multiple VSs using different VLANs.

VSX Cluster deployment: create a VSX Cluster object, add both members, configure ClusterXL, define Virtual IPs per VS per interface, and synchronize VS configuration via vsx_util or SmartConsole.

Policy installation to a VS: select the VS object in SmartConsole and install policy; the policy is installed only to that VS; the VSX Gateway management VS policy is installed separately.

VSX configuration backup: use vsx_util or the VSX Gateway backup utility; the VSX configuration is stored in the management database; gateway-side configuration is in /etc/vsx and /var/opt/vsx.

VSX Gateway initial setup requires a reboot after VSX Wizard completion; the management VS (VS0) must be reachable from SmartConsole before adding other VSs.

Each VS has its own Security Policy, NAT policy, and VPN community; policies are independent and can be installed per VS; a VS cannot use another VS's policy.

VSX Management Server (SmartCenter) manages all VSs; administrators can be assigned per-VS permissions using VSX Administrator profiles (e.g., read-only for a specific VS).

Global Policy: a policy assigned to the VSX Gateway object that applies to all VSs; a VS can have a local policy in addition to the global policy; global policy is installed to all VSs at once.

VSX policy installation order: global policy first, then local policy; rule order in the VS rule base: global rules are evaluated before local rules unless the VS is configured otherwise.

NAT in VSX: each VS has its own NAT rule base; NAT is performed per VS; the VSX Gateway itself (VS0) can also perform NAT for management traffic.

VPN in VSX: each VS can be a VPN peer; VPN communities are per VS; VSX supports IPsec VPN with third-party peers; VPN routing is per VS.

Monitoring VSs: use SmartConsole > VSX > Virtual Systems to view VS status; use vsx_stat or cpstat vsx on the gateway to see VS CPU, memory, and connections; SmartView Monitor shows per-VS statistics.

VSX backup and restore: use vsx_util backup and vsx_util restore; the backup includes VS configuration and policies; gateway backup via cpbackup includes VSX configuration.

VSX license management: each VS consumes a VSX license; check license status in SmartConsole > VSX > Virtual Systems; license expiry affects all VSs on the gateway.

VSX troubleshooting tools: vsx_stat (VS status), vsx_util (configuration), cpstat vsx (statistics), fw vsx stat (VS list and status), fw vsx stat -v (verbose), fw vsx stat -l (VS IDs and names).

If a VS fails to start: check VSX license, VS ID conflicts, Virtual Interface mapping errors, and VSX Gateway status; use fw vsx stat to see VS state (up/down).

Policy installation failure to a VS: verify the VS is up, the management VS (VS0) is reachable, the VS has a valid policy, and the VSX Gateway has enough resources; check $FWDIR/log/fwm.elg on the management server.

VSX Cluster failover: if a VS fails on one member, ClusterXL moves the VS to the other member; check ClusterXL status with cphaprob stat and VS status with fw vsx stat; VS failover is per VS, not per gateway.

VSX performance issues: use vsx_stat and cpstat vsx to identify high-CPU VSs; each VS has its own CPU/memory limits; VSX Gateway CPU is shared; use CoreXL and SecureXL per VS.

VSX logging: each VS logs to the management server; logs are tagged with the VS name; use SmartConsole Logs & Monitor and filter by VS; VSX Gateway (VS0) logs separately.

VSX upgrade: upgrade the VSX Gateway management VS first, then the VSs; use vsx_util upgrade; ensure VSX license supports the new version; backup before upgrade.

VSX Gateway reboot: rebooting the gateway restarts all VSs; use vsx_util or the VSX Wizard to stop/start individual VSs; stopping a VS does not affect other VSs.

VSX troubleshooting commands: fw vsx stat, vsx_stat, cpstat vsx, vsx_util, fw ctl pstat (per VS), netstat -rn (per VS routing table), and tcpdump on Virtual Interfaces.