NGX (R60) Link Selection VPN Deployments August 30, 2005

Size: px

Start display at page:

Download "NGX (R60) Link Selection VPN Deployments August 30, 2005"

Brice Lane
5 years ago
Views:

NGX (R60) Link Selection VPN Deployments August 30, 2005 Introduction In This Document Introduction page 1 Link Selection in NGX R60 page 1 Configuration Scenarios page 7 This document provides

In addition, the document introduces two common scenarios in which Link Selection can be used, along with a detailed explanation of how the setup should be configured.

1 NGX (R60) Link Selection VPN Deployments August 30, 2005 Introduction In This Document Introduction page 1 Link Selection in NGX R60 page 1 Configuration Scenarios page 7 This document provides general knowledge of Check Point s Link Selection capabilities, which were enhanced in VPN-1 Pro NGX. In addition, the document introduces two common scenarios in which Link Selection can be used, along with a detailed explanation of how the setup should be configured. Link Selection in NGX R60 Link Selection mechanisms help the administrator define how two peer VPN gateways find the path to establishing a tunnel between them. Link Selection was designed to answer: 1) Which IP address of the peer gateway should be used to establish the tunnel? 2) Which interface and next hop gateway should be used to reach that IP address? 3) Which IP address of the local gateway should be used as the source IP on the outgoing tunneled traffic (i.e. the encapsulating tunnel headers and tunnel establishment packets)? Where more than one path exists between two VPN peer gateways, Link Selection mechanisms can be used to fail over from one path to another, thus the resolved IP address or outbound interface may change dynamically, providing redundancy between the paths. In a typical scenario the main IP address of the gateway, i.e. the one defined in the General tab of the VPN-1 Pro Gateway object, can be used both to select the peer s IP, and to select the outgoing traffic source IP. The operating system with its IP routing capabilities can be left to handle the interface and the next hop. Copyright 2005 Check Point Software Technologies, Ltd. All rights reserved.

2 Link Selection in NGX R60 Which IP address of the peer gateway should be used to However, there are scenarios where the main IP address cannot be used. For instance, a gateway may have several IP addresses. More than one IP address can be viable for VPN establishment, and the administrator needs to be careful to choose the right one. Different peer gateways may need to choose a different IP address for connecting to the same gateway. When connecting to several ISPs, one would expect redundancy between them. To facilitate this, a gateway should be able to send traffic through the proper ISP based on availability of the ISP and of the peer gateways through each ISP. If a peer gateway has several IP addresses given to it by different ISPs, the administrator must not only choose the right IP address that remote peers will connect to but must also define which IP address to be used for failover purposes. The Link Selection settings described in this document can be modified on the Link Selection page which is located in SmartDashboard on a VPN-1 Pro Gateway object under VPN > Link Selection. Which IP address of the peer gateway should be used to establish the tunnel? There are several methods that can determine how remote peers resolve the IP address of the local Gateway. Remote peers can connect to the local Gateway using: A fixed IP address either the main IP or one of the other gateway s IP addresses. This can be configured under IP Selection by Remote Peer > Always Use this IP address. Under this option, one can configure: Main address - if this option is selected, the main IP address of the VPN-1 Pro Gateway will always be used as the destination address for VPN traffic sent to this gateway. Selected address from topology table - this option allows to select any IP address configured on the topology table (under the Topology tab on the gateway object). The IP address selected will be used as the destination IP address on all the VPN traffic sent to this VPN-1 Pro gateway. Statically NATed IP - this option allows the administrator to configure an IP address that is not one of the gateway s defined interfaces addresses to be used as the destination IP. This option can best be used in cases where the VPN-1 Pro gateway is located behind a NAT device. In order to reach such a gateway, the destination IP on the traffic sent to it should be the configured NATed IP. The result of a topological calculation, based on the information in the Topology tab of both gateways the local and the peer. This can be configured by selecting the Calculate IP based on network topology option. The result of a DNS query. This can be configured by selecting the Use DNS Resolving option. There are two options to configure the host name that will be used in the DNS query: NGX (R60) Link Selection VPN Deployments. Last Update August 30,

3 Link Selection in NGX R60 Which IP address of the peer gateway should be used to Full hostname - a full DNS name should be written (for example daip_name.checkpoint.com). Gateway s name and domain name (specified in the Global Properties) - in this case, under Global Properties > VPN > Advanced > Link Selection settings > Domain name for DNS resolving, a domain name should be specified (for example checkpoint.com ). This name will be concatenated with the host name of the VPN-1 Pro gateway object as defined in SmartCenter. This hostname will be used in a DNS query to resolve this gateway s IP address. The IP address received from the DNS server will be used as the destination IP address of traffic sent to this gateway. This is useful for gateways with a dynamically allocated address that can be updated by a DNS server. The result of actively probing to see which of the gateway s IP addresses responds. This method is useful when different peers should access different IP addresses of a gateway, as it allows each gateway to choose an appropriate IP address automatically. In addition, by using this method, a remote gateway can dynamically change the selected IP address. In order to configure this method, the Use a probing method checkbox should be checked. The probing will be done by sending RDP packets (UDP port 259) to the remote peer s IP addresses. If a response to these RDP packets is received, the remote peer s IP address would be considered available. Probing can be done once, just to determine the proper IP to be used, or it can be ongoing, which allows failing over to another IP if the chosen IP stops responding to the probes. This can be configured under the Use a probing method section. By selecting Using ongoing probing the probing will be done continuously, whereas by selecting Using one time probing the probing will take place once for each remote peer, upon initial connection with this gateway. Since some of the gateway s IP addresses may not be relevant for probing, the addresses to be probed can also be designated. Use the Configure button to open the Probing Settings window, and select between Probe all addresses defined in the Topology tab and Probe the following addresses. If the latter is selected, one can retrieve all the IP addresses defined in the Topology tab (by pressing on the Retrieve Addresses from Topology), and remove or add interfaces as needed. One of the addresses can be designated as primary, in which case it would be preferred over the others. This can be configured by entering the Configure window (under the Use a probing method section). Check the Primary address checkbox and select an IP address to be the primary IP address. By default, these configuration parameters apply for Remote Access connections as well. In order to configure a different configuration for Remote Access users, one should modify the following parameters using dbedit: Change the value of apply_resolving_mechanism_to_sr to false on the gateway s object NGX (R60) Link Selection VPN Deployments. Last Update August 30,

4 Link Selection in NGX R60 Which interface and next hop gateway should be used to Configure the Remote Access link selection method on the gateway s object using the attribute: ip_resolution_mechanism. The valid values for this property are: mainipvpn - in this case the main IP address of the VPN-1 Pro gateway will always be used as the destination address on packets sent to this gateway. singleipvpn or singlenatipvpn- if one of these values is given, then the single_vpn_ip_ra attribute should be configured to contain the specific IP address to be used. topologycalc - given this value, the IP address will be selected according to topology based calculation. onetimeprob or ongoingprob - if one of these values is configured, one time probing or ongoing probing will be applied respectfully. When these attributes are used, one can also set the following two attributes: interface_resolving_ha_primary_if - by setting an IP address as the value for this attribute, this IP address will be used as the primary IP address upon probing. use_interface_ip - by setting this attribute to true, all IP addresses defined in Topology tab should be probed. Otherwise, the attribute should be set to false. In this case, the IP addresses defined in the manual list only will be probed. This manual list can be configured by setting the attribute available_vpn_ip_list to include a list of the desired IP addresses. Which interface and next hop gateway should be used to reach the selected address? For outbound traffic, if the operating system s decision regarding which interface to use isn t good enough, Route Based Probing can be used to look at all the possible routing entries in the routing table that are relevant for reaching a peer gateway, and then probe all of them simultaneously in order to choose the best one based on the routing metric. The routing table may be updated at any time with the new and/or removed routes, either manually or with dynamic routing (i.e. BGP), and Route Based Probing will probe accordingly. The default configuration is to allow the operating system to decide on the interface for outgoing traffic. However, route based probing is supported on gateways using the SecurePlatform, IPSO or Linux platforms. In order to enable route based probing, In the Link Selection page, in the Outgoing Route Selection section, select Route based probing. This configuration is valid for traffic initiated by this gateway. In order to configure the outgoing interface of traffic sent from this gateway in response to received traffic, press the Setup button. In the Link Selection > Responding Traffic window, there are two options to be chosen from: Use outgoing traffic configuration. If this is selected, the same logic that was chosen for outgoing traffic interface selection will apply for responding traffic interface selection. The second option is Reply from the same interface - NGX (R60) Link Selection VPN Deployments. Last Update August 30,

5 Link Selection in NGX R60 Which IP address of the local gateway should be used as meaning, responding traffic will be sent from the same interface from where the traffic was received. When Route based probing is enabled, the Setup button is disabled and Reply from the same interface becomes the default method. On demand probing (relevant only when Route Based Probing is enabled) - this mode enables certain routes to be probed only when all other options have been exhausted. This is useful in cases when there s a dialup (e.g. ISDN) connection. In such a case we may wish to avoid sending traffic on this link (including the probing traffic) unless there s no other alternative. In order to configure on demand probing, using dbedit, turn the use_on_demands_links global flag to true. In addition, set the on_demand_metric_min global property to the minimum route metric value from which the interface should be probed upon demand. When this is configured, all the routes with a metric of on_demand_metric_min and above, will be probed (once) only after all the interfaces with a lower metric than on_demand_metric_min have been identified as down. When one of the non on-demand links is up again, it will start using it again and stop using the on-demand link On demand scripts - When all non on-demand links are unavailable, the on-demand initial script is invoked. If this script adds new on-demand links to the routing table, it should add them with a metric larger than on_demand_metric_min. When one of the non on-demand links is up again, the on-demand shutdown script will be scheduled. Unless all non on-demand links are down again, the shutdown script will be invoked after 15 minutes. The on-demand scripts are configured in global properties using DBedit: on_demand_initial_script the name of the initial script. The script should be located in $FWDIR/conf directory. on_demand_shutdown_script the name of the shutdown script. The script should be located in $FWDIR/conf directory. Which IP address of the local gateway should be used as the source IP on the outgoing tunneled traffic? The source IP address of outbound traffic for traffic initiated by this gateway can be configured as well, by selecting the Source IP address settings button in the Outgoing Route Selection section. In the Link Selection > Source IP Address Setting window, the source IP of traffic initiated by this gateway can be configured to be one of the following: Automatic (derived from method of IP selection by remote peer) - if this option is selected then: If the configuration of IP Selection by Remote peer is to always use the main address, then the main address will be used as the source IP of outgoing traffic. NGX (R60) Link Selection VPN Deployments. Last Update August 30,

6 Link Selection in NGX R60 Which IP address of the local gateway should be used as If the configuration of IP Selection by Remote peer is a selected address from the topology table, then this selected IP address will also be used as source IP for outgoing traffic. Any other configuration of IP Selection by Remote peer will result in using the IP address of the chosen interface as the source IP of outgoing traffic. Manual - if this option is chosen, then one of the following methods can be selected: Main IP address - meaning the main IP address of this gateway will always be used as source IP for outgoing traffic. Selected address from topology table - if this option is chosen, one of the interfaces configured on the topology table (under the Topology tab of the gateway object) can be selected. The interface selected will be used as the source IP of outgoing traffic from this gateway. IP address of chosen interface - by selecting this option, the IP address of the interface will be used as the source IP of outgoing traffic. All the configuration options specified above apply to VPN tunnel establishment (IKE and RDP packets). However, the destination IP address, source IP address and interface to be used for IPSec traffic will be derived from the Link Selection configuration, in the following manner: If the Link Selection configuration is static (meaning, no dynamic probing will take place, both for destination IP and source interface), the parameters used for the IKE negotiation will be used for the IPSec traffic. If there is a dynamic configuration, the IPSec parameters will update according to the recent dynamic findings. A dynamic configuration on a VPN-1 Pro gateway includes: A probing method for the destination IP of the remote peer gateway Route based probing for source interface The destination gateway is a MEP gateway NGX (R60) Link Selection VPN Deployments. Last Update August 30,

7 Configuration Scenarios Multiple ISPs (Link Selection) Configuration Scenarios Multiple ISPs (Link Selection) In the following configuration, two VPN-1 Pro gateways (VPN A and VPN B) have a VPN tunnel between them. They are both connected to two ISPs each (VPN A to ISP A1 and ISP A2 and VPN B to ISP B1 and ISP B2). For VPN-1 A, ISP A1 takes precedence over ISP A2, however, when connectivity to the ISP A1 s router breaks, it will failover to work with ISP A2. Similarly, VPN-1 B will prefer to work with ISP B1 and will failover to ISP B2 upon connectivity failure. Using Link Selection, all the possible links will be probed and of all the links that are up, the one with the highest preference will be chosen. FIGURE 1 Multiple ISPs In this scenario: Gateways A and B are connected to the Internet through two different ISPs: ISP A1 and ISP A2 connect VPN-1 A to the Internet. ISP B1 and ISP B2 connect VPN-1 B to the Internet. Purpose 1) For each VPN-1 Pro gateway, to allow full redundancy between the ISPs. 2) Designate one ISP as the primary to be used when both ISPs are available. 3) To minimize network impact upon failover from one ISP to another. This includes avoiding the need to apply configuration changes in order to switch from one ISP to another. Configuration check list 1) Define the two Gateway objects and a VPN community. 2) Configure the interfaces of each VPN-1 Pro gateway. 3) Configure the Link Selection page on both VPN-1 Pro gateways NGX (R60) Link Selection VPN Deployments. Last Update August 30,

8 Configuration Scenarios Multiple ISPs (Link Selection) 4) Install the policy. 5) Configure the routing table on each gateway. How to configure The configuration for gateways A and B are the same. 1) Use Check Point s NGX R60 SmartDashboard to configure the following objects: a. A Check Point gateway object for each of the two gateways (VPN A and VPN B) i. The OS should be either SecurePlatform, SecurePlatform Pro, Linux or IPSO ii. It should be possible to manage each gateway by a separate SmartCenter. b. A site-to-site Meshed community that contains the two gateway objects. 2) On each of the gateway objects, under the topology tab, configure the relevant interfaces. You can do this by automatically fetching the topology. a. VPN-1 A should include and as its interfaces. 3) On each VPN-1 Pro gateway object configure the Link Selection page (under VPN > Link Selection): a. Under IP Selection by remote peer check Use a probing method and select Using ongoing probing. b. Enter the Configure window and select the Probe the following addresses. The interfaces associated with each ISP should be added to the IP address list. c. Select the Primary address checkbox and choose the IP address associated with the preferred ISP (choose for VPN A). Click OK. d. Under the Outgoing Route Selection section, select the Route based probing option. 4) Install the Policy. 5) On each VPN-1 Pro gateway configure the routing table so that each of the interfaces associated with the ISPs will be configured with the correct nexthop gateway and the correct metric. On VPN A: a. route add default gateway metric 0 b. route add default gateway metric 100 Kernel IP routing table: NGX (R60) Link Selection VPN Deployments. Last Update August 30,

9 Configuration Scenarios Dialup backup (Link Selection) Summary All possible links (based on the routing table) will be probed all the time. In particular, VPN A will probe the following links: through ISP A1 to ISP B1; through ISP A1 to ISP B2; through ISP A2 to ISP B1 and through ISP A2 to ISP B2.The link that is identified as up and is configured to have the best metric is chosen. When all the links are available, VPN A will choose the link from ISP A1 to ISP B1 because all the routes through here have a higher priority metric and it knows that ISP B1 on VPN B is the primary address. When the previously chosen link fails to respond, the mechanism will move to the next best alive link. There is only one VPN tunnel between the two VPN gateways, this provides a seamless failover between links (no IKE renegotiation takes place upon failover). Note - When ISP Redundancy is enabled, specific routes are required to be configured in step 5 to both peer addresses with different metric, instead of adding the default routes. A specific route is required for each peer gateway. More than one default route is not supported by ISP Redundancy. Dialup backup (Link Selection) FIGURE 1 In this scenario: Gateways A and B are connected to the Internet through two different ISPs. ISP A1 and ISP A2 connect VPN-1 A to the Internet. ISP A1 is a regular connection, whereas the connection to ISP A2 is through an expensive ISDN line. ISP B connects VPN-1 B to the Internet. Purpose 1) Allow full redundancy between the ISPs. 2) To minimize network impact upon failover from one ISP to another. This includes avoiding the need to apply configuration changes in order to switch from one ISP to another. NGX (R60) Link Selection VPN Deployments. Last Update August 30,

10 Configuration Scenarios Dialup backup (Link Selection) Configuration check list 1) Define the two gateway objects and the VPN community. 2) Configure the interfaces of each VPN-1 Pro gateway. 3) Configure the Link Selection page on both VPN-1 Pro gateways. 4) Turn on the On demand option using dbedit. 5) Install the policy. 6) Configure the routing table on each gateway. How to configure 1) Use Check Point s NGX (R60) SmartDashboard to configure the following objects: a. A Check Point gateway object for each of the two gateways (VPN A and VPN B) i. The OS should be either SecurePlatform, SecurePlatform Pro, Linux or IPSO. ii. It should be possible to manage each gateway using a separate SmartCenter server. b. A site-to-site Meshed community that contains the two gateway objects. 2) On each of the gateway objects, in the Topology tab, configure the relevant interfaces. You can do this by automatically fetching the topology. a. VPN A should include and as its interfaces. 3) On VPN A s gateway object configure the Link Selection page (select VPN > Link Selection): a. Under IP Selection by remote peer check Use a probing method and select Using ongoing probing. b. Enter the Configure window and select Probe the following addresses. The interfaces associated with each ISP should be added to the IP address list. c. Select the Primary address and choose the IP address associated with the preferred ISP (choose ). Click OK. d. Under the Outgoing Route Selection select the Route based probing option. 4) On VPN B s gateway object configure the Link Selection page (select VPN > Link Selection): a. Under IP Selection by remote peer check Always use this IP Address. Choose Selected address from topology table and select the IP address of the interface connected to ISP B. 5) Using dbedit, turn the use_on_demands_links global flag to true. In addition, set the on_demand_metric_min global property to the minimum metric value from which the interface should be probed on demand; (in our example it will be set to 100). NGX (R60) Link Selection VPN Deployments. Last Update August 30,

11 Configuration Scenarios Dialup backup (Link Selection) 6) Install the Policy. 7) Configure the routing table on VPN A, so that each of the interfaces associated with the ISPs will be configured with the correct nexthop gateway and the correct metric. a. route add default gateway metric 0 b. route add default gateway metric 110 Kernel IP routing table: Summary All possible links with metrics lower than the minimum configured threshold (based on the routing table information) are probed all the time (In this case there s one such link). The link that is identified as up and is configured to have the best metric is chosen. When the previously chosen link fails to respond, the mechanism will move to the next best alive link (again, in this example there s only one such link). When all links with a metric lower than the threshold fail, the high metric links will be probed only once, to make sure they are available. In addition, the on-demand initial script, if configured, is run. Once one of the low metric links goes back up, the traffic will failover from the expensive link to the cheaper one. In addition, the on-demand shutdown script is run to shut down the link. There is only one VPN tunnel between the two VPN gateways, regardless of the links being used. This provides a seamless failover between links (no IKE renegotiation takes place upon failover). NGX (R60) Link Selection VPN Deployments. Last Update August 30,

Configuring and Using Dynamic DNS in SmartCenter

Configuring and Using Dynamic DNS in SmartCenter This document describes how to configure and use Dynamic DNS for Check Point Embedded NGX gateways, using Check Point SmartCenter R60 and above, with or