Link Selection

Link Selection Overview

Link Selection is a method to define which interface is used for incoming and outgoing VPN traffic as well as the best possible path for the traffic. With the Link Selection mechanisms, the administrator can choose which IP addresses are used for VPN traffic on each Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources..

Link Selection has many configuration options to enable you to control VPN traffic. These options include:

• Use probing to choose links according to their availability.

• Use Load Sharing for Link Selection to distribute VPN traffic over available links.

• Use Service Based Link Selection to control bandwidth use.

Configuration settings for remote access clients can be configured together or separately from the Site-to-Site configuration.

Configuring IP Selection by Remote Peer

There are several ways to configure how a Remote Peer resolves the IP address of the local Security Gateway.

Last Known Available Peer IP Address

The IP address used by a Security Gateway during a successful IKE negotiation with a peer Security Gateway, is used by the peer Security Gateway as the destination IP address for the next IPsec traffic and IKE negotiations that it initiates. This is only the case when the Link Selection configuration does not use probing.

Configuring Outgoing Route Selection

For outbound traffic, there are different methods that can be used to determine which path to use when connecting with a remote peer. These settings are configured in Security Gateway Properties > IPsec VPN > Link Selection.

When Initiating a Tunnel:

• Operating system routing table (default setting) - With this method, the routing table is consulted for the available route with the lowest metric and best match for the VPN tunnel traffic.

• Route based probing - This method also consults the routing table for an available route with the lowest metric and best match. However, before a route is chosen, it is tested for availability with RDP probing. The Security Gateway then selects the best match (highest prefix length) active route with the lowest metric. This method is recommended when there is more than one external interface.

  If you selected the IP Selection by Remote Peer setting of Use probing with Load Sharing, it also affects Route based probing link selection. In this case, Route based probing distributes the outgoing encrypted traffic among all available links. All possible links to the peer Security Gateway are derived from the routing table and the link's availability is tested with RDP probing. Every new connection ready for encryption uses the next available link in a round robin manner.

  Route based probing enables the use of On Demand Links (ODL), which are triggered upon failure of all primary links. You can run a script to activate an On Demand Link when all other links with higher priorities become unavailable. For more information, see the section "On Demand Links".

  For IKE and RDP sessions, Route based probing uses the same IP address and interface for responding traffic.

  Notes: The High Availability mechanism is based on: resolver_session_interval (30) - Defines for how many seconds the remote peer status (up or down) stays valid resolver_ttl (10) - Defines how many seconds the Security Gateway waits before it decides that a remote peer is down

  Some network protocols (for example, TCP) might timeout in the time between link failure and the next attempt to resolve. Administrators can decrease these default values. Note that high resolution frequency can overload the Security Gateway. This configuration also changes the default resolution timeouts for the MEP mechanism.

  For Layer 2 links, there must be routes to the peer's encryption domains through the local Layer 2 interface device.

When Responding to a Remotely Initiated Tunnel

When responding to a remotely initiated tunnel, there are two options for selecting the interface and next hop that are used. These settings are only applicable for IKE and RDP sessions.

These settings are configured in Link Selection > Outgoing Route Selection > Setup > Link Selection - Responding Traffic window.

• Use outgoing traffic configuration - Select this option to choose an interface with the same method selected in the Outgoing Route Selection section of the Link Selection page.

• Reply from the same interface - This option sends the returning traffic through the same interface and next hop IP address through which it arrived.

Note - When Route Based Probing is enabled, Reply from the same interface is the selected method and cannot be changed.

Using Route Based Probing

The local Security Gateway, with RDP probing, considers all possible routes between itself and the remote peer Security Gateway. The Security Gateway then decides on the most effective route between the two Security Gateways:

In this scenario, Security Gateway A has two external interfaces, 192.168.10.10 and 192.168.20.10. Peer Security Gateway B also has two external interfaces: 192.168.30.10 and 192.168.40.10.

For Security Gateway A, the routing table reads:

Destination	Netmask	Next hop	Metric
192.168.40.10	255.255.255.0	192.168.10.20	1
192.168.40.10	255.255.255.0	192.168.20.20	2
192.168.30.10	255.255.255.0	192.168.10.20	3
192.168.30.10	255.255.255.0	192.168.20.20	4

For Security Gateway B, the routing table reads:

Destination	Netmask	Next hop	Metric
192.168.20.10	255.255.255.0	192.168.40.20	1
192.168.20.10	255.255.255.0	192.168.30.20	2
192.168.10.10	255.255.255.0	192.168.40.20	3
192.168.10.10	255.255.255.0	192.168.30.20	4

If all routes for outgoing traffic from Security Gateway A are available, the route from 192.168.10.10 to 192.168.40.10 has the lowest metric (highest priority) and is therefore the preferred route.

Source IP Address Settings

Outgoing Link Tracking

When Outgoing link tracking is activated on the local Security Gateway, the Security Gateway sends a log for every new resolving decision performed with one of its remote VPN peers.

If Use Probing is configured on the local Security Gateway for Remote Peer resolving, or if Route Based Probing is activated on the local Security Gateway, log entries are also created for all resolving changes. For example, if a link in use becomes unavailable and a new available link is chosen, a log entry is issued.

Link Selection Scenarios

Link Selection can be used in many environments. This section describes various scenarios and how Link Selection should be configured in each scenario.

Security Gateway with a Single External Interface

This is the simplest scenario, where the local Security Gateway has a single external interface for VPN:

How do peer Security Gateways select an IP address on the local Security Gateway for VPN traffic?

Since there is only one interface available for VPN, to determine how remote peers determine the IP address of the local Security Gateway, select the following from the IP Selection by Remote Peer section of the Link Selection page:

• Select Main address or choose an IP address from the Selected address from topology table drop down menu.

• If the IP address is located behind a static NAT device, select Statically NATed IP.

Security Gateway with Several IP Addresses Used by Different Parties

In this scenario, the local Security Gateway has a point-to-point connection from two different interfaces. Each interface is used by a different remote party:

The local Security Gateway has two IP addresses used for VPN. One interface is used for VPN with a peer Security Gateway A and one interface for peer Security Gateway B.

To determine how peer Security Gateways discover the IP address of the local Security Gateway, enable one-time probing with High Availability redundancy mode. Since only one IP is available for each peer Security Gateway, probing only has to take place one time.

Security Gateway with an Interface Behind a Static NAT Device

In this scenario, the local Security Gateway has two external interfaces available for VPN.

The IP address of interface eth0 is translated using a NAT device:

To determine how peer Security Gateways discover the IP address of the local Security Gateway, use ongoing probing with High Availability redundancy mode.

In order for the Static NAT IP address to be probed, it must be added to the Probe the following addresses list in the Probing Settings window.

Utilizing Load Sharing

Depending on your configuration, there are many ways to use Load Sharing to distribute VPN traffic among available links between the local and peer Security Gateways.

Load Sharing with Multiple External Interfaces on Each End

In the following scenario, the local and peer Security Gateways each have two external interfaces available for VPN traffic.

To utilize both external interfaces by distributing VPN traffic among all available links, use the Probing redundancy mode of Load Sharing on both Security Gateways. You can also specify that only certain external interfaces should be probed by putting only those interfaces in the Probe the following addresses list in the Probing Settings window. If one link goes down, traffic will automatically be rerouted through the other link.

To enable this configuration, make sure that your routing table allows packet flow back and forth between both eth0 interfaces and packet flow back and forth between both eth1 interfaces. Then Link Selection can reroute the VPN traffic between these available links.

Load Sharing with Multiple External Interfaces on One End

In the following scenario, the local Security Gateway has two external interfaces available for VPN traffic. The peer Security Gateway has one external interface for VPN traffic.

To utilize both external interfaces and distribute VPN traffic between the available links, use the Probing redundancy mode of Load Sharing on the local Security Gateway. Then the peer Security Gateway will distribute its outgoing VPN traffic between interfaces eth0 and eth1 of the local Security Gateway.

If the default, Operating system routing table, setting in the Outgoing Route Selection section is selected, the local Security Gateway will only use one of its local interfaces for outgoing VPN traffic; the route with the lowest metric and best match to reach the single IP address of the peer Security Gateway, according to the routing table.

If you want to distribute the outgoing VPN traffic on both outbound links from the local Security Gateway as well, select Route Based Probing in the Outgoing Route Selection on the Link Selection page of the local Security Gateway.

Service Based Link Selection

Service Based Link Selection enables administrators to control outgoing VPN traffic and bandwidth use by assigning a service or a group of services to a specific interface for outgoing VPN routing decisions. The encrypted traffic of an outgoing connection is routed through the configured interface according to the traffic's service. The links to the peer Security Gateway are derived from the routing table and the link's availability is tested with RDP probing.

If all links through the interface assigned to a specific service stop responding to RDP probing, a link failover will occur by default, as in any other probing mode. When a link through the assigned interface is restored, new outgoing connections are assigned to it, while existing connections are maintained over the backup link until they are completed.

It is possible to configure the traffic of a specific service not to fail over. In this case, traffic of the configured service will only be routed through interfaces assigned to this service, even if these interfaces stop responding to RDP.

If the same service is assigned to more than one interface, this service's traffic is distributed between the configured interfaces. Every new outgoing encrypted connection uses the next available link in a round robin manner.

All traffic from services that are not assigned to a specific interface is distributed among the remaining interfaces. If all links through these interfaces are down, the traffic is distributed among the interfaces that are configured for specific services.

Service Based Link Selection configuration requires enabling the following features:

• IP Selection by Remote Peer - Load Sharing probing mode

• Outgoing Route Selection - Route based probing

• Service Based Link Selection - Configuration file on the management server

Service Based Link Selection is supported on Security Gateways R71 and higher. Service Based Link Selection is not supported on UTM-1 Edge devices.

Configuring Service Based Link Selection

To configure Service Based Link Selection:

1. In the Link Selection page, in the IP Selection by Remote Peer section, select:

   • Use probing. Redundancy mode

   • Load Sharing

2. In the Outgoing Route Selection section, select Route based probing.

Edit the Service Based Link Selection configuration in the $FWDIR/conf/vpn_service_based_routing.conf configuration file on the management server.

Fill in each line in the configuration file to specify the target Security Gateway, the interface for outgoing routing, and the service (or services group) to route through this interface. Use the names defined in the 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.. Fill in all of the details for each Security Gateway on which you want to configure Service Based Link Selection.

The fields are:

• Gateway - Security Gateway name (the name of the VPN Security Gateway or the cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing.).

• Interface - Interface name.

• Service - Service or services group name.

• dont_failover - (Optional) If this string is present, traffic of the configured service will only be routed through interfaces configured for this service and will not fail over to another interface.

Service Based Link Selection Scenarios

The following scenarios provide examples of how Service Based Link Selection can be utilized.

Service Based Link Selection with Two Interfaces on Each End

In the scenario below, the local and peer Security Gateways each have two external interfaces for VPN traffic.

In this example, interface eth1 of both Security Gateways is dedicated to HTTP and FTP traffic. All other traffic is routed to interface eth0.

If the available link through eth1 stops responding to RDP probing, HTTP and FTP traffic will fail over to eth0. It is possible to specify that HTTP and FTP traffic should only be routed through eth1 even if the link through eth1 stops responding. Specify this by including the dont_failover flag when editing the Service Based Link Selection configuration file.

All other traffic that is not HTTP or FTP will be routed through eth0. If the link through eth0 stops responding to RDP probing, all traffic will be routed through eth1.

The Service Based Link Selection configuration file for this environment should appear as follows:

Security Gateway	Interface	Service	[dont_failover]
London_GW	eth1	http
London_GW	eth1	ftp
Paris_GW	eth1	http
Paris_GW	eth1	ftp

Alternatively, in SmartConsole, you can create a Services Group that includes HTTP and FTP services. In the example below, this group is called http_ftp_grp. With this group, the Service Based Link Selection configuration file for this environment should appear as follows:

Security Gateway	Interface	Service	[dont_failover]
London_GW	eth1	http_ftp_grp
Paris_GW	eth1	http_ftp_grp

Service Based Link Selection with Multiple Interfaces on Each End

In the following scenario, the local and peer Security Gateways each have three external interfaces available for VPN.

To utilize all three external interfaces and distribute the VPN traffic among the available links, Link Selection Load Sharing and Route based probing should be enabled. To control your bandwidth use, dedicate one or more links to a specific service or services using Service Based Link Selection. In this scenario, interfaces eth0 and eth1 of both Security Gateways are dedicated to SIP traffic. SIP traffic is distributed between eth0 and eth1. All other traffic is routed through eth2.

If either the link through eth0 or the link through eth1 stops responding to RDP probing, SIP traffic will fail over to the other SIP interface. If the link through eth2 stops responding to RDP probing, all traffic will be routed though eth0 or eth1.

Service Based Link Selection with Two Interfaces on One End

In the following scenario, the local Security Gateway has two external interfaces available for VPN traffic. The peer Security Gateway has a single external interface for VPN traffic.

To utilize all external interfaces and distribute the VPN traffic among the available links, Link Selection Load Sharing and Route based probing should be enabled on the local Security Gateway, London_GW. To control your bandwidth use, dedicate interface eth1 of the local Security Gateway to HTTP and FTP traffic using Service Based Link Selection. The local Security Gateway will route outgoing HTTP and FTP connections through interface eth1. All other traffic, not HTTP or FTP, will be routed through eth0.

In this scenario, HTTP and FTP traffic should not fail over. HTTP and FTP traffic should only be routed through interface eth1, even if the link through interface eth1 stops responding to RDP probing. This is configured by specifying the dont_failover flag.

The Service Based Link Selection configuration file for this environment should appear as follows:

Security Gateway	Interface	Service	[dont_failover]
London_GW	eth1	http	dont_failover
London_GW	eth1	ftp	dont_failover

Since the Service Based Link Selection configuration is only applicable for outgoing traffic of the local Security Gateway, the peer Security Gateway can send HTTP and FTP traffic to either interface of the local Security Gateway. The outgoing VPN traffic of the peer Security Gateway is distributed between interfaces eth0 and eth1 of the local Security Gateway.

Trusted Links

Trusted Links allows you to set an interface as "trusted" for VPN traffic so that traffic sent on that link will not be encrypted. You may want to set up a trusted link if you are confident that the link is already encrypted and secure and you do not need a second encryption.

If you configure an interface as trusted, traffic routed through that interface will be sent unencrypted, while traffic sent through other interfaces will still be encrypted.

Trusted interfaces should be configured symmetrically on the local and peer Security Gateways. If only one side of the link is configured as trusted for VPN traffic, clear traffic received by a non-trusted interface will be dropped by the peer Security Gateway.

If you have configured a specific link as trusted for VPN traffic and you use probing, the probing method considers all links, including the trusted link, when choosing a link for a connection.

The probing method chooses the link according to these criteria:

• The configured redundancy mode, High Availability or Load Sharing

• If Service Based Link Selection is configured.

If the trusted link is chosen for a connection, the traffic is not encrypted. If another, non-trusted, link is chosen, the traffic is encrypted.

In an MEP configuration, trusted links are only supported for connections initiated by a peer Security Gateway to a MEP Security Gateway. Unencrypted VPN connections routed through a trusted interface and initiated by a MEP Security Gateway may be dropped by the peer Security Gateway.

Trusted links are not supported in Traditional mode. In Traditional mode, trusted link settings are ignored and VPN traffic is always encrypted.

Trusted links are supported on Security Gateways R71 and higher.

Configuring Trusted Links

Use the Database Tool (GuiDBEdit Tool) (see sk13009) to configure Trusted Links.

To configure a trusted link:

1. In the top left pane, go to Network objects > network_objects.

2. In the top right pane, click the Security Gateway / Cluster object that you want to edit.

3. In the bottom pane, search for the interface that you want to configure as trusted from within the interfaces set. The interface name appears in the officialname attribute.

4. Within the trusted interface set, change the value of the vpn_trusted attribute to true (default value: false).

5. Configure trusted interfaces symmetrically on the peer Security Gateways. If only one side of the link is configured as trusted for VPN traffic, clear traffic received by a non-trusted interface will be dropped by the peer Security Gateway.

6. Save changes (File menu > Save All).

7. In SmartConsole, install the Access Control Policy on the Security Gateway / Cluster object.

Trusted Links Scenarios

In the following scenario, both the local and peer Security Gateways have two external interfaces available for VPN traffic. Interface eth1 on both Security Gateways has been configured as a trusted interface. Therefore, traffic sent from eth1 of the local Security Gateway is sent unencrypted and is accepted by interface eth1 of the peer Security Gateway, and the other way around.

If the probing redundancy mode is High Availability and the trusted link is configured as the Primary IP address, the trusted link will be used for VPN traffic. If the trusted link stops responding to RDP probing, the link through Interface eth0 will be used for VPN traffic and traffic will be encrypted.

If the probing redundancy mode is Load Sharing, the VPN traffic will be distributed between the available links. Connections routed through interface eth0 will be encrypted while connections routed through the trusted link will not be encrypted.

Using Trusted Links with Service Based Link Selection

In the following scenario, the local and peer Security Gateways have two external interfaces available for VPN traffic. Interface eth1 on both Security Gateways is configured as a trusted interface for VPN traffic since encryption is not needed on that link. In addition, interface eth1 of both Security Gateways is dedicated to SIP traffic using Service Based Link Selection.

SIP traffic is routed through the trusted link between the two eth1 interfaces and will not be encrypted. If the trusted link stops responding to RDP probing, SIP traffic will be routed through the eth0 interfaces and will be encrypted.

All other traffic that is not SIP is encrypted and routed through the interface eth0 link. However, if interface eth0 stops responding to RDP probing, all the traffic will be routed through the trusted link and will not be encrypted.

On Demand Links (ODL)

Route based probing enables use of an On Demand Link (ODL), which is triggered upon failure of all primary links. When a failure is detected, a custom script is used to activate the ODL and change the applicable routing information. The ODL's metric must be set to be larger than a configured minimum in order for it to be considered an ODL.

The Security Gateway has two external links for Internet connectivity: one to an ISP, the other to an ISDN dialup. The ISDN dialup connection is configured as an On Demand Link.

On the Security Gateway, the Route Based Probing mechanism probes all of the non-On Demand Links and selects the active link with the lowest metric. In this case, it probed the ISP link. A script is run to activate the On Demand Link when all other links with higher priorities become unavailable. When the link becomes available again, a shutdown script is run automatically and the connection continues through the link with the ISP.

Note - On Demand Links are probed only once with a single RDP session. Fail over between On Demand Links is not supported.

Configuring On Demand Links

You can enable On Demand Links only if you enabled Route Based Probing. Configure On Demand Links commands in Database Tool (GuiDBEdit Tool) (see sk13009).

Property	Description
use_on_demand_links	Enables on-demand links. The default is false. Change to true.
on_demand_metric_min	Defines the minimum metric level for an on-demand link. This value must be equal to or higher than the configured minimum metric.
on_demand_initial_script	The name of the on-demand script, which runs when all not-on-demand routes stop responding. Put the script in the $FWDIR/conf/ directory.
on_demand_shutdown_script	This script is run when the failed links become available. Put the script in the $FWDIR/conf/ directory.

If you do not want to use Database Tool (GuiDBEdit Tool), you can configure the use_on_demand_links and on_demand_metric_min settings in SmartConsole:

1. Click Menu > Global properties.

2. Click Advanced > Configure.

3. Click VPN Advanced Properties > Link Selection.

4. Select use_on_demand_links to enable On Demand Links.

5. In the on_demand_metric_min field, set the minimum metric level for an On Demand Link.

6. Click OK.

7. Click OK.

8. Install the Access Control Policy.

Link Selection and ISP Redundancy

ISP Redundancy enables reliable Internet connectivity by allowing a single or clustered Security Gateway to connect to the Internet via redundant ISP connections. As part of standard VPN installation, it offers two modes of operation:

• Load Sharing mode

• Primary/Backup mode

Configuring Link Selection and ISP Redundancy

Configure Link Selection and ISP Redundancy in the Other > ISP Redundancy page of the Security Gateway object:

• Load Sharing mode connects to both ISPs while sharing the load of outgoing connections between the ISPs according to a designated weight assignment. New connections are randomly assigned to a link. If a link fails, all new outgoing connections are directed to the active link. This configuration effectively increases the WAN bandwidth while providing connectivity protection. The assigned ISP Links weight is only supported for Security Gateway traffic.

• Primary/Backup mode connects to an ISP through the primary link, and switches to a backup ISP if the primary ISP link fails. When the primary link is restored, new outgoing connections are assigned to it, while existing connections are maintained over the backup link until they are complete.

The settings configured in the ISP Redundancy window are by default, applied to the Link Selection page and will overwrite any pre-existing configuration. The following settings carry over:

• When ISP Redundancy is configured, the default setting in the Link Selection page is Use ongoing probing. However, Link Selection only probes the ISPs configured in the ISP Redundancy window. This enables connection failover of the VPN tunnel if connectivity to one of the Security Gateway interfaces fails.

• If the ISP Redundancy mode is Load Sharing, the Probing redundancy mode in the Link Selection page is also Load Sharing.

• If the ISP Redundancy mode is Primary/Backup, the Probing redundancy mode in the Link Selection page is High Availability.

  • The Primary ISP link of the ISP redundancy is set as the Primary Address of the Link Selection probing. The Primary Address is set under: IP Selection by Remote Peer > Use Probing > Configure (or View, if the settings are derived from the ISP Redundancy settings).

If you do not want the ISP Redundancy settings to affect the Link Selection settings, on the ISP Redundancy page, clear the check box that says Apply settings to VPN traffic and configure the required VPN settings on the Link Selection page. This may apply when you want to route VPN traffic differently than the clear traffic. For example, if you want to use Load Sharing for clear traffic and High Availability for VPN traffic, or if you want to use different primary ISPs for clear and VPN traffic.

Link Selection and ISP Redundancy

In the following scenario, the local Security Gateway maintains links to ISPs A and B, both of which provide connectivity to the Internet with ISP Redundancy.

In the Topology > ISP Redundancy window, configure the ISP Redundancy settings, such as ISP Links and Redundancy mode. The ISP Redundancy settings are applied by default to VPN traffic. The derived Link Selection settings are visible in the IPsec VPN > Link Selection window.

In the following scenario, the Apply settings to VPN traffic on the ISP Redundancy page was cleared, and there are different setting configured for Link Selection and ISP Redundancy.

In this scenario:

• Security Gateways A, B, and C each have two interfaces configured as ISP links.

• ISP Redundancy is configured on Security Gateway A.

• Security Gateway A should use ISP 1 in order to connect to Security Gateway B and ISP 2 in order to connect to Security Gateway C. If one of the ISP links becomes unavailable, the other ISP should be used.

In this scenario, the administrator of Security Gateway A needs to:

• Clear the box Apply settings to VPN traffic in the ISP Redundancy window.

• Reconfigure the Outgoing Route Selection to Route Based Probing in the Link Selection window.

• Configure the routing table so that ISP 1 is the highest priority for peer Security Gateway B and ISP 2 has the highest priority for peer Security Gateway C.

Link Selection with non-Check Point Devices

RDP probing, the probing method used for certain Link Selection features, is proprietary to Check Point and only works between Check Point entities. It is not supported with non-Check Point devices.

Since RDP probing is not active on non-Check Point Security Gateways, the following results apply if a Check Point Security Gateway sends VPN traffic to a non-Check Point Gateway:

• Use probing cannot be used by locally managed Check Point Security Gateways to determine the IP address of non-Check Point devices. Any of the other methods available from the IP Selection by Remote Peer section can be used.

• Load Sharing and Service Based Link Selection do not work with non-Check Point Gateways. If Load Sharing or Service Based Link Selection is enabled on the local Security Gateway, but the peer is a non-Check Point device, the local Security Gateway will only use one link to the non-Check Point device: the best match (highest prefix length) link with the lowest metric.

• If Route based probing is selected as the Outgoing Route Selection method, for VPN traffic to a non-Check Point device, the local Security Gateways always use the best match (highest prefix length) link with the lowest metric.