The information you are about to copy is INTERNAL!
DO NOT share it with anyone outside Check Point.
How To Create a Redundant, Service-based MPLS/Encrypted Link VPN
R71, R75, R76, R77, R77.10, R77.20, R77.30
SecurePlatform 2.6, Gaia, Linux
Platform / Model
Show more details
Show less details
Note: This article is related only to IPv4 traffic. IPSO acceleration is not supported with solution. Service based link selection is NOT supported for Check Point R77.20 for 600 / 700 /1100 / 1200R / 1400 Appliances
Table of Contents:
In some IT topologies, 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 may wish that certain services will be routed though the MPLS link in clear-text, while other services will be forwarded encrypted via the Internet link.
On top of this topology, availability is required: traffic should be rerouted on the available link once a certain link goes down.
This article presents such a topology, describing the network requirements and displays the configuration steps for setting it up.
VoIP traffic (control and data connections) and HTTP connections should be routed through eth1 interfaces of the gateways, in clear text, i.e., the MPLS link.
All other traffic (except VoIP and HTTP) should be routed, encrypted, via eth0 interfaces of the gateways.
If the clear-text link (MPLS) should go down, VoIP traffic should be rerouted (failover VoIP) to the encrypted link, without breaking any SIP session. However, the HTTP traffic is required to stay on the MPLS link (do not failover HTTP).
If the encrypted link goes down, all of its traffic should be rerouted via the MPLS link in clear-text packet.
When a failed link recovers the, initial service-based link selection policy should be enforced again.
Basic VPN Configuration
Enable VPN IPSec blade on both "London_GW" and "Paris_GW" gateways.
In the 'Topology' tab of each VPN gateway, check that the VPN Domain is properly set.
Add "London_GW" and "Paris_GW" gateways to Site-to-Site VPN community.
VPN Service-Based Link Selection
In the Link Selection page of each VPN gateway, select "Use probing" and choose "Load Sharing" as link redundancy mode. For example, snapshot taken from "London_GW":
Setting "Use probing" as link selection method in a gateway object, in this case "London_GW", will cause peer gateways member in the VPN community, such as "Paris_GW", to send RDP probing packets toward the gateway IP addresses in order to detect which link is alive.
Once the available links were mapped, according to the Link redundancy mode, VPN connections will be routed on the available links by the peer gateways. For High Availability, all the VPN connections will be routed via one available link (the primary if configured). With "Load Sharing" the VPN connections will be shared equally between the available links. For configuring service-based link selection "Load Sharing" should be selected on both gateways, as each gateway will route VPN connections on more than one available link.
Open the "Probing Settings" dialog by pressing on the "Configure" button in the Link Selection page. Choose "Probe the following addresses" and add IP addresses of eth0 and eth1 of the configured gateway.
This way, the peer gateways will send RDP probing packets only to the relevant IP addresses available for VPN and not to all of the interfaces of the gateway (default option)
Back in the Link Selection page of each gateway select "Route Based probing".
Service-based Link Selection always requires "Route based probing" to be enabled even if alternative routes with lower metric are not defined.
[Optional] Configure faster detection of link failure. By default RDP session starts each 30 seconds and it can take up to 10 seconds for waiting for RDP reply packet before concluding a link is down. So in the worst case it takes 40 seconds until traffic will (failover) be rerouted on available link.
To improve link failure detection: SmartDashboard - go to 'Policy' menu - click on 'Global Properties' - go to 'SmartDashboard Customization' - at the bottom, click on 'Configure...' button - expand 'Firewall-1' section - go to 'Resolver'.
change "resolver_session_interval" from 30 to 10
change "resolver_ttl" from 10 to 5
These RDP resolver settings also affect Secure Clients using probing to detect available link to the Remote Access gateway, that is why the defaults are little too high. It is recommended to change the defaults for site-to-site topologies such as described here to get faster link failure detection.
Service-Based Link Selection settings
Edit the following Service Based Link Selection configuration file on the Management Server:
The services that are explicitly configured within the configuration file, SIP and HTTP, will be rerouted on the outgoing interfaces they were configured with, in this case eth1 interfaces (MPLS link). The rest of the traffic will be delivered by other available links that are not including eth1 as outgoing interface. In this case all other traffic will be rerouted through eth0 interfaces of each gateway (Internet link)
Suppose all outgoing interfaces are configured with certain service, all other services that are not explicitly configured will be load shared between the available links. For example, suppose HTTP would have been configured on eth0 on both gateways, then SIP traffic would have been enforced on MPLS link (eth1 interfaces), HTTP on the Internet link (eth0 interfaces) and all the other traffic will be load shared between the two links.
The gateways names, their interfaces and the services should match the names given in the SmartDashboard. It is also possible to quote service group containing multiple services in the Service column.
Configuring MPLS link as clear-text, trusted link.
Both end point interfaces of the trusted (MPLS) link: eth1@London_GW and eth1@Paris_GW, should be configured as "VPN trusted".
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, go to 'Table' - 'Network Objects' - 'network_objects'.
In the right upper pane, select the relevant Security Gateway / Cluster object - follow this procedure for "London_GW" gateway and for "Paris_GW" gateway.
Press CTRL+F (or go to 'Search' menu - 'Find') - paste vpn_trusted - click on 'Find Next'.
In the lower pane, under "eth1" interface (refer to 'officialname' attribute) - right-click on the vpn_trusted - 'Edit...' - choose "true" - click on 'OK'.
Save the changes: go to 'File' menu - click on 'Save All'.
Close the GuiDBedit Tool.
Connect to Security Management Server / Domain Management Server with SmartDashboard.
Install the policy onto the relevant Security Gateway / Cluster object.
Example for "London_GW" gateway:
To detect availability of the links between the gateways and to be able to reroute connections according to the service-based link selection policy, it is sufficient to set the routes only between the external interfaces of the VPN gateways: RDP packets and IPSec packets designated to eth0 of the peer gateway should be routed via the next hop router connected to eth0 of the local gateway. Same goes for eth1: packets designated to the IP address of eth1 of the peer gateway should go through eth1 of the local gateway.
In the local VPN gateway there is no need to add routes to reach the peer gateway VPN domain through the two links. However, since on the MPLS link, the packets delivered as clear-text, routes to the VPN domains should be defined in the MPLS routers (connected to eth1).
If Redundancy is required for all the services then skip configuration step 2.E
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 /1100 / 1200R / 1400 Appliances. VPN traffic between peers configured with Load Sharing or Service-Based link selection is not accelerated by IPSO acceleration devices.
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.
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.