Configuring Virtual MAC (VMAC)

Virtual MAC

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

ClusterXLClosed 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 clusterClosed 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:

G-ARP behavior on network switches and hosts:

Some Layer 3 switches do not integrate the information from G-ARP updates fast enough into their ARP cache table. As a result, such a switch continues to send traffic to the real MAC address of the previous Active member / Pivot member that failed. This causes a traffic outage on the network until the switch updates its ARP cache table.

When there is a large number of Static NAT entries on a Cluster Member, upon failover the ClusterXL mechanism sends many G-ARP updates. In some cases, the number of G-ARP updates is more than a switch can handle. As a result, some traffic is lost

In some other cases, different network devices (for example, VoIP phones) categorically ignore these G-ARP updates.

Check Point solution:

To work with such switches, you can configure Cluster Members to use Virtual MAC (VMACClosed Virtual MAC Address. When this feature is enabled in a ClusterXL (in the High Availability or Load Sharing Unicast mode), the current Active or Pivot Cluster Member sends Gratuitous ARP Requests (G-ARP) for its Cluster Virtual IP (VIP) addresses and Virtual MAC (VMAC) addresses in G-ARP updates. Cluster Members create a VMAC address for each Cluster VIP address. This feature helps avoid issues during a cluster failover, when switches do not integrate G-ARP updates into their ARP cache table.) addresses in G-ARP updates on the cluster interfaces instead of the real MAC addresses. In this scenario, such "smart" switches do need to update their ARP cache tables.

When you enable the Virtual MAC (VMAC) mode in a cluster object, all Cluster Members start to send their G-ARP updates for their Cluster Virtual IP (VIP) addresses with a Virtual MAC (VMAC) address. Cluster Members create a VMAC address for each VIP address. For details, see VMAC Value.

Example:

  • Member_A has the interface eth0 (with a real MAC "A") in the subnet 192.168.3.x/24

  • Member_B has the interface eth0 (with a real MAC "B") in the subnet 192.168.3.x/24

  • Cluster VIP in this subnet is 192.168.3.1

  • When you enable the VMAC mode, all Cluster Members start to send G-ARP packets for the VIP 192.168.3.1 and the same Source Virtual MAC address created for the cluster interfaces eth0.

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.

Source addresses for traffic originating from an Active / Pivot cluster member:

Important - VMAC addresses apply only to cluster G-ARP updates. When Cluster Members forward traffic, they continue to use their real MAC addresses.

Address

Value

Layer 2 Source (MAC) address

Real MAC address of corresponding Cluster Member's interface

Layer 3 Source (IP) address

Virtual IP address that was configured for corresponding cluster interfaces.

Source addresses for traffic originating from hosts on the network toward Cluster Members:

Address

Value

Layer 2 Source (MAC) address

Real MAC address of corresponding host's interface.

Layer 2 Destination (MAC) address

Virtual MAC address created for corresponding cluster interfaces.

Layer 3 Source (IP) address

IP address of corresponding host's interface.

Layer 3 Destination (IP) address

Virtual IP address that was configured for corresponding cluster interfaces.

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 SmartConsoleClosed 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-downClosed 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 ServerClosed 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

VMAC Map:

Bit Number

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Bit Value

 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1 1 1 1 1 1 1 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

Byte Value

 00 1C 7F Virtual System ID Value of "cluster id"

  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:

  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".

Same VMAC

Important - This feature is available in R80.40 Jumbo Hotfix Accumulator Take 172 and higher.

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 VMACClosed 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:

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 StandbyClosed 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. For more information, see sk169154.") 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