Cluster IP Addresses on Different Subnets

Introduction

You can configure cluster virtual IP addresses in different subnets than the members. The cluster virtual interfaces must have routable IP addresses that connect to internal and external networks.

The network "sees" the cluster as one Security Gateway that operates as a network router. The network is not aware of the internal cluster structure and member addresses.

Advantages of using different subnets:

• Lets you create a cluster in an existing subnet that has a shortage of available IP addresses.
• You use only one routable, virtual IP address for the cluster. All other IP addresses can be on other subnets.
• Lets you 'hide' cluster physical cluster addresses behind the virtual cluster IP address. This security practice is almost the same as NAT.

  Note - This capability is available only for ClusterXL Clusters. For details about OPSEC certified clusters, see the vendor documentation.

Traffic sent from cluster members to internal or external networks is hidden behind the cluster virtual IP addresses and MAC addresses. The MAC address assigned to cluster interfaces is the:

• MAC address of the active member interface, in the new High Availability mode.
• Multicast MAC, in the Load Sharing Multicast mode.
• Pivot member MAC in the Load Sharing Unicast mode.

The use of different subnets with cluster objects has some limitations.

Configuring Cluster Addresses on Different Subnets

These are the steps necessary to configure a cluster with different subnets:

1. For each member, define a static route from the member interface to the cluster virtual interface.

   You can do this with operating system commands or with the Check Point cpconfig utility,

2. Configure the cluster topology so that each member has one interface that connects to each cluster virtual IP address.

   Usually, cluster virtual IP addresses are automatically related to an interface based on membership in the same subnet. When the subnets are different, you must explicitly define the relationship between a member interface and a cluster virtual IP address.

Defining the Member Network.

When using a cluster with the cluster virtual IP and members on different subnets, it is necessary to manually define the member.

To manually define the member network.

1. In SmartDashboard, use the Classic Mode to manually create a new cluster.
2. Define the cluster members and their physical interfaces.
3. Go to the Topology page.
4. Click Edit.
5. In the Edit Topology window, enter the IP address for each virtual cluster interface.
6. Save the database.
7. Install policy.

For more details, see the Configuring Cluster Objects chapter.

Configuring a Static Route - Gaia

Use this procedure to configure a static route on all Gaia members. If you do not define the static routes correctly, the member interface IP address is not routable.

To configure a static route on a member - clish:

1. Run set static-route <VIP-subnet/mask> nexthop gateway logical <interface> on.

   <VIP-subnet> - Cluster Virtual IP address and subnet mask for the cluster interface.

   <interface> - Member interface name.

2. Run set static-route <VIP-subnet> scopelocal on.

   <VIP-subnet> - Subnet virtual IP address for the cluster interface.

3. To make sure that the scopelocal attribute is set correctly, run:

   cat /etc/routed.conf

   Sample output:

static {

10.16.6.0 masklen 24 gateway eth1 scopelocal; 

  default gateway 192.168.2.11; 

};

To configure a static route on a member - WebUI:

1. In the WebUI navigation tree, select IPv4 Static Routes.
2. In the IPv4 Static Routes pane, click Add
   or
   Select a route and click Edit to change an existing route.
3. In the Add (or Edit) Destination Route window, enter the
   • Destination - Cluster Virtual IP address.
   • Subnet mask - for the cluster interface.
   • Next Hop Type - Select Normal. This accepts and sends packets to the specified destination.
4. Click Add Gateway.
5. Select Network Interface.
6. Select a Logical Interface. This identifies the next hop gateway by the cluster member interface that connects to it. Use this option only if the next hop gateway has an unnumbered interface.
7. Click OK.
8. Select Local Scope. This lets the cluster member accept static routes on the subnet of the Cluster Virtual address.
9. Click Save.

Configuring a Static Route - SecurePlatform

Use this procedure to configure a static route on all SecurePlatform members. If you do not define the static routes correctly, the member interface IP address is not routable.

To configure a static route on a member:

1. Go to the expert mode.
2. Run sysconfig.
3. Select Routing > Add New Network Route.
4. When prompted for the network IP address, enter the cluster virtual IP address and net mask.
5. When prompted for the gateway IP address, press Enter to accept the default local address.
6. When prompted for the outgoing interface, enter the member interface name.
7. Run this command to make sure that the scopelocal attribute is set correctly:

   cat /etc/routed.conf

   Sample output:

static {

10.16.6.0 masklen 24 gateway eth1 scopelocal; 

  default gateway 192.168.2.11; 

};

Configuring a Static Route - Other Operating Systems.

To configure a static route in other operating systems, refer to the documentation for those systems. For more assistance, contact Check Point Support.

Example of Cluster Addresses on Different Subnets

In this example, a one-Security Gateway firewall separating network 172.16.6.0 (Side "A") from network 172.16.4.0 (Side "B") is to be replaced with a ClusterXL cluster. The cluster members, however, will use networks 192.168.1.0 for Side "A", 192.168.2.0 for Side "B" and 192.168.3.0 for the synchronization network (all network addresses given in this example are of class "C"). The addresses in italics are the cluster Virtual IP addresses.

In this example, cluster protects two networks, Network A and Network B.

Configuring Static Routes on the Cluster Members

Configure each cluster member with these static routes:

• 192.168.1.x logical interface as the next hop gateway for network 172.16.6.0
• 192.168.2.x logical interface as the next hop gateway for network 172.16.4.0.

For more on static route configuration, see sk32073.

Configuring Cluster IP Addresses in SmartDashboard

To configure the cluster interface IP addresses:

1. In the Cluster object Topology > Edit Topology window, edit a cluster interface, and open the Interface Properties window.
2. For each cluster interface, configure the Interface Properties window as follows:

• All IP addresses have the Netmask 255.255.255.0

Limitations of Cluster Addresses on Different Subnets

This new feature does not yet support all the capabilities of ClusterXL. Some features require additional configuration to work properly, while others are not supported.

Connectivity Between Cluster Members

Since ARP requests issued by cluster members are hidden behind the cluster IP and MAC, requests sent by one cluster member to the other may be ignored by the destination computer. To allow cluster members to communicate with each other, a static ARP should be configured for each cluster member, stating the MAC addresses of all other members in the cluster. IP packets sent between members are not altered, and therefore no changes should be made to the routing table.

Load Sharing Multicast Mode with "Semi-Supporting" Hardware

Although not all types of network hardware work with multicast MAC addresses, some routers can pass such packets, even though they are unable to handle ARP replies containing a multicast MAC address. Where a router semi-supports Load Sharing Multicast mode, it is possible to configure the cluster MAC as a static ARP entry in the router internal tables, and thus allow it to communicate with the cluster.

When different subnets are used for the cluster IPs, static ARP entries containing the router MAC need to be configured on each of the cluster members. This is done because this kind of router will not respond to ARP requests containing a multicast source MAC. These special procedures are not required when using routers that fully support multicast MAC addresses.

Manual Proxy ARP

When using static NAT, the cluster can be configured to automatically recognize the hosts hidden behind it, and issue ARP replies with the cluster MAC address, on their behalf. This process is known as Automatic Proxy ARP.

However, if you use the ClusterXL VMAC mode or different subnets for the cluster IP addresses, this mechanism will not work, and you must configure the proxy ARP manually. To do so, in SmartDashboard, select Policy menu > Global Properties > NAT Network Address Translation, and disable Automatic ARP Configuration. Then create a file called local.arp in the firewall configuration directory ($FWDIR/conf).

Each entry in this file is a triplet, containing the:

• host address to be published
• MAC address that needs to be associated with the IP address
• unique IP of the interface that responds to the ARP request.

The MAC address that should be used is the cluster multicast MAC defined on the responding interface, when using multicast LS, or this interface unique IP, for all other modes.

Connecting to the Cluster Members from the Cluster Network

Since the unique IP addresses may be chosen arbitrarily, there is no guarantee that these addresses are accessible from the subnet of the cluster IP address. In order to access the members through their unique IP addresses, you must configure routes on the accessing cluster member, such that the cluster IP is the Default Gateway for the subnet of the unique IP addresses.

Configuring Anti-Spoofing

1. In SmartDashboard, define a group object, which contains the objects of both the external network and the internal network.

   In the example, suppose Side "A" is the external network, and Side "B" is the internal network.

2. You must define a group object, which contains both network 172.16.4.0 and network 192.168.2.0.
3. Open the cluster object.
4. Go to Topology pane and click Edit.
5. Select the cluster interface and click Edit at the bottom.
6. Go to Topology tab.
7. Select Internal (leads to the local network).
8. Select Specific and select the group object that contains the objects of both the external network and the internal network.
9. Click OK.
10. Install the Network Security Policy on this cluster object.