IPv6 Neighbor Discovery

Neighbor discovery works over the ICMPv6 Neighbor Discovery protocol, which is the functional equivalent of the IPv4 ARP protocol. ICMPv6 Neighbor Discovery Protocol must be explicitly allowed for all bridged networks in your Firewall rules. This is different from ARP, for which traffic is always allowed regardless of the Rule Base.

This is an example of a rule that allows ICMPv6 Neighbor Discovery protocol:

Configuring Link State Propagation

You can bind two ports together, so that when the link state for one port goes down, the other port also goes down. This lets a switch detect and react to a link failure on the other side of a bridge or another part of the network.

This feature is available in one of these modes:

• Automatic port detection and port pair creation - All bridge ports are assigned to a port pair (the pair in the bridge).
• Manual port pair creation - Up to four port pairs are supported.

Link state propagation is supported on these Check Point appliance line cards:

• CPAC-4-1C/CPAC-8-1C – Copper line cards with IGB driver
• CPAC-4-1F – 1Gbe fiber line card with an IGB driver
• CPAC-4-10F – 10Gbe fiber line card with an IXGBE driver

For example:
fw_lsp_pair1=”eth1,eth2"

Note: The below procedures are applicable to R77.20 and higher.

To configure Link State Propagation for automatic port detection:

1. Open FWDIR/modules/fwkern.conf in a text editor.

   If there is no fwkern.conf file, create a new one.

2. Add this line:

   fw_link_state_propagation_enabled=1

3. Reboot the computer.

To create port pairs automatically:

1. Open FWDIR/modules/fwkern.conf in a text editor.

   If there is no fwkern.conf file, create a new one.

2. Add these lines:

   fw_link_state_propagation_enabled=1

   fw_manual_link_state_propagation_enabled=1

   fw_lsp_pair<1-4>=”<interface_name1,interface_name2>”

3. Reboot the computer.

   Note - Link State Propagation is a Firewall Software Blade feature. It is supported for Security Gateways and clusters. You must configure Link State Propagation for each cluster member.

Managing Ethernet Protocols

This feature is supported in R77.10 and higher.

It is possible to configure a Security Gateway with bridge interface to allow or drop protocols that are not based on IP that pass through the bridge interface. For example, protocols that are not IPv4, IPv6, or ARP.

By default, these protocols are allowed by the Security Gateway.

To manage the traffic of Ethernet protocols:

1. Change the value of global parameter fwaccept_unknown_protocol in $FWDIR/modules/fwkern.conf. The default value is 1.
2. Create user defined tables in $FWDIR/conf/user.def:

$ifndef __user_def__

$define __user_def__

\\

\\ User defined INSPECT code

\\

allowed_ethernet_protocols={ <0x44,0x44> );

dropped_ethernet_protocols={ <0x4,0x4> );

fendif /*__user_def__*/

Traffic is allowed if:

• fwaccept_unknown_protocol is enabled
• OR protocol is in allowed_ethernet_protocols table
• AND NOT in dropped_ethernet_protocols table

VLANs

When switches are configured with VLANs, VLAN traffic can pass through our bridge in Access mode or in Trunk mode:

• Access mode (VLAN translation) – Bridge is constructed from two VLAN interfaces.
• Trunk mode – Bridge is constructed from two non-VLAN interfaces. The VLAN tag is not removed, and the firewall processes the tagged packet. The traffic passes with the original tag to its destination.

Access Mode VLAN

When the switch is configured in Access Mode, create the bridge from two VLAN interfaces as the slave ports of the bridge. For VLAN translation, use different numbered VLAN interfaces to create the bridge. You can build multiple VLAN translation bridges on the same Security Gateway.

To configure VLAN translation:

1. Add the VLANs. In the WebUI: Network Management > Network Interfaces > Add > VLAN.

   The Add VLAN window opens. Configure the interfaces of the VLAN.

   

2. Open the Add Bridge window and select the VLAN interfaces in the Bridge tab.

   

VLAN ID 2 traffic will be translated into VLAN ID 22, and vice versa.

Special Protocols

PVST - Per-VLAN Spanning Tree. PVST is a proprietary Cisco version of STP and maintains a spanning tree instance for each VLAN. It uses ISL Trunking and lets a VLAN trunk be forwarded for some VLANs and blocked for others. Because PVST treats each VLAN as a separate network, it can load balance traffic at layer-2. It forwards some VLANs on one trunk and other VLANs on another trunk without causing a Spanning Tree loop.

BPDU - Bridge Protocol Data Unit. BPDUs are data messages that are exchanged across the switches within an extended LAN that uses STP topology.

When VLAN translation is configured, BPDU frames can arrive with the wrong VLAN number to the ports through the bridge. This mismatch can cause the switch port to enter blocking mode.

In Active-Standby mode only, there are options to avoid blocking mode.

To disable BPDU forwarding:

1. Edit the file /etc/rc.d/init.d/network
2. After the line:
   ./etc/init.d/functions

   Add this line:
   /sbin/sysctl -w net.bridge.bpdu_forwarding=0

3. Save the file.
4. Reboot the Security Gateway.

To configure the gateway to allow only IPv4, IPv6, and ARP traffic:

1. Add to $FWDIR/modules/fwkern.conf the line: fwaccept_unknown_protocol=0
2. Reboot the Security Gateway.

Trunk Mode

If you configure the switch ports as VLAN trunk, the Check Point bridge should not interfere with the VLANs. To configure bridge with VLAN trunk, create the bridge from two interfaces (no VLAN).

Configuring a DLP Gateway in Bridge Mode

When setting up a dedicated DLP gateway, Check Point recommends that you configure the DLP gateway as a bridge, so that the DLP gateway is transparent to network routing.

You can deploy DLP in bridge mode, with the requirements described in this section for routing, IP address, and VLAN trunks.

Note the current limitations:

• In an environment with more than one bridge interface, the DLP gateway must not see the same traffic twice on the different interfaces. The traffic must not run from one bridged segment to another.
• Inter-bridge routing is not supported. This includes inter-VLAN routing.
• If the bridge interface is connected to a VLAN trunk, all VLANs will be scanned by DLP. You cannot exclude specific VLANs.
• Routing from the bridge interface to a Layer3 interface, and from Layer3 interface to the bridge, is not supported. Traffic on the bridge interface must run through the bridge or be designated to the DLP gateway.
• From R76, the DLP gateway in bridge mode can be in a cluster, in High Availability mode. But the Ask User action and the UserCheck Agent are not supported.
• If the DLP gateway in bridge mode is behind a cluster, the cluster must be in High Availability mode.
• Bond High Availability (HA) or Bond Load Sharing (LS) (including Link Aggregation) are not supported in combination with bridge interfaces.

Required Routing in Bridge Mode

There must be routes between the DLP gateway and the required servers:

• Security Management Server
• DNS server
• Mail server, if an SMTP Relay server is configured to work with the gateway
• Active Directory or LDAP server, if configured to work with the gateway

There must be a default route. If this is not a valid route, it must reach a server that answers ARP requests.

If UserCheck is enabled, configure routing between the DLP gateway and the network.

Configuring Bridge IP Address

The bridge interface can be configured without an IP address, if another interface is configured on the gateway that will be used to reach the UserCheck client and the DLP Portal.

If you do add an IP address to the bridge interface after the Security Gateways are started, run the cpstop and cpstart commands to apply the change.

Required VLAN Trunk Interfaces

• A single bridge interface must be configured to bind the DLP gateway for a VLAN trunk.
• If an IP address is configured on the bridge, the IP address must not belong to any of the networks going through the bridge. Users must have routes that run traffic through the bridge interface of the DLP gateway. The gateway handles this traffic and answers to the same VLAN of the original traffic.
• In a VLAN trunk interface, another interface must be configured as the management interface for the required bridge routing.

Virtual System in Bridge Mode

A Virtual System in bridge mode implements native layer-2 bridging. A typical bridge mode scenario incorporates an 802.1q compatible VLAN switch on either side of the VSX Gateway. The Virtual System interfaces do not have IP addresses.

A Virtual System in bridge mode:

• Simplifies virtual network management
• Does not segment an existing virtual network
• Requires manual topology configuration to enforce anti-spoofing

To configure a Virtual System to use bridge mode, define it as a Virtual System in bridge mode when you first create it. You cannot reconfigure a non-Bridge mode Virtual System to use bridge mode later.

Core Network Security

Many Enterprise environments are based on core networks. Situated adjacent to core network backbone switches, VSX protects the internal network by providing security at layer-2, layer-3 or both. VSX communicates with the core network using the existing infrastructure. With Virtual Systems in the Bridge Mode, VSX can protect departmental networks, while simultaneously preventing network segmentation. In this case, switches are located at the entrance to each department's network.

VSX ensures connectivity between the core network and the Internet or external networks, while providing perimeter security. Security can be configured on a per VLAN basis.

Three Layer Hierarchical Model

A three-layer hierarchical model is used in large, high-traffic network environments.

1. A core network, with high-speed backbone switches that direct traffic to and from the Internet and other external networks.
2. A distribution layer, with routers, for connectivity between the core and the access layer.
3. An access layer, with redundant LAN switches, that forward traffic to and from internal networks.

VSX in Active/Standby Bridge Mode is incorporated in the distribution layer, enforcing the security policy.

The routers direct external traffic to the appropriate Virtual System through a segregated VLAN. Inspected traffic exits the Virtual System through a separate segregated VLAN, to the routers and then to internal destinations.

Configuring Virtual Systems for Active/Standby Bridge Mode

To configure a Virtual System to use bridge mode, define it as such when you first create the object.

To configure a Virtual System for the Active/Standby Bridge Mode:

1. In the Virtual System General Properties page of the new Virtual System object, select Bridge Mode.
2. Click Next.

   The Virtual System Network Configuration window opens.

3. Configure the external and internal interfaces for the Virtual System.
4. Optional: Select Enable Layer-3 Bridge Interface Monitoring.

   The IP address must be unique and on the same subnet as the protected network.

5. Click Next and then click Finish.

Enabling Active/Standby Bridge Mode for a New Member

When you create a new cluster member, enable the cluster options during the first configuration.

1. In the Gaia First Time Configuration Wizard Products page, select ClusterXL.
2. From the VSX Gateway CLI, run: cpconfig
   • If you enable the Per Virtual System State feature, (required for VSLS), Active/Standby Bridge Mode is enabled automatically.
   • If you chose not to enable Virtual System Load Sharing, an option to enable Active/Standby Bridge Mode appears. Enter y and continue with the gateway configuration.

Enabling Active/Standby Bridge Mode for Existing Members

To enable the Active/Standby Bridge Mode on existing Virtual Systems:

1. Run: cpconfig
2. Enable ClusterXL for Bridge Active/Standby.
3. Reboot the member.

Enabling Active/Active Bridge Mode when Creating Member

When you create a new VSX Gateway to use as a cluster member, configure it as a cluster member when you first define the gateway.

1. Run: cpconfig
2. At Would you like to install a Check Point clustering product, enter: y
3. If prompted to disable Active/Standby Bridge Mode, enter: n
4. Continue with the cpconfig options as usual.

Enabling Active/Active Bridge Mode for Existing Members

To enable the Active/Active Bridge mode for existing cluster members:

1. Run: cpconfig
2. Enable cluster membership for this member.

   (If a numerical value appears here, cluster membership has already been enabled).

3. Disable ClusterXL for Bridge Active/Standby.
4. Reboot the member.

Custom or Override in Bridge Mode

You must manually define network interfaces, if:

• You used the Custom Configuration template when you created the VSX Gateway
• You selected Override Creation Template and this is a Virtual System in bridge mode

In the Virtual System wizard > Virtual System Network Configuration, add the external and internal interfaces and links to devices.

If the Virtual System is on IPSO, select Enable Layer-3 Bridge Interface Monitoring. Define the IP address and net mask. Make sure the IP address to be monitored is on a different subnet than the subnet that handles bridge traffic.

VLAN Shared Interface Deployment

In this deployment, each member connects to pair of redundant switches through a VLAN trunk. All Virtual Systems in a given member share the same VLAN trunk.

With Active/Standby Bridge Mode in High Availability mode, ClusterXL directs traffic to members according to administrator -defined priorities and status. In Virtual System Load Sharing deployments, the system distributes the traffic load amongst members according to your Virtual System Load Sharing configuration.

VSX Clusters

A VSX cluster has two or more identical, interconnected VSX Gateways for continuous data synchronization and transparent failover. Virtual System Load Sharing (VSLS) enhances throughput by distributing Virtual Systems, with their traffic load, among multiple, redundant machines.

Configuring Clusters for Active/Standby Bridge Mode

To enable the Active/Standby Bridge Mode for a cluster:

1. Open SmartDashboard.
2. From the Network Objects tree, double-click the VSX Cluster object.

   The VSX Cluster Properties window opens.

3. Select Other > VSX Bridge Configuration.
4. Select Check Point ClusterXL.

   The Active/Standby Bridge Mode loop detection algorithms in ClusterXL is enabled.

Configuring Clusters for Active/Active Bridge Mode

To enable the Active/Active Bridge mode for a cluster:

1. Open SmartDashboard.
2. From the Network Objects tree, double-click the VSX Cluster object.

   The VSX Cluster Properties window opens.

3. Select Other > VSX Bridge Configuration.
4. Select Standard Layer-2 Loop Detection Protocols.

Separate Interfaces in Bridge Mode

The Virtual System Network Configuration page for the Separate Interfaces template in the Bridge Mode opens.

To configure the external and internal interfaces:

1. Select the desired interfaces for the internal and external networks from the appropriate list.

   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.

2. Define the topology for the internal interface:
   • Select Not Defined if you do not wish to define an IP address.
   • Select Specific and then select an IP address definition from the list. IP address definitions can be based on object groups or predefined networks that define the topology.
3. To create a new IP address definition:
   1. Select Specific, and click New.
   2. Select Group to define an object group, or Network to define network properties.
4. Enable Layer-3 bridge interface monitoring to enable layer 3 network fault detection for this Virtual System.

   Enter an IP address and subnet mask, which continuously monitors the specified network for faults or connectivity issues. The IP address/subnet define the network on which the Virtual System resides.

5. Complete the definition process.

Virtual System Load Sharing (VSLS)

VSX clusters can efficiently balance network traffic load by distributing active Virtual Systems amongst cluster members. This capability is known as Virtual System Load Sharing (VSLS).

In a deployment scenario with three cluster members, each with three Virtual Systems: an equalized Load Sharing deployment might have one active Virtual System on each cluster member.

A different member hosts the active peer for each Virtual System. This distribution spreads the load equally amongst the members. When you create a Virtual System, VSX automatically assigns standby and backup states to the appropriate peers and distributes them among the other cluster members.

In the event that a cluster member fails, VSLS directs traffic destined to affected Virtual Systems to their fully synchronized standby peers, which then become active. At the same time, a backup Virtual Systems switches to standby, and synchronizes with the newly active Virtual System.

In the event that an individual active Virtual System fails, it immediately fails over to its standby peer and one of its backup peers becomes the standby, synchronizing with the newly active peer.

Converting from High Availability to VSLS

To convert an existing High Availability cluster to VSLS Load Sharing:

1. Close SmartDashboard.
2. On each member:
   1. Run cpconfig
   2. Enable the Per Virtual System State.
   3. Enable ClusterXL for Bridge Active/Standby.
3. Restart the members: cpstop and cpstart
4. On the management server, enter Expert mode.
5. Run: vsx_util convert_cluster
6. Enter the Security Management Server or Multi-Domain Security Management Domain Management Server IP address.
7. Enter the administrator user name and password.
8. Enter the VSX cluster name.
9. Enter: LS
10. At the "Proceed with conversion?" prompt, enter: y
11. Select an option to distribute Virtual Systems among members:
    1. Distribute all Virtual Systems equally.
    2. Set all Virtual Systems as Active on the same member.