|
|
|
The Gaia First Time Configuration Wizard automatically installs and enables SecureXL on your Security Gateway. No additional configuration is required.
Starting from R80.20, you can disable the SecureXL only temporarily. The SecureXL starts automatically when you start Check Point services (with the cpstart command), or reboot the Security Gateway.
Important:
SecureXL remains disabled until you enable it again on-the-fly, or reboot the Security Gateway.
SecureXL continues to accelerate the connections that are already accelerated.
Other non-connection oriented processing continues to function (for example, virtual defragmentation and VPN decrypt).
To temporarily disable SecureXL for IPv4:
Step |
Description |
|---|---|
1 |
Connect to the command line on your Security Gateway. |
2 |
Log in to Gaia Clish, or Expert mode. |
3 |
Examine the SecureXL status:
|
4 |
Disable the SecureXL:
|
5 |
Examine the SecureXL status again:
|
To temporarily disable SecureXL for IPv6:
Step |
Description |
|---|---|
1 |
Connect to the command line on your Security Gateway. |
2 |
Log in to Gaia Clish, or Expert mode. |
3 |
Examine the SecureXL status:
|
4 |
Disable the SecureXL:
|
5 |
Examine the SecureXL status again:
|
To enable SecureXL again for IPv4:
Step |
Description |
|---|---|
1 |
Connect to the command line on your Security Gateway. |
2 |
Log in to Gaia Clish, or Expert mode. |
3 |
Examine the SecureXL status:
|
4 |
Enable the SecureXL:
|
5 |
Examine the SecureXL status again:
|
To enable SecureXL again for IPv6:
Step |
Description |
|---|---|
1 |
Connect to the command line on your Security Gateway. |
2 |
Log in to Gaia Clish, or Expert mode. |
3 |
Examine the SecureXL status:
|
4 |
Enable the SecureXL:
|
5 |
Examine the SecureXL status again:
|
To learn more about SecureXL, see the R80.20 Performance Tuning Administration Guide.
By default, the traffic for each interface is processed on one CPU core. If there are more CPU cores than interfaces, not all of the CPU cores are used to process traffic.
You can enable the Multi-Queue feature to assign more than one CPU core to one interface. Run the cpmq command to configure the Multi-Queue settings.
The SND (Secure Network Distributer) is part of SecureXL and CoreXL. It processes and helps to accelerate network traffic:
Sample Multi-Queue Configuration
This sample configuration shows how CoreXL, SecureXL and Multi-Queue can help to use more CPU cores for SNDs to accelerate network traffic. There is a Security Gateway with two six core CPUs (total 12 CPU cores) and three interfaces:
|
CPU cores for SND |
CPU cores for CoreXL |
|---|---|---|
Multi-Queue disabled |
3 |
9 |
Multi-Queue enabled |
6 |
6 |
To learn more about Multi-Queue, see the R80.20 Performance Tuning Administration Guide.
Security Gateways and VPN connections are business critical devices. The failure of a Security Gateway or VPN connection can result in the loss of active connections and access to critical data. The Security Gateway between the organization and the world must remain open under all circumstances.
ClusterXL is a Check Point software-based cluster solution for Security Gateway redundancy and Load Sharing. A ClusterXL Security Cluster contains identical Check Point Security Gateways.
Item |
Description |
|---|---|
1 |
Internal network |
2 |
Switch for internal network |
3 |
Security Gateways with ClusterXL Software Blade |
4 |
Switch for external networks |
5 |
Internet |
R80.20 ClusterXL supports High Availability clusters for IPv6. IPv6 status information is synchronized and the IPv6 clustering mechanism is activated during failover. However, IPv6 is not supported for Load Sharing clusters. Also, you cannot define IPv6 addresses for synchronization interfaces.
ClusterXL uses State Synchronization to keep active connections alive and prevent data loss when a Cluster Member fails. With State Synchronization, each Cluster Member "knows" about connections that go through other Cluster Members.
ClusterXL uses virtual IP addresses for the cluster itself and unique physical IP and MAC addresses for the Cluster Members. Virtual IP addresses do not belong to physical interfaces.
Note - This guide contains information only for Security Gateway clusters. For additional information about the use of ClusterXL with VSX, see the R80.20 VSX Administration Guide.
The Cluster Control Protocol (CCP) is the glue that links together the members in the Security Cluster. CCP traffic is distinct from ordinary network traffic and can be viewed using any network sniffer.
CCP runs on UDP port 8116, and has the following roles:
The Check Point CCP is used by all ClusterXL modes.
Note - There is no need to add an explicit rule to the Security Policy Rule Base that accepts CCP.
For more information about the CCP packets, see sk25977.
In addition, see Selecting the CCP Transport Mode on the Cluster Members.
ClusterXL must be installed in a distributed configuration, in which the Security Management Server and the Security Cluster members are on different computers. ClusterXL is part of the standard Security Gateway installation.
For installation instructions, see the R80.20 Installation and Upgrade Guide.
To see the ClusterXL supported platforms, see the R80.20 Release Notes.
ClusterXL is a software-based Load Sharing and High Availability solution that distributes network traffic between clusters of redundant Security Gateways.
ClusterXL has these High Availability features:
All members in the cluster are aware of the connections passing through each of the other members. The cluster members synchronize their connection and status information across a secure synchronization network.
The glue that binds the members in a ClusterXL cluster is the Cluster Control Protocol (CCP), which is used to pass synchronization and other information between the cluster members.
In a High Availability cluster, only one member is active (Active/Standby operation). In the event that the active Cluster Member becomes unavailable, all connections are re-directed to a designated standby without interruption. In a synchronized cluster, the standby Cluster Members are updated with the state of the connections of the Active Cluster Member.
In a High Availability cluster, each member is assigned a priority. The highest priority member serves as the Security Gateway in normal circumstances. If this member fails, control is passed to the next highest priority member. If that member fails, control is passed to the next member, and so on.
Upon Security Gateway recovery, you can maintain the current Active Security Gateway (Active Up), or to change to the highest priority Security Gateway (Primary Up).
ClusterXL High Availability mode supports both IPv4 and IPv6.
Important:
|
ClusterXL Load Sharing distributes traffic within a cluster so that the total throughput of multiple members is increased.
In Load Sharing configurations, all functioning members in the cluster are active, and handle network traffic (Active/Active operation).
If any member in a cluster becomes unreachable, transparent failover occurs to the remaining operational members in the cluster, thus providing High Availability.
All connections are shared between the remaining Security Gateways without interruption.
ClusterXL Load Sharing modes do not support IPv6.
ClusterXL uses unique physical IP and MAC addresses for each cluster member, and a virtual IP addresses for the cluster itself. Cluster interface addresses do not belong to any real member interface.
The following diagram illustrates a two-member ClusterXL cluster, showing the cluster virtual IP addresses and member physical IP addresses. This sample deployment is used in many of the examples presented in this chapter.
Item |
Description |
|---|---|
1 |
Internal network |
2 |
Internal switch (internal cluster IP address 10.10.0.100) |
3 |
Security Gateway - Cluster member A |
3a |
Virtual interface to the internal network (10.10.0.1) |
3b |
Interface to the Cluster Sync network (10.0.10.1) |
3c |
Virtual interface to the external network (192.168.10.1) |
4 |
Security Gateway - Cluster member B |
4a |
Virtual interface to the internal network (10.10.0.2) |
4b |
Interface to the Cluster Sync network (10.0.10.2) |
4c |
Virtual interface to the external network (192.168.10.2) |
5 |
External switch (external routable cluster IP address 192.168.10.100) |
6 |
Internet |
Each cluster member has three interfaces: one external interface, one internal interface, and one for synchronization. Cluster member interfaces facing in each direction are connected via a switch, router, or VLAN switch.
All cluster member interfaces facing the same direction must be in the same network. For example, there must not be a router between cluster members.
The Security Management Server can be located anywhere, and should be routable to either the internal or external cluster addresses.
The guidelines for configuring each Cluster Member are as follows:
All members within the cluster must have at least three interfaces:
All interfaces pointing in a certain direction must be on the same network.
For example, in the previous illustration, there are two Cluster Members, Member_A and Member_B. Each has an interface with an IP address facing the Internet through a hub or a switch. This is the external interface with IP address 192.168.10.1 on Member_A and IP address 192.168.10.2 on Member_B.
Note - This release presents an option to use only two interfaces per member, one external and one internal, and to run synchronization over the internal interface. We do not recommend this configuration. It should be used for backup only.
In the previous illustration, the IP address of the cluster is 192.168.10.100.
The cluster has one external virtual IP address and one internal virtual IP address. The external IP address is 192.168.10.100, and the internal IP address is 10.10.0.100.
The previous illustration shows a synchronization interface with a unique IP address on each Cluster Member - IP 10.0.10.1 on Member_A and IP 10.0.10.2 on Member_B.
