Configuring Virtual MAC (VMAC)

Most switches learn information about hosts connected to the network from ARP Requests and ARP Replies.

ClusterXL Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. relies on this behavior and on its cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. interfaces it sends Gratuitous ARP Requests (G-ARP updates) to the connected networks so network devices (switches, hosts, routers) update their ARP tables with the applicable entries - the Cluster Virtual IP (VIP) and its corresponding MAC address.

Note - Cluster Members send these G-ARP every "N" seconds. This timeout is controlled by the value (in HTUs - HA Time Units) of the global kernel parameter fwha_gratuitous_arp_timeout.

G-ARP behavior in a Check Point cluster:

• In a ClusterXL High Availability A redundant cluster mode, where only one Cluster Member (Active member) processes all the traffic, while other Cluster Members (Standby members) are ready to be promoted to Active state if the current Active member fails. In the High Availability mode, the Cluster Virtual IP address (that represents the cluster on that network) is associated: (1) With physical MAC Address of Active member (2) With virtual MAC Address. Synonym: Active/Standby. Acronym: HA. mode:

  The current Active State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism. Cluster Member Security Gateway that is part of a cluster. sends G-ARP updates for its Cluster Virtual IP (VIP) addresses and their corresponding MAC addresses - the real MAC addresses of the cluster interfaces on the Active Cluster Member.

  When a failover Transferring of a control over traffic (packet filtering) from a Cluster Member that suffered a failure to another Cluster Member (based on internal cluster algorithms). Synonym: Fail-over. occurs, the new Active Cluster Member sends its G-ARP updates for its Cluster Virtual IP (VIP) addresses and their corresponding MAC addresses - the real MAC addresses of the cluster interfaces on the new Active Cluster Member.

• In a ClusterXL Load Sharing A redundant cluster mode, where all Cluster Members process all incoming traffic in parallel. For more information, see "Load Sharing Multicast Mode" and "Load Sharing Unicast Mode". Synonyms: Active/Active, Load Balancing mode. Acronym: LS. Unicast mode:

  The current Pivot A Cluster Member in the Unicast Load Sharing cluster that receives all packets. Cluster Virtual IP addresses are associated with Physical MAC Addresses of this Cluster Member. This Pivot Cluster Member distributes the traffic between other Non-Pivot Cluster Members. Cluster Member sends G-ARP updates for its Cluster Virtual IP (VIP) addresses and their corresponding MAC addresses - the real MAC addresses of the cluster interfaces on the Pivot Cluster Member.

  When a failover occurs, the new Pivot Cluster Member sends its G-ARP updates for its Cluster Virtual IP (VIP) addresses and their corresponding MAC addresses - the real MAC addresses of the cluster interfaces on the new Pivot Cluster Member.

A Cluster VMAC configuration makes G-ARP updates for NATed IP addresses unnecessary during a cluster failover. This decreases the likelihood of a traffic outage during the cluster failover.

• VMAC mode is supported in ClusterXL only in the High Availability mode and in the Load Sharing Unicast mode.

• VMAC mode is supported in a 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 - in High Availability (default mode) and in Virtual System Load Sharing (VSLS) mode.

• In Gaia Clish The name of the default command line shell in Check Point Gaia operating system. This is a restricted shell (role-based administration controls the number of commands available in the shell)., the "show interface" command does not show the VMAC addresses. Use "show cluster members interfaces virtual" command.

• In the Expert mode, the "ifconfig" command does not show the VMAC addresses. Use "cphaprob -a if" command.

Best Practices: We recommend to schedule a maintenance window. We recommend to enable the feature when all cluster members are in the state "UP".

You configure the VMAC mode in 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..

You can control the VMAC mode in the command line on each Cluster Member.

Configuration in SmartConsole:

1. In SmartConsole, open the cluster object.

2. From the left tree, select ClusterXL and VRRP.

3. Below Select the cluster mode and configuration: select High Availability.

4. In the drop-down State of a Cluster Member during a failure when one of the Critical Devices reports its state as "problem": In ClusterXL, applies to the state of the Security Gateway component; in 3rd-party / OPSEC cluster, applies to the state of the State Synchronization mechanism. A Cluster Member in this state does not process any traffic passing through cluster. menu to the right of High Availability, select ClusterXL.

5. Below Advanced Settings, select Use Virtual MAC.

6. Click OK.

7. Install the Access Control Policy on the cluster object.

Configuration in the command line of each Cluster Member (alternative method):

Note - To get the current value of the kernel parameter "fwha_vmac_global_param_enabled", run on each Cluster Member: fw ctl get int fwha_vmac_global_param_enabled

1. To disable VMAC mode temporarily (does not survive reboot), on each Cluster Member configure the value of the kernel parameter "fwha_vmac_global_param_enabled" to 0:

   fw ctl set int fwha_vmac_global_param_enabled 0

2. To enable the VMAC mode again, on each Cluster Member configure the value of the kernel parameter "fwha_vmac_global_param_enabled" to 1 (default value is 0):

   fw ctl set int fwha_vmac_global_param_enabled 1

Total 48 bits (from left-to-right):

Bits	Description	Value
First 24 bit	Unique constant value.	00:1C:7F
Next 8 bits	VSX Virtual System ID.	In a VSX Cluster: Virtual System ID In a non-VSX Cluster 000000000
Last 16 bits	Unique value that the Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. assigns to each cluster object. This makes the VMAC value unique for each managed cluster.	Unique value for each cluster

1. Connect to the command line on each Cluster Member.

2. To see the VMAC addresses, run this command and see the "VMAC address" values:
   

   • In Gaia Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. Clish:

     show cluster members interfaces virtual

   • In the Expert mode:

     cphaprob -a if

3. Make sure that the ARP tables of the hosts connected to these Cluster Members now contain the VMAC value.

   Use the applicable command for the Operating System on the hosts.

   For example, on Linux, run "arp -an". On Windows, run "arp-a".

VMAC mode applies only to Gratuitous ARP packets. For more information about VMAC, see Virtual MAC.

When Cluster Members forward traffic, they continue to use their real MAC addresses.

Some Layer 3 switches learn about the hosts from the source IP addresses and source MAC addresses of the traffic that arrives at these switches.

If an IP-to-MAC address association on such a "smart" Layer 3 switch changes frequently, the switch may consider such an IP address as "misbehaving" or "rogue". Security features on such a "smart" switch can disable ARP table updates and freeze the current IP-to-MAC address association.

As a result, a traffic outage can occur because Cluster Members send traffic from the same source IP addresses, but with different source MAC addresses (VMAC in G-ARP and real MAC in regular traffic).

Check Point solution:

To work with such switches, you can configure Cluster Members to use Virtual MAC (VMAC) addresses on the cluster interfaces instead of the real MAC addresses.

Cluster interfaces that belong to the same subnet get the same VMAC Same Virtual MAC Address (see "VMAC"). When this feature is enabled in a ClusterXL (in the High Availability or Load Sharing Unicast mode), the Cluster Members use Virtual MAC (VMAC) addresses on the cluster interfaces instead of the real MAC addresses. Cluster interfaces that belong to the same subnet get the same VMAC address instead of their real MAC address. This feature helps avoid issues during the cluster operation, when switches block ports connected to the Cluster Members. address instead of their real MAC address. In this scenario, such "smart" switches always detect traffic from the same source IP addresses and the same source MAC addresses.

Example:

• eth1 - cluster interface An interface on a Cluster Member, whose Network Type was set as Cluster in SmartConsole in cluster object. This interface is monitored by cluster, and failure on this interface will cause cluster failover. on Member_1 has a VMAC address

• eth1 - cluster interface on Member_2 has the same VMAC address

• Only ClusterXL High Availability and VSX VSLS modes are supported.

• In the ClusterXL High Availability object, you must enable and configure the state synchronization Technology that synchronizes the relevant information about the current connections (stored in various kernel tables on Check Point Security Gateways) among all Cluster Members over Synchronization Network. Due to State Synchronization, the current connections are not cut off during cluster failover.:

  1. On the ClusterXL and VRRP page, select Use State Synchronization.

  2. On the Network Management page, you must configure a Sync interface An interface on a Cluster Member, whose Network Type was set as Sync or Cluster+Sync in SmartConsole in cluster object. This interface is monitored by cluster, and failure on this interface will cause cluster failover. This interface is used for State Synchronization between Cluster Members. The use of more than one Sync Interfaces for redundancy is not supported because the CPU load will increase significantly due to duplicate tasks performed by all configured Synchronization Networks. Synonyms: Secured Interface, Trusted Interface..

     Best Practice - Configure a dedicated Sync interface on each Cluster Member, and in the interface properties, in the Network Type field, select Sync.

• Cluster Members monitor their cluster interfaces only with the Link Monitoring (and not with Cluster Control Protocol Proprietary Check Point protocol that runs between Cluster Members on UDP port 8116, and has the following roles: (1) State Synchronization (Delta Sync), (2) Health checks (state of Cluster Members and of cluster interfaces): Health-status Reports, Cluster-member Probing, State-change Commands, Querying for cluster membership. Note: CCP is located between the Check Point Firewall kernel and the network interface (therefore, only TCPdump should be used for capturing this traffic). Acronym: CCP. (CCP) packets).

• Physical cluster interfaces that have VLAN interfaces configured, must not have a Virtual IP Address:

  1. Open the Cluster Member object.

  2. In the left navigation tree, click Network Management.

  3. In the table, double-click applicable physical cluster interface for each Cluster Member.

     The Network: <Interface Name> window opens on the page General.

  4. In the General section, in the Network Type drop-down menu, select Private.

  5. Click OK to close the Network window.

  6. Click OK to close the Gateway Cluster Properties window.

  Example:

  • eth1 - physical interface with VLANs, must not have a VIP address

  • eth1.2 - VLAN interface, VIP is supported

  • eth1.3 - VLAN interface, VIP is supported

• The Management interface of Cluster Members does not use a VMAC address (continues to use only its real MAC address).

• To connect to Standby State of a Cluster Member that is ready to be promoted to Active state (if the current Active Cluster Member fails). Applies only to ClusterXL High Availability Mode. Cluster Members (for example an SSH connection from a Host), you must connect to their Management interfaces or Sync interfaces.

• Local connections from Standby Cluster Members to an IPv6 Host (for example, to an FTP server) are not supported.

Best Practices: We recommend to schedule a maintenance window. We recommend to enable the feature when all cluster members are in the state "UP".

Note - A reboot is not required after you enable or disable the "Same VMAC" (and the "Silent Standby In the ClusterXL High Availability mode, this feature configures the Standby cluster member to communicate only through the Active cluster member. This feature is useful when it is necessary to connect from Standby cluster members to a host / server on the network.") features.

To enable "Same VMAC" and "Silent Standby":

1. Connect to the command line on each Cluster Member.

2. Log in to the Expert mode.

3. Enable the "Same VMAC" feature:

   fw ctl set -f int fwha_alter_vmac_param 1

4. Enable the "Silent Standby" feature:

   fw ctl set -f int fwha_silent_standby_mode 1

   Important - You must enable the "Silent Standby" feature if it is necessary to connect from Standby cluster members to a host / server on the network. The "Silent Standby" feature configures the Standby cluster member to communicate only through the Active cluster member (for more information, see sk169154 - section "(3.4) Standby member's connections").

5. Enable Link Monitoring of all cluster interfaces:

   1. Look for the required configuration file:

      ls -l $FWDIR/conf/cpha_link_monitoring.conf

      • If this file already exists, back it up:

        cp -v $FWDIR/conf/cpha_link_monitoring.conf{,_BKP}

      • If this file does not exist, create it:

        touch $FWDIR/conf/cpha_link_monitoring.conf

   2. Configure only the value "all" in the configuration file:

      echo all > $FWDIR/conf/cpha_link_monitoring.conf

6. Enable the VMAC on all cluster members:

   1. In SmartConsole, open the cluster object.

   2. From the left tree, select ClusterXL and VRRP.

   3. Below Select the cluster mode and configuration: select High Availability.

   4. In the drop-down menu to the right of High Availability, select ClusterXL.

   5. Below Advanced Settings, select Use Virtual MAC.

   6. Click OK.

   7. Install the Access Control Policy on the cluster object.

To disable "Same VMAC" and "Silent Standby":

1. Connect to the command line on each Cluster Member.

2. Log in to the Expert mode.

3. Disable the "Same VMAC" feature:

   fw ctl set -f int fwha_alter_vmac_param 0

4. Disable the "Silent Standby" feature:

   fw ctl set -f int fwha_silent_standby_mode 0

5. Disable Link Monitoring of all cluster interfaces:

   echo '' > $FWDIR/conf/cpha_link_monitoring.conf

6. Disable the VMAC on all cluster members:

   1. In SmartConsole, open the cluster object.

   2. From the left tree, select ClusterXL and VRRP.

   3. Below Advanced Settings, clear Use Virtual MAC.

   4. Click OK.

   5. Install the Access Control Policy on the cluster object.

1. Connect to the command line on the Cluster Member.

2. To see the VMAC addresses, run a command and see the "VMAC address" values:

   • In Gaia Clish:

     show cluster members interfaces virtual

   • In the Expert mode:

     cphaprob -a if

3. Make sure that the ARP tables of the hosts connected to these cluster members now contain the VMAC value.

   Use the applicable command for the Operating System on the hosts.

   For example, on Linux, run "arp -an". On Windows, run "arp -a".

4. To see the Same VMAC addresses, run the command and see the MAC addresses on the cluster interfaces:

   • In Gaia Clish:

     show interfaces all

     show interface <Name of Physical Interface><SPACE><TAB>

   • In the Expert mode:

     ifconfig