Note: This article is related only to IPv4 traffic. IPSO acceleration is not supported for this solution.
Table of Contents:
Background
Topology
Network Requirements
Configuration
FAQ
Background
In some network topologies, a clear-text MPLS link (encryption is not required) is deployed in addition to an encrypted Internet link between Check Point VPN Gateways. (The MPLS link should be defined as external or have the networks exempt from the Anti-Spoofing list).
Customers can configure certain services to be routed through the MPLS link in clear-text, while other services are forward encrypted through the Internet link.
This topology requires an available route. If a link goes down, the VPN Gateway reroutes traffic on another available link.
This article shows the topology, describes the network requirements, and provides the configuration procedure.
Topology
Network Requirements
VoIP traffic (control and data connections) and HTTP connections are routed through the eth1 interfaces of the VPN Security Gateways in clear text through the MPLS link.
All other traffic (except VoIP and HTTP) is encrypted and routed through the eth0 interfaces of the VPN Security Gateways.
If the clear-text link (MPLS) fails, VoIP traffic is rerouted (failover VoIP) to the encrypted link, without breaking any SIP session. However, the HTTP traffic stays on the MPLS link, and does not fail over.
If the encrypted link goes down, all of its traffic is rerouted through the MPLS link clear-text packets.
When a failed link recovers, the initial service-based link selection policy is enforced again.
Configuration
This configuration is based on the topology diagram shown above.
Basic VPN Configuration:
Enable VPN IPSec blade on both the London_GW and Paris_GW VPN Security Gateways.
In the Topology tab of each VPN Security Gateway, make sure the VPN Domain is properly configured.
Add the London_GW and Paris_GW VPN Security Gateways to a Site-to-Site VPN community.
Install the policy.
VPN Service-Based Link Selection:
In the Link Selection page of eachVPN Security Gateway, select Use probing and choose Load Sharing as the link redundancy mode. For example:
Setting Use probing as the link selection method in a VPN Security Gateway object. London_GW causes peer members in the VPN community, such as Paris_GW, to send RDP probing packets toward the VPN Security Gateway IP addresses to detect which link is alive.
Once the peer VPN Security Gateways map available links according to the Link redundancy mode, VPN connections are routed on the available links.
In a High Availability configuration, all VPN connections are routed through one available link. You can configure a primary link as the default for this configuration.
In a Load Sharing configuration, VPN connections are shared equally between two available links. To configure service-based link selection, you should select Load Sharing on both VPN Security Gateways. This is because in Load Sharing configuration each VPN Security Gateway routes VPN connections on more than one available link.
On the Link Selection page, click the Configure button to open the Probing Settings dialogue. Select Probe the following addresses and add the IP addresses of eth0 and eth1 for the configured VPN Security Gateway:
This way, the peer VPN Security Gateways send RDP probing packets only to the relevant IP addresses available for VPN and not to all of the interfaces of the peer VPN Security Gateways (default option).
On the Link Selection page of each peer VPN Security Gateway, select Route Based probing.
If you enable "Service-based Link Selection," you must enable "Route based probing," even if alternative routes with lower metric are not defined.
Optional: Configure faster detection of link failure. By default, an RDP session starts at 30 second intervals. An RDP session waits up to 10 seconds for an RDP reply packet before it concludes that a link is down. Therefore, with the default settings traffic takes up to 40 seconds to reroute (failover) on the available link. These RDP resolver settings also determine how Secure Clients probe Remote Access Security Gateways to detect available links.
To improve link failure detection:
In SmartConsole, go to Menu > Global properties.
In the Advanced section at the bottom, click the Configure... button.
In the left tree, expand the Firewall-1 section.
Click Resolver.
Configure the applicable values. These RDP resolver settings also affect Remote Access VPN clients that use probing to detect available link to the VPN Gateway. Check Point recommends lower values for Site-to-Site topologies. For example:
change resolver_ttl from 10 to 5
change resolver_session_interval from 30 to 10
Service-Based Link Selection settings.
Note - If redundancy is required for all the services, then skip this step.
Edit this Service Based Link Selection configuration file on the Security Management Server:
$FWDIR/conf/vpn_service_based_routing.conf
The SIP and HTTP services that are explicitly configured within the configuration file are rerouted on the outgoing interfaces, in this case eth1 interfaces (MPLS link). The rest of the traffic is delivered by other available links that do not use eth1 as the outgoing interface. In this case, all other traffic is rerouted through the eth0 interfaces of each VPN Security Gateway (Internet link).
If all outgoing interfaces of a VPN Security Gateway are configured to use a certain service, then traffic over other services is load shared between the available links. For example, if HTTP is configured on eth0 on both VPN Security Gateways, then:
SIP traffic is enforced on the MPLS link (eth1 interfaces).
HTTP traffic is enforced on the Internet link (eth0 interfaces).
All the other traffic is load shared between the two links.
Configure the names, interfaces, and services of the two VPN Security Gateways to be the same as in SmartConsole / SmartDashboard. You can also quote a service group containing multiple services in the Service column.
Configuring an MPLS link as clear-text, trusted link.
Configure both end point interfaces of the trusted (MPLS) link, eth1@London_GW and eth1@Paris_GW, as "VPN trusted".
Configure the trusted interface with GuiDBedit Tool for the two member VPN Security Gateways (London_GW and Paris_GW):
Close all SmartConsole windows (SmartDashboard, SmartView Tracker, SmartView Monitor, etc.).
Connect to Security Management Server / Domain Management Server with GuiDBedit Tool.
In the left upper pane, select Table - Network Objects - network_objects.
In the right upper pane, select the relevant Security Gateway / Cluster object.
In the lower pane, below the eth1 interface (refer to the officialnameattribute) - right-click on vpn_trusted - Edit... - choose true - click OK.
Example for the London_GW VPN Security Gateway:
Save the changes: select File - click Save All.
Close the GuiDBedit Tool.
Connect to the Security Management Server / Domain Management Server with SmartDashboard.
Install the policy onto the relevant Security Gateway / Cluster object.
Routing.
To detect availability of the links between the VPN Security Gateways and to reroute connections according to the service-based link selection policy, set the routes only between the external interfaces of the VPN gateways.
RDP packets and IPSec packets designated to eth0 of the peer Security Gateway should be routed through the next hop router connected to the eth0 of the local Security Gateway.
The eth1 packets designated to the IP address of eth1 of the peer gateway should go through eth1 of the local VPN Security Gateway.
For the local VPN Security Gateway, you do not need to add routes to reach the peer VPN Security Gateway's VPN domain through the two links. However, since packets on the MPLS link are delivered as clear-text, routes to the VPN domains must be defined in the MPLS routers (connected to eth1).
Load Sharing Link Selection is supported in all platforms except UTM-1 Edge devices. Service-Based Link Selection is supported only in Gaia / SecurePlatform / Linux and IPSO OS. Service based link selection is NOT supported for Check Point R77.20 for 600 / 700 Appliances. VPN traffic between peers configured with Load Sharing or Service-Based link selection is not accelerated by IPSO acceleration devices.
Trusted links are not supported with star communities that have MEP configuration for the center. A single center gateway is only supported. Refer to sk115231 for more information. Services defined as port range are not supported. Only the first port in the range will be considered. Encryption logs are issued for clear-text traffic released on trusted interfaces even though the traffic was not encrypted. When Route Based VPN with OSPF is configured with load sharing or service based link selection OSPF adjacencies might be lost.
Workaround: Additional policy installation operation is restoring OSPF adjacencies. Trusted interfaces with MEP configuration are not supported. Trusted interfaces is not supported when CoreXL is enabled.
No, the VPN tunnels are only generated between VPN gateways according to the "VPN Tunnel Sharing" settings in the VPN gateway object or in the VPN community. Tunnels are not generated per link, the VPN gateway just redistributing the same VPN tunnel traffic among the available links.
Once all links are down, Service-Based initial policy will be enforced. In this case, VoIP and HTTP traffic will be rerouted through MPLS and the rest of the traffic encrypted through the Internet.
It is possible to configure an on-demand link that will be activated once all links are down:
SmartDashboard - go to 'Policy' menu - click on 'Global Properties' - go to 'SmartDashboard Customization' - at the bottom, click on 'Configure...' button.
Expand 'VPN Advanced Properties' section - go to 'Link Selection'.
Check the box 'use_on_demand_links'.
Set the minimum metric level for an on-demand link next to the 'on_demand_metric_min' command (a link is considered on-demand only if its metric is equal or higher than the configured minimum metric).
Click on 'OK' to apply the settings.
Save the changes: go to 'File' menu - click on 'Save'.
Install policy onto all involved Security Gateways.
The above and additional attributes ('on_demand_initial_script' and 'on_demand_shutdown_script') can be configured using the GuiDBedit Tool.
Refer to VPN Administration Guide (R71, R75, R75.40, R75.40VS, R76, R77) - Chapter 'Link Selection' - On Demand Links (ODL).
In some cases it is possible: first, it depends on the topology. Service-Based Link Selection can work only between two VPN gateways members in same VPN community. Service-Based Link Selection policy is applied only for VPN traffic between VPN domains of the gateways. To enable only clear-text links between the gateways (no encrypted link), ALL of the links between the VPN gateways should be configured as Trusted links (as described in this article), for the MPLS link. Setting purely trusted links between VPN gateways affects latency of the clear traffic for the following two reasons:
Even though all links between the gateways are defined as trusted, IKE negotiation will still run before sending the traffic.
SXL Accept templates will not be supported, increasing latency on the first packet of the connection.
Interoperability with non Check Point VPN gateways is not supported. RDP (probing) protocol is Check Point proprietary. Interoperable VPN devices generate VPN tunnels per interface, whereas in this solution the tunnel is generated between VPN peers regardless of the number of outgoing VPN interfaces and links deployed between the VPN gateways.
Yes. Only one VTI can be configured between a pair of VPN gateways, however if there are multiple physical links between the VPN gateways, then the link selection layer will perform the final rerouting of the VPN traffic via one of the physical interfaces, irrespective of the physical interface that is configured as the "proxy" interface for the VTI. Static routes or a dynamic routing protocol, such as OSPF, can then route traffic through the VTIs preconfigured towards other VPN peer gateways. There is no point in configuring a VTI interface to be a trusted interface as the traffic is not delivered on the VTI interface but rerouted on the physical interfaces by the link selection layer.
