Home Page | Skip to Navigation | Skip to Content | Skip to Search | Skip to Footer
 Support Center > Search Results > SecureKnowledge Details
Support Center
 Print    Email
How To Create a Redundant, Service-based MPLS/Encrypted Link VPN

Solution ID: sk56384
Product: IPSec VPN
Version: R71, R75, R76, R77
OS: SecurePlatform 2.6, Gaia, Linux
Platform / Model: All
Date Created: 28-Oct-2010
Last Modified: 05-Jan-2014
Rate this document
[1=Worst,5=Best]
Solution

Note: This article is related only to IPv4 traffic. IPSO acceleration is not supported with solution.

Table of Contents:

  • Background
  • Topology
  • Network Requirements
  • Configuration
  • FAQ

 

Background

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.

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.

 

Topology

 

Network Requirements

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

  2. All other traffic (except VoIP and HTTP) should be routed, encrypted, via eth0 interfaces of the gateways.

  3. 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).

  4. If the encrypted link goes down, all of its traffic should be rerouted via the MPLS link in clear-text packet.

  5. When a failed link recovers the, initial service-based link selection policy should be enforced again.

 

Configuration

  1. Basic VPN Configuration

    1. Enable VPN IPSec blade on both "London_GW" and "Paris_GW" gateways.

    2. In the 'Topology' tab of each VPN gateway, check that the VPN Domain is properly set.

    3. Add "London_GW" and "Paris_GW" gateways to Site-to-Site VPN community.


  2. VPN Service-Based Link Selection

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

    2. 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)

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

    4. [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'.

      For example:

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

    5. Service-Based Link Selection settings

      Edit the following Service Based Link Selection configuration file on the Management Server:

      $FWDIR/conf/vpn_service_based_routing.conf

      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.



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

    The trusted interface is configured using GuiDBedit Tool

    1. Close all SmartConsole windows (SmartDashboard, SmartView Tracker, SmartView Monitor, etc.).

    2. Connect to Security Management Server / Domain Management Server with GuiDBedit Tool.

    3. In the left upper pane, go to 'Table' - 'Network Objects' - 'network_objects'.

    4. In the right upper pane, select the relevant Security Gateway / Cluster object - follow this procedure for "London_GW" gateway and for "Paris_GW" gateway.

    5. Press CTRL+F (or go to 'Search' menu - 'Find') - paste vpn_trusted - click on 'Find Next'.

    6. In the lower pane, under "eth1" interface (refer to 'officialname' attribute) - right-click on the vpn_trusted - 'Edit...' - choose "true" - click on 'OK'.

    7. Save the changes: go to 'File' menu - click on 'Save All'.

    8. Close the GuiDBedit Tool.

    9. Connect to Security Management Server / Domain Management Server with SmartDashboard.

    10. Install the policy onto the relevant Security Gateway / Cluster object.

    Example for "London_GW" gateway:



  4. Install policy.

  5. Routing.

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

 

FAQ

Show All
  • Which platforms are supported?
    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.
    VPN traffic between peers configured with Load Sharing or Service-Based link selection is not accelerated by IPSO acceleration devices.
  • What are the related limitations for R71 and above?
    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.
  • Consider there are more than one encrypted links between the gateways, are different VPN tunnels generated per each link?
    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.
  • What happens when all links between the VPN gateways are down?
    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:
    1. SmartDashboard - go to 'Policy' menu - click on 'Global Properties' - go to 'SmartDashboard Customization' - at the bottom, click on 'Configure...' button.
    2. Expand 'VPN Advanced Properties' section - go to 'Link Selection'.
    3. Check the box 'use_on_demand_links'.
    4. 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).
    5. Click on 'OK' to apply the settings.
    6. Save the changes: go to 'File' menu - click on 'Save'.
    7. 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).
  • Can I use Service-Based link selection to route only clear-text traffic, with no encryption?
    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:
    1. Even though all links between the gateways are defined as trusted, IKE negotiation will still run before sending the traffic.
    2. SXL Accept templates will not be supported, increasing latency on the first packet of the connection.
  • How about interoperability with non Check Point VPN devices?
    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.
  • Is Route Based VPN supported?
    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.
  • Can certain service's be load shared between few links?
    Yes. For example, consider the following 'vpn_service_based_routing.conf' file:

    SIP traffic will be load shared between eth1 and eth2 of each gateway

  • If a link goes down all of its related traffic will failover to the secondary link. Once the link is restored will all the related traffic return to the restored link?
    Only new connections will start via the restored link, old connections will stay on the secondary link.

Give us Feedback
Rate this document
[1=Worst,5=Best]
Additional comments...(Max 2000 characters allowed)
Characters left: 2000