|
|
|
In This Section: |
This chapter shows you how to use SmartDashboard to provision, configure and manage virtual devices in a VSX environment.
If you define or configure VSX objects in a Multi-Domain Security Management deployment: open the SmartDashboard of the Domain Management Server that manages the virtual devices. The Multi-Domain Security Management chapter explains these procedures.
To configure virtual devices, make sure that these preparations are ready:
This chapter assumes that you are familiar with SmartDashboard and how to configure standard Security Gateway objects and security policies. Many virtual device and policy operations are the same as physical Security Gateways and these standard procedures are not in this Administration Guide.
This chapter explains how to use SmartDashboard provision, configure and manage virtual devices in a VSX environment.
If you define or configure VSX objects in a Multi-Domain Security Management deployment: open the SmartDashboard of the Domain Management Server that manages the virtual devices. The Multi-Domain Security Management chapter explains these procedures.
To configure virtual devices, make sure that these preparations are ready:
This chapter assumes that you are familiar with SmartDashboard and how to configure standard Security Gateway objects and security policies. Many virtual device and policy operations are the same as physical Security Gateways and these standard procedures are not in this Administration Guide.
Defining and installing security policies on a VSX gateway or Virtual System is the same as on a physical Security Gateway. Therefore, these procedures are not presented in this Administration Guide.
Important - The Revision Control feature is not supported when the Security Management Server database contains VSX objects. You must not select the Create database version option in SmartDashboard when you install a policy.
This section explains how to create a new VSX Gateway using the VSX Gateway Wizard. After you complete the VSX Gateway Wizard, you can change the VSX Gateway definition from SmartDashboard. For example, you can add or delete interfaces, or configure existing interfaces to support VLANs.
To start the VSX Gateway wizard:
If you are using Multi-Domain Security Management, open SmartDashboard from the Domain Management Server of the VSX Gateway.
The General Properties page of the VSX Gateway Wizard opens.
The General Properties page contains basic identification properties for VSX Gateways.
The Creation Templates page lets you provision predefined, default topology and routing definitions to Virtual Systems. This makes sure Virtual Systems are consistent and makes the definition process faster. You always have the option to override the default creation template when you create or change a Virtual System.
The default Creation Templates are:
If the default templates are not appropriate, you can create a custom configuration:
Initialize Secure Internal Communication trust between the VSX Gateway and the management server. The gateway and server cannot communicate without Trust.
When you create a VSX Gateway, you must enter an Activation Key. Enter and confirm the activation key and then click Initialize. If you enter the correct activation key, the Trust State changes to Trust established.
If SIC trust was not successfully established, click Check SIC Status to see the reason for the failure. The most common issues are an incorrect activation key and connectivity problems between the management server and the VSX Gateway.
Troubleshooting to resolve SIC initialization problems:
cpconfig utility to re-initialize SIC. After this process completes, click Reset in the wizard and then re-enter the activation key.For more about resolving SIC initialization, see the R76 Security Management Administration Guide.
In the VSX Gateway Interfaces window, define physical interfaces as VLAN trunks. The page shows the interfaces currently defined on the VSX Gateway.
To define an interface as a VLAN trunk, select VLAN Trunk for the interface.
If you chose the Custom Configuration option, the Virtual Network Device Configuration window opens. In this window, define a virtual device with an interface shared with the VSX Gateway. If you do not want to define a virtual device at this time, click Next to continue.
To define a virtual device with a shared interface:
Do not select the management interface if you want to define a Dedicated Management Interface (DMI) gateway. If you do not define a shared virtual device, a DMI gateway is created by default.
Important - This setting cannot be changed after you complete the VSX Gateway Wizard. If you define a non-DMI gateway, you cannot change it to a DMI gateway later.
These options are not available for a Virtual Switch.
In the VSX Gateway Management window, define security policy rules that protect the VSX Gateway. This policy is installed automatically on the new VSX Gateway.
Note - This policy applies only to traffic destined for the VSX Gateway. Traffic destined for Virtual Systems, other virtual devices, external networks, and internal networks is not affected by this policy.
The security policy consists of predefined rules for these services:
Click Next to continue and then click Finish to complete the VSX Gateway wizard.
This may take several minutes to complete. A message shows successful or unsuccessful completion of the process.
If the process ends unsuccessfully, click View Report to see the error messages. See the Troubleshooting chapter.
For example, to be able to ping the gateway from the management server, allow ICMP echo-request traffic.
The default value is *Any. Click New Source Object to define a new source.
Use the VSX Gateway Conversion wizard in SmartDashboard to convert Gaia Security Gateways to VSX Gateways. You can convert one Security Gateway or all the members of a cluster to VSX. The settings of the Security Gateways are applied to the VSX Gateway (VS0). You can also use SmartDashboard to convert a VSX Gateway to a Security Gateway.
We recommend that you go to sk79260, before you use the Conversion wizard. You can only convert Security Gateways or clusters that use the Gaia operating system.
|
Note - The Security Gateway loses connectivity during the conversion process. |
SmartDashboard converts a Security Gateway or cluster to VSX. You can only complete the Conversion Wizard if the features and settings of the Security Gateway or cluster are compatible with VSX.
When the Conversion Process window is shown, you cannot cancel or close the Conversion Wizard.
To convert a Security Gateway:
The compatibility check makes sure that the Security Gateway or cluster is compatible with VSX.
The Converting window shows as the management database is updated.
|
Note - You cannot use SmartDashboard while the Converting window shows. |
The VSX Gateway Conversion Wizard cannot convert a Security Gateway or cluster that uses Software Blades or other features that VSX does not support. The wizard automatically checks for common compatibility problems with the Security Gateway. We recommend that you go to sk79260, to see a full list of limitations and compatibility problems.
If the Security Gateway is not compatible, the Compatibility Check window tells you the solution for each compatibility problem. Close the wizard, disable the unsupported features, and run the VSX Gateway Conversion Wizard again.
Complete the Security Gateway to VSX Gateway Conversion Wizard. When you complete the wizard, the management database is updated with the new VSX Gateway object.
To complete the Conversion Wizard:
Click Finish. The Converting window is shown as the management database is updated.
|
Note - You cannot use SmartDashboard while the Converting window is shown. |
SmartDashboard converts a VSX Gateway or cluster to a Security Gateway. You must remove all the Virtual Systems and other virtual devices from the VSX object before you can convert the VSX Gateway.
You cannot convert a VSX Gateway that uses a shared interface configuration to a Security Gateway.
To convert a VSX Gateway to a Security Gateway:
From the Network Objects tree, right-click each virtual device object and select Delete.
A confirmation window opens.
The VSX Gateway is converted to a Security Gateway.
|
Note - You cannot use SmartDashboard while the Converting window is shown. |
A VSX gateway is a physical machine that serves as a container for Virtual Systems and other virtual network components. This section has step-by-step procedures for creating and configuring standalone VSX gateways.
After you create a VSX Gateway, you can modify the topology, other parameters, and advanced configurations in the VSX Gateway Properties window. To open this window, double-click on the VSX Gateway object in SmartDashboard. The VSX Gateway Properties window opens, showing the General Properties page.
In the General Properties page, check and re-establish SIC trust, and activate Check Point products for this VSX Gateway.
You can change these properties:
You can test and reset SIC trust and also see the VSX Gateway Relative Distinguished Name.
To initialize SIC trust:
The VSX Gateway Properties window opens.
The Trusted Communication window opens.
Note - If you cannot establish trust, click Test SIC Status to see the reason for the failure. The most common issues are an incorrect activation key and connectivity problems between the management server and the VSX Gateway.
To reset SIC trust with the VSX Gateway:
cpconfig utility to re-initialize the SIC.VS0 only.cpstop;cpstart Select the Check Point Software Blades to install on this VSX Gateway from the list. The items you see are available for the product version and your license agreement.
The Creation Templates page displays the creation template used to create the Virtual Systems for this VSX Gateway. You can change from the current creation template to the Custom Configuration template and change the shared physical interface if the Shared Interface template is active.
The Physical Interfaces page lets you add or delete a physical interface on the VSX Gateway, and to define a VLAN trunk.
The Topology page contains definitions for interfaces and routes between interfaces and virtual devices.
The Interfaces section defines interfaces and links to devices. You can add new interfaces, and delete or modify existing interfaces.
To add an interface:
The Interface Properties window opens.
Click Actions > Copy to Clipboard to copy the Interfaces table in CSV format.
The Routes section of the Topology window defines routes between network devices, network addresses, and virtual devices. Some routes are defined automatically based on the interface definitions. You can add new routes as well as delete and change existing routes.
To add a default route to the routing table:
The Default Gateway window opens.
The default route is added to the routing table.
The Route Configuration window opens.
To add a new route to the routing table:
The Route Configuration window opens.
To change a route:
The Route Configuration window opens.
To delete a route:
A confirmation window opens.
Select the Calculating topology automatically based on routing information option to let VSX automatically calculate the network topology based on interface and routing definitions. When enabled, VSX creates automatic links, or connectivity cloud objects linked to existing internal or external networks.
|
Note - If you wish to enable Anti-Spoofing protection when there are no routes pointing to internal networks, disable the Calculating topology automatically based on routing information option. Modify the appropriate interface definitions to enable Anti-Spoofing. |
When you delete a VSX Gateway object, the system automatically deletes all Virtual Systems and other virtual devices associated with that gateway from the management database.
To delete a VSX Gateway:
In the event of a catastrophic VSX Gateway failure, you can use the vsx_util command to restore the VSX Gateway configuration as well as its virtual device configuration.
To restore a VSX Gateway configuration:
vsx_util reconfigure.This section presents procedures for creating and configuring Virtual Systems. The Virtual System definition process varies somewhat according to the template selected when creating the VSX Gateway.
A typical Virtual System contains two interfaces:
VSX supports up to 64 interfaces per virtual device and a total of up to 4096 interfaces per gateway or cluster. The supported interfaces include VLANs and Warp Links.
You can add as many interfaces to a Virtual System as required by your environment, subject to system resource limitations.
The following illustration illustrates an example of a typical VSX Gateway deployment with four Virtual Systems, each containing two interfaces.
You use the Virtual Systems Wizard to create a new Virtual System. Modify the initial definition and configure advanced options after you complete the wizard.
To start the Virtual System wizard:
If you are using Multi-Domain Security Management, open SmartDashboard from the Domain Management Server in which you are creating the Virtual System.
The Virtual System Wizard opens.
The General Properties wizard page defines the Virtual System object and the hosting VSX Gateway.
These are the parameters in this page:
The Virtual System Network Configuration page allows you to define internal and external interfaces as well as the IP address topology located behind the internal interface. The process for Virtual System defining network properties varies according to the several factors:
Note - Bridge mode is not available for a Virtual System created with the Shared Interface template.
The Virtual System Network Configuration page for the Shared Interface and Separate Interfaces templates appears as shown.
To configure the external and internal interfaces:
The Virtual System Network Configuration page for the Separate Interfaces template in the Bridge Mode appears as shown.
To configure the external and internal interfaces:
If the selected Interface is a VLAN interface, enter the same VLAN tag in both the external and internal VLAN Tag fields. This field is not available for non-VLAN interfaces.
|
Note - When creating a Virtual System in the bridge mode on an IPSO cluster, you must enable Layer-3 bridge interface monitoring. The IP address to be monitored should reside on a different subnet than the one that handles bridge traffic. |
If you used the Custom Configuration template when creating the VSX Gateway, or if you selected the Override Creation Template option, it is necessary to manually define the network interfaces and connections. The Virtual System Network Configuration page for Custom Configuration appears as shown:
To configure the external and internal interfaces:
To add an interface, click Add. The Interface Properties window opens. Select an interface from the list and define the appropriate properties. Click Help for details regarding the various properties and options.
To make your external IP address routable, select the external interface IP address as the main IP address.
For example, you would generally define a default gateway route leading to an external Virtual Router or to the Virtual System external interface.
To add a default route to the Routes table, click Add Default Routes and either enter the default route IP address or select the default Virtual Router. The Route Configuration window opens. Click Help for details regarding the various properties and options.
If you used the Custom Configuration template when you created the VSX Gateway, or if you selected the Override Creation Template option, and are creating a Virtual System in bridge mode, manually define the network interfaces.
Click Next and then Finish to create the Virtual System. Please note that this may take several minutes to complete. A message appears indicating successful or unsuccessful completion of the process.
If the process ends unsuccessfully, click View Report to view the error messages. Refer to the troubleshooting chapter for further assistance.
Once you create a Virtual System using the Virtual System Wizard, you can modify the topology and all other parameters using the Virtual System Properties window.
Once you create a Virtual System using the wizard, you can modify the topology and other properties using the Virtual System General Properties window.
To modify a Virtual System:
From the Network Objects tree, double-click the Virtual System object. The Virtual System General Properties window opens.
The General Properties page lets you specify the main IP address and to enable various Check Point products for a Virtual System.
The Topology page contains definitions for Virtual System interfaces, routes and Warp Links. Based on these interface settings, VSX automatically creates routes to virtual devices and the VSX Gateway.
|
Note - If you modify the topology for a specific Virtual System in a cluster environment, the cluster topology is not updated until you install a policy on that Virtual System. |
To add an interface, click New and select one of these options:
The Interface Properties window opens. Select the interface from the list and define the appropriate properties. The Modifying an Interface Definition section and the online help provides explanations of the various properties and options.
Click Actions > Copy to Clipboard to copy the Interfaces table in CSV format.
When including a virtual device as part of a VPN connection, you must specify a VPN Domain. The domain definition specifies Virtual System interfaces that are included in the VPN. You can define a VPN Domain in one of two ways by enabling the appropriate option:
The NAT > Advanced page lets you configure NAT rules for packets originating from a Virtual System.
To enable and configure NAT for a Virtual System:
or
To delete a Virtual System, right-click the appropriate Virtual System object on the Object Tree and select Delete. Click Yes in the confirmation box.
Virtual Switches provide level-2 connectivity between Virtual Systems and internal or external networks. This section describes how to define and configure a Virtual Switch. As with physical switches, each Virtual Switch maintains a forwarding table containing entries that describe known networks and directions for reaching them.
You can define Virtual Switches for external and internal communications.
This figure shows a typical deployment using a Virtual Switch for external connections and a VLAN trunk leading to the internal, protected network.
Once you create a Virtual Switch using the wizard, you can modify the topology and other properties using the Virtual Switch General Properties window.
To modify a Virtual Switch:
From the Network Objects tree, double-click the Virtual Switch object. The Virtual Switch General Properties window opens.
The General Properties page allows you to add comments and change the icon color as displayed in SmartDashboard.
The Topology page defines Virtual Switch interfaces. You can only modify the single defined interface. Warp interfaces cannot be modified from this window.
To add an interface, click New. The Interface Properties window opens. Select an interface from the list and define the IP address, net mask and other properties as required.
Click Actions > Copy to Clipboard to copy the Interfaces table in CSV format.
Refer to the Modifying an Interface Definition section or the online help for details regarding the various properties and options.
Remove all Virtual System connections before you delete a Virtual Switch.
To delete a Virtual Switch, right-click the appropriate Virtual Switch object in the Object Tree and select Delete. Click Yes in the confirmation box.
Use the Virtual Switch Wizard to create a new Virtual Switch. You can modify the initial definition and configure advanced options after completing the wizard.
To create a new Virtual Switch:
If you are using Multi-Domain Security Management, open SmartDashboard from the Domain Management Server in which you are creating the Virtual Switch.
The General Properties page of the Virtual Switch Wizard opens.
The Add Interface window opens.
This section describes how to define and configure a Virtual Router. As with physical routers, each Virtual Router maintains a routing table containing entries that describe known networks and directions on how to reach them.
You can define Virtual Routers for both external and internal communications. A Virtual Router that connects to external networks, including a DMZ and the Internet, are referred to as an external Virtual Router. A Virtual Router that connects to internal, protected networks is known as an internal Virtual Router.
An external Virtual Router functions as the external gateway for Virtual Systems, allowing them to share a single secure physical interface leading to external networks and the Internet.
In this scenario, VSX creates Warp interfaces between the Virtual Systems and both Virtual Routers. Note that the external Virtual System interfaces are defined as unnumbered interfaces.
An internal Virtual Router typically connects with one interface leading to internal networks through a switch with additional Warp Links leading to other Virtual Systems located in the VSX Gateway.
After you create a new Virtual Router, add new interfaces to the Virtual Systems to connect to the Virtual Router.
Use the Virtual Router Wizard to create a new Virtual Router. You can modify the initial definition and configure advanced options after you complete the wizard.
On interfaces and routes, you can select the Propagate route to adjacent virtual devices option to broadcast the IP address to neighboring virtual devices. This option enables connectivity with these virtual devices.
To create a Virtual Router:
If you are using Multi-Domain Security Management, open SmartDashboard from the Domain Management Server in which you are creating the Virtual System.
The General Properties page of the Virtual Router Wizard opens.
The Add Interface window opens.
The Route Configuration window opens.
Once you create a Virtual Router using the wizard, you can modify the topology and other properties using the Check Point Virtual Router window. This window also allows you to configure many advanced features and options that are not available in the wizard.
To work with a Virtual Router definition, double-click the Virtual Router object in the Object tree. The Check Point Virtual Router window opens, displaying the General Properties page.
The General Properties page enables you change the Virtual Router IP address as well as to add comments and change the icon color as displayed in SmartDashboard.
The Virtual Router Network Configuration page defines the network topology for the Virtual Router. For an external interface, you define one or more shared external interfaces and a default gateway.
Topology is defined by these properties:
To add an interface, click New. The Interface Properties window opens. Select an interface from the list and define the IP address, net mask and other properties.
You cannot delete a Virtual Router if it is still connected to a Virtual System. Remove all Virtual Router connections before deleting.
To delete a Virtual Router, right-click the appropriate Virtual Router object on the Object Tree and select Delete. Click Yes in the confirmation box.
Source-based routing directs traffic to a specific destination based on the source IP address or a combination of the source and destination IP addresses. Rules defining Source-based routing take precedence over ordinary destination-based routing rules.
This section describes how to configure sourced-based routing rules when working in a VSX environment. The procedures for defining source-based rules are the same for Virtual Routers in both VSX Gateways and VSX clusters.
Define Source-based Routing rules in the Topology page of the Virtual Router definition window.
To define source-based routing rules:
The Advanced Routing Rules window opens.
Note: The highlighted rule is based on a source and a destination address, as compared to the preceding rules, which are based on a source address only.
The Add/Edit Route Rule window opens.
Define the properties:
Use the Advanced Routing Rules window to define source-based routing rules.
To define source-based routing rules:
The General Properties window opens.
From the navigation tree, select Topology.
The Advanced Routing Rules window opens.
The Add/Edit Route Rule window opens.
CoreXL creates multiple firewall instances that are, in reality, independent firewalls. You can use CoreXL to increase the performance of the VSX Gateway on an open server or appliance with multiple cores. You can also assign each instance to a group of CPU cores with the fw ctl affinity command.
You configure firewall instances differently for the VSX Gateway (VS0) than for other Virtual Systems.
You can configure multiple instances for each Virtual System. When you change the number of firewall instances on a Virtual System, there is some downtime for that Virtual System.
|
Important - Each firewall instance that you create uses additional system memory. A Virtual System with five instances would use approximately the same amount of memory as five separate Virtual Systems. |
The number of IPv6 instances cannot exceed the number of IPv4 instances. For more about IPv6 instances and VSX, go to sk97997.
For more about configuring CoreXL, see the R76 Performance Tuning Administration Guide.
Use the cpconfig command to configure CoreXL on the VSX Gateway (VS0). The number of instances for the VSX Gateway is limited to the physical number of cores on the server or appliance.
To configure the number of instances on the VSX Gateway:
cpconfig.cpconfig.
|
Note - It is not necessary to reboot the VSX Gateway after you configure CoreXL. |
Use SmartDashboard to configure the number of firewall instances on the Virtual Systems. You can assign up to 8 instances on a Virtual System. The number of instances is not limited by the physical cores on the VSX Gateway server or appliance.
You can assign the number of IPv6 instances. It must be less or equal to the number of IPv4 instances. The number of IPv6 instances may be zero. IPv6 virtual instances will only be enabled if an IPv6 address is configured for that Virtual System.
We recommend that you use the number of instances for each Virtual System according to the expected network traffic on the Virtual System. Configuring unnecessary instances will have an impact on performance.
We recommend that you do not configure more instances than the total number of physical cores on the VSX Gateway server or appliance.
To configure CoreXL on a Virtual System:
The Virtual System General Properties window opens.
This section presents procedures for configuring dynamic routing for Virtual Systems and Virtual Routers. The virtual devices can use dynamic routing protocols to communicate and distribute routes amongst themselves and with external routers and other devices. VSX uses the Gaia routing daemon (routed).
You can configure dynamic routing for each of these virtual devices:
Each of these virtual devices has its own dynamic routing instance and configuration file. Use the same procedures to configure the dynamic routing protocols for Warp Links as regular interfaces. You can also configure dynamic routing separately on each cluster member.
To configure dynamic routing for a virtual device:
set virtual-system <vsid>
|
Note - When you run a dynamic routing command, use the TAB key to show the interfaces that you can enable. |
All VSX Gateways and Virtual Routers and Virtual Switches contain at least one interface definition. Typically, you define the interfaces during the process of configuring the topology for a given object. Warp interfaces, however, are created automatically based on virtual device definitions and their topology. You cannot modify or delete a Warp interface.
All VSX Gateways and Virtual Routers and Virtual Switches have at least one interface definition. Typically, you define the interfaces when you configure the topology for a given object. Warp interfaces are created automatically based on virtual device definitions and their topology. You cannot change or delete a Warp interface.
The procedure and options for defining an interface vary according to the object and the network topology. Some properties and pages are not available for certain interface definitions.
To add a new interface:
The Topology page opens.
The Interface Properties window for the selected option opens.
The General tab defines the network connections associated with an interface.
One or more of these properties show, depending on the context.
The General tab for interface connections leading to Virtual Routers or Virtual Switches contains connection properties specific to those virtual devices.
For some interface types, you can change some or all of these topology properties:
Attackers can gain access to protected networks by falsifying or "spoofing" a trusted source IP address with high access privileges. It is important to configure Anti-Spoofing protection for VSX Gateways and Virtual Systems, including internal interfaces. You can configure Anti-Spoofing for an interface, provided that the topology for the interface is properly defined.
If you are using dynamic routing, disable the Calculate topology automatically based on routing information option, and manually configure the topology of the Virtual System.
To enable Anti-Spoofing for an interface:
IP multicasting applications send one copy of each datagram (IP packet) and address it to a group of computers that wish to receive it. Multicast restrictions allow you to define rules that block outbound datagrams from specific multicast groups (IP address ranges). You can define multicast access restrictions for physical and Warp interfaces in a VSX environment.
According to RFC 1112, you can only use an IP address in between 224.0.0.0 and 239.255.255.255.
To enable multicast restrictions:
The Add Object window opens.
The Multicast Address Range Properties window opens.
This section presents procedures for modifying existing interface definitions and related features.
Interfaces definitions are always associated with a Virtual Gateway or a Virtual System definition.
To work with an existing interface definition:
To delete an interface:
Authentication schemes employ user names and passwords to identify valid users. Some schemes are maintained locally, storing user names and passwords on the VSX Gateway, while others store authentication information on an external authentication server. Some schemes, such as SecurID, are based on providing a one-time password.
All of the schemes can be used with users defined on an LDAP server. For additional information on configuring a Security Gateway to integrate with an LDAP server, refer to the User Directory (LDAP) and User Management section in the R76 Security Management Administration Guide.
VSX stores a static password for each user in the management server database. No more software is required.
VSX can authenticate users by means of a user name and password defined on the management server operating system. You can also use passwords stored in a Windows domain. No additional software is required.
Remote Authentication Dial In User Service (RADIUS) is an external, server-based authentication protocol that provides authentication services using the UDP protocol.
Terminal Access Controller Access Control System (TACACS) is an external, server-based authentication protocol that provides verification services using the TCP protocol. TACACS+ is an enhanced version of the TACACS that supports additional types or authentication requests and response codes.
SecurID requires users to possess a token authenticator and to supply a password. Token authenticators generate one-time passwords that are synchronized to an RSA ACE/Server. Hardware tokens are key-ring or credit card-sized devices, while software tokens reside on the PC or device from which the user wants to authenticate. All tokens generate a random, one-time use access code that changes approximately every minute. When a user attempts to authenticate to a protected resource, the one-time use code must be validated by the ACE/Server.
These are the options to enable connectivity between Virtual Systems and a SecurID ACE/Server:
|
Note - You can configure authentication for more than one ACE/Server in private mode. Contact Check Point Technical Support for more information. |
The SecurID ACE/Server sends a shared key (called a "node secret") to its peer ACE/Clients. This key is unique per IP address, and is sent when it connects to the ACE/Server for the first time.
Configure shared authentication so that all the Virtual Systems on the VSX Gateway use the same encryption key to authenticate to the remote SecurID/ACE server. Each cluster member uses a different encryption key and node secret file.
The SecurID encryption key is stored in the sdconf.rec file. When you generate the sdconf.rec file, use the MIP (Member IP address) of a VSX Gateway interface that connects to the ACE/Server.
The first time that a Virtual System connects and attempts to authenticate to the ACE/Server, the server sends the node secret file (securid) to that Virtual System. Copy the node to all the other Virtual Systems.
To generate an sdconf.rec file:
sdconf.rec file with the VSX Gateway MIP.For example, a cluster with three VSX Gateways and each member has five Virtual Systems. Generate three sdconf.rec files, one for each cluster member.
To configure shared authentication:
The Virtual Systems General Properties window opens.
Do all of the previous steps for each Virtual System.
sdopts.rec file that contains the MIP.# vsenv <vsid>
$VAR_ACE/sdopts.rec For VS0, create the file /var/ace/sdopts.rec
sdopts.rec file.CLIENT_IP=<MIP> <MIP> is the Member IP address of the VSX Gateway.
sdconf.rec, to $VAR_ACE.For VS0, copy the file to /var/ace.
On 61000/41000 Security Systems, copy the same encryption key file sdconf.rec to $FWDIR/conf in the context of that Virtual System.
table.def file.$FWDIR/lib/table.def %FWDIR%\lib\table.def no_hide_services_ports parameter contains UDP 5500. Sample parameter with Hide NAT disabled:
no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <5500, 17> };
To distribute the node secret to the Virtual Systems:
The ACE/Server sends the node secret file to the gateway.
securid./var/ace.$VAR_ACE.$FWDIR/conf in the context of each Virtual System.securid file to $VAR_ACE.For VS0, copy the file to /var/ace.
On 61000/41000 Security Systems, copy the securid file to $FWDIR/conf in the context of each Virtual System.
Configure private authentication so that the active and standby Virtual Systems use the same encryption key and node secret file to authenticate to the remote SecurID ACE/Server.
The SecurID encryption key is stored in the sdconf.rec file. When you generate the sdconf.rec file, use the VIP (Virtual IP address) of the Virtual System interface that connects to the ACE/Server.
The first time that a VSX Gateway connects to the ACE/Server, the server sends the node secret file (securid) to that VSX Gateway. Copy the node to all the other VSX Gateways.
To generate an sdconf.rec file:
sdconf.rec file with the Virtual System VIP.For example, a cluster with three VSX Gateways and each member has five Virtual Systems. Generate five sdconf.rec files, one for each Virtual System.
To configure private authentication:
The VSX Gateway General Properties window opens.
Do all of the previous steps for each Virtual System.
sdopts.rec file that contains the VIP of that Virtual System.# vsenv <vsid> $VAR_ACE/sdopts.rec For VS0, create the file /var/ace/sdopts.rec
On 61000/41000 Security Systems, create the file $FWDIR/conf/sdopts.rec in the context of each Virtual System.
sdopts.rec file.CLIENT_IP=<VIP> <VIP> is the Virtual IP address of the Virtual System.
sdconf.rec, to $VAR_ACE. Each Virtual System on the VSX Gateway uses a different sdopts.rec file.
For VS0, copy the file to /var/ace.
On 61000/41000 Security Systems, copy the file to $FWDIR/conf/ in the context of each Virtual System.
For Multi-Domain Server, use the Domain Management Server that manages the Virtual System.
table.def file.$FWDIR/lib/table.def %FWDIR%\lib\table.def no_hide_services_ports parameter DOES NOT contain UDP 5500. Sample parameter with Hide NAT enabled:
no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17> };
To distribute the node secret to Virtual Systems in a VSX cluster:
The ACE/Server sends the node secret file to the gateway.
securid file to the same Virtual System on the other members./var/ace.$VAR_ACE.$FWDIR/conf/ in the context of each Virtual System.These are the options to enable connectivity between Virtual Systems and a RADIUS or TACACS/TACACS+ server:
For Multi-Domain Server configurations, make sure that you configure the SecurID or Remote Authentication settings of the Domain Management Server that manages the Virtual Systems.
Configure shared authentication so that all the Virtual Systems on the VSX Gateway authenticate to the remote RADIUS or TACACS/TACACS+ server.
To configure shared authentication for RADIUS or TACACS/TACACS+:
The Virtual Systems General Properties window opens.
Do all of the previous steps for each Virtual System.
table.def file.$FWDIR/lib/table.def %FWDIR%\lib\table.def no_hide_services_ports parameter contains the UDP ports for RADIUS or TACACS, or the TCP ports for TACACS+. The default ports are:Sample RADIUS parameter with Hide NAT disabled:
no_hide_services_ports = { <49, 6>, <49, 17>, <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <1645, 17> };
For private configurations, the active and standby Virtual Systems use the same encryption key to authenticate to the remote RADIUS or TACACS/TACACS+ server.
For High Availability configurations, make sure that the active and standby Virtual Systems on each cluster member use the same VIP.
To configure private authentication:
The VSX Gateway General Properties window opens.
Do all of the previous steps for each Virtual System.
For Multi-Domain Server, use the Domain Management Server that manages the Virtual System.
table.def file.$FWDIR/lib/table.def %FWDIR%\lib\table.def no_hide_services_ports parameter DOES NOT contain the UDP ports for RADIUS or TACACS, or the TCP ports for TACACS+. The default ports are:
Sample parameter with Hide NAT enabled:
no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17> };
SmartView Monitor is the Graphical User Interface application that displays the status of all Security Gateways, VSX Gateways and virtual devices. SmartView Monitor displays a snapshot of installed Check Point products including VSX. For each VSX Gateway, VSX cluster, or virtual device, SmartView Monitor shows a full range of information including, operating system, CPU, and memory. You can also enable the SmartView Monitor Software Blade on a Virtual System to show detailed information about the network traffic.
For more information on using SmartView Monitor, refer to the R76 SmartView Monitor Administration Guide.
SmartView Monitor connects to and validates each Virtual System as an independent gateway. If one Virtual System is down, this information will be reflected in SmartView Monitor even though the other Virtual Systems on the VSX Gateway or VSX cluster are functioning normally.
VSX supports the following client/session authentication schemes:
For a complete description of these features, see the R76 IPS Administration Guide.
In a VSX environment, you configure Client/Session authentication settings by manually editing the $FWDIR/conf/cpauthd.conf file, located on the VSX Gateway.
|
Note - The VSX client/session authentication procedure is different than the one for Security Gateways. |
You must configure client/session for the VSX Gateway. These settings apply, by default, to all Virtual Systems located on the gateway.
You can optionally configure client/session authentication for specific Virtual Systems. Virtual System specific settings override the default settings for that Virtual System only. Virtual Systems that do not have their own settings inherit the default settings.
To configure client/session authentication for the VSX Gateway:
$FWDIR/conf/cpauthd.conf .$FWDIR/conf/cpauthd.conf.cpwd_admin stop -name FWD -path "$FWDIR/bin/fw" -command "fw kill fwd"
cpwd_admin start -name FWD -path "$FWDIR/bin/fwd" -command "fwd"
Parameter |
Default Value |
Description |
|---|---|---|
|
259 |
The TCP port on which client authentication over TELNET is done. 0 = Client authentication over TELNET is disabled. |
|
900 |
The TCP port on which client authentication over HTTP/HTTPS is done. 0 = Client authentication over HTTP/HTTPS is disabled. |
|
0 |
0 = HTTPS client authentication is disabled. 1 = HTTPS client authentication is enabled. |
|
none |
Specifies the certificate nickname when client authentication is performed over HTTPS. This attribute must match the Virtual System certificate nickname as configured using SmartDashboard (Virtual System >VPN >Certificate List). |
To configure client/session authentication for the VSX Gateway:
$FWDIR/CTX/CTX#/conf/cpauthd.conf, where CTX# refers to the specific Virtual System directory.$FWDIR/CTX/CTX#/conf/cpauthd.conf$FWDIR/conf/cpauthd.conf to FWDIR/CTX/CTX#/conf/cpauthd.conf cpwd_admin stop -name FWD -path "$FWDIR/bin/fw" -command "fw kill fwd"
cpwd_admin start -name FWD -path "$FWDIR/bin/fwd" -command "fwd"
Parameter |
Default Value |
Description |
|---|---|---|
|
259 |
The TCP port on which client authentication over TELNET is performed. 0 = Client authentication over TELNET is disabled. |
|
900 |
The TCP port on which client authentication over HTTP/HTTPS is performed. 0 = Client authentication over HTTP/HTTPS is disabled. |
|
0 |
0 = HTTPS client authentication is disabled. 1 = HTTPS client authentication is enabled. |
|
none |
Specifies the certificate nickname when client authentication is performed over HTTPS. This attribute must match the Virtual System certificate nickname as configured using SmartDashboard (Virtual System >VPN >Certificate List). |
This section describes the process for using Network Address Translation (NAT) in a VSX deployment. The procedures described in this section assume that the reader is familiar with NAT concepts and their implementation in Check Point products. For more about NAT, see the Network Address Translation chapter in the R76 Firewall Administration Guide.
VSX supports NAT for Virtual Systems much in the same manner as a physical firewall. When a NAT enabled (Static or Hide) Virtual System connects to a Virtual Router, the translated routes are automatically forwarded to the appropriate Virtual Router.
You configure NAT using the NAT page in the Virtual System window. Hide or Static NAT addresses configured in this manner are automatically forwarded to the Virtual Router to which the Virtual System is connected. Alternatively, you can manually add NAT routes on the Topology page in the Virtual Router window.
To configure NAT for a Virtual System:
The Advanced page opens.
When you configure Virtual Systems to use the Application Control and URL Filtering Software Blades, you must configure the VSX Gateway to connect to the Application Control and URL Filtering Database. Make sure that the VSX Gateway (VS0) can connect to the Internet, because communication for updates and URL categories is only done from this Virtual System.
To enable Application Control and URL Filtering Categories on Virtual Systems:
When you configure Virtual Systems to use the Anti-Bot and Anti-Virus Software Blades, you must configure the VSX Gateway to connect to the Anti-Bot and Anti-Virus Database. Make sure that the VSX Gateway (VS0) can connect to the Internet.
To enable Application Control and URL Filtering Categories on Virtual Systems:
Check Point software is activated with a license key. To obtain a license key, register the certificate key (that appears on the back of the software media pack) with the Check Point User Center. The certificate key is used to generate a license key for the products that you are either evaluating or purchasing. To purchase the required Check Point products, contact your reseller. Check Point software that has not yet been purchased functions for 15 days only.
Each VSX Gateway or VSX cluster member requires its own license, bound to the gateway or cluster member IP address. Each gateway / cluster license covers a predefined number of Virtual Systems (3, 10, 25, and 50) and these licenses are cumulative. The VSX licenses are applied in addition to the Security Gateway license (container and Software Blades).
Before upgrading a gateway or Security Management Server to R76, you need to have a valid support contract that includes software upgrade and major releases registered to your Check Point User Center account. The Security Management Server stores the contract file and downloads it to Security Gateways during the upgrade. By verifying your status with the User Center, the contract file enables you to easily remain compliant with current Check Point licensing standards.
The license upgrade procedure can be performed if you have purchased any of the Enterprise Software Subscription services. To upgrade a VSX license, do the Software Blades upgrade procedure. See sk65850.
When installing a Check Point product for the first time, users receive a 15 day trial period, during which the product is fully functional. Once the trial period expires, you must purchase and install the appropriate permanent product licenses. During the trial period, you can define up to 25 Virtual Systems.
For more information regarding licensing, refer to the Check Point User Center.