Configuring Advanced Site to Site Settings

In the VPN > Site to Site Advanced page you can configure global advanced options that define how the appliance connects to remote sites.

The configuration options on this page answer these configuration questions:

Configuring a Local Encryption Domain

In domain-based VPN, traffic is encrypted when it originates in one Encryption Domain and is transmitted to a different domain.

The local Encryption Domain defines:

  • The internal networks that encrypted traffic from remote sites and networks can get access.

  • That traffic from the Encryption Domain to remote sites is encrypted.

By default, the local encryption domain is determined automatically be the appliance. Networks behind LAN interfaces and trusted wireless networks are part of the local Encryption Domain. Optionally, you can manually create a local Encryption Domain if necessary.

To configure a local Encryption Domain manually:

  1. Click the link defined automatically according to topology.

  2. Select Define local network topology manually.

  3. Click Select to show the full list of available networks and select the applicable checkboxes.

  4. Click New if the existing list does not contain the necessary networks required.

    For information on how to create a new network object, see the Users & Objects > Network Objects page.

  5. Click Apply.

The Site to Site Local Encryption Domain window opens and shows the services you selected.

Configuring the Appliance Interfaces

Link Selection is used to:

  • Specify which interface is used for incoming and outgoing VPN traffic.

  • Determine the best possible path for the traffic.

In addition, with the Link Selection mechanisms, the administrator can select which source IP addresses are used for VPN traffic.

The default configuration to select an outgoing interface and source IP address is for the device to determine them automatically. Alternatively, you can change the default settings and select other means to determine:

  • The appliance's outgoing interface

  • The appliance's source IP address

To configure the appliance's outgoing interfaces and source IP address for VPN:

  1. In the Link Selection > Outgoing interface selection section, select a method to specify the outgoing interface:

    • According to the routing table – The OS's routing table finds the interface link with the lowest metric (highest priority) through which to send traffic based on the remote site's IP addresses.

    • Route based probing – This method also consults the routing table for the link with the lowest metric. But, before choosing an interface link to send traffic, all routing possibilities are examined. This is to make sure that the link is active. The gateway selects the best match (highest prefix length) active route with the lowest metric (highest priority). This method is recommended when there is more than one external interface.

  2. In the Source IP address selection section, select an option to configure the source IP address used by the Security GatewayClosed A dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources., when it initiates or responds to VPN traffic. This IP address is normally used by the remote sites to connect to this Security Gateway:

    • Automatically chosen according to outgoing interface.

    • Manually configured – Enter an IP address that is always used as the source IP address of a VPN tunnel.

Configuring the IKE ID Type for the IKEv2 Main Mode (MM) Negotiation with 3rd-party VPN Peers

Note - In the R81.10.X releases, this feature is available starting from the R81.10.10 version.

The purpose of the IKEv2 ID Type exchanged during the IKEv2 Main Mode (MM) negotiation (Packet 5 and Packet 6) is to provide an ID, based on which the remote peer searches for the local peer in its database.

The ID Type is not necessary for IKEv2 Main Mode (MM) negotiation between Check Point Security Gateways. However, it is necessary for most 3rd-party VPN gateways. It is important to make sure both sides authenticate using the same ID Type and ID values.

Quantum Spark Spark gateways can configure IKEv2 ID Type to one of these:

  • An FQDN (this is the default).

  • An IP address (determined dynamically, based on the OS routing) - in R81.10.10 and higher.

To see the current configuration:

  1. Connect to the command line on the Quantum Spark appliance.

  2. Log in.

  3. If your default shell is Gaia ClishClosed The default shell of the Gaia CLI, then go to the Expert mode:

    expert

  4. Examine the value of the Registry parameter:

    ckp_regedit -p SOFTWARE\\CheckPoint\\VPN1 | grep BestRoutingSenderIP

    Explanation:

    • If the output shows the value "False", then the Quantum Spark gateway configures IKEv2 ID Type to an FQDN

    • If the output shows the value "True", then the Quantum Spark gateway configures IKEv2 ID Type to its IP address

To configure IKEv2 ID Type to an FQDN:

Important - Schedule a maintenance window.

  1. Connect to the command line on the Quantum Spark appliance.

  2. Log in.

  3. If your default shell is Gaia Clish, then go to the Expert mode:

    expert

  4. Configure the required value for the Registry parameter:

    ckp_regedit -a SOFTWARE/CheckPoint/VPN1 BestRoutingSenderIP False

  5. Examine the value of the Registry parameter:

    ckp_regedit -p SOFTWARE\\CheckPoint\\VPN1 | grep BestRoutingSenderIP

  6. Restart all Check Point services (this interrupts all traffic):

    cpstop ; cpstart

To configure IKEv2 ID Type to an IP address based on the OS routing:

Important - Schedule a maintenance window.

  1. Connect to the command line on the Quantum Spark appliance.

  2. Log in.

  3. If your default shell is Gaia Clish, then go to the Expert mode:

    expert

  4. Configure the required value for the Registry parameter:

    ckp_regedit -a SOFTWARE/CheckPoint/VPN1 BestRoutingSenderIP True

  5. Examine the value of the Registry parameter:

    ckp_regedit -p SOFTWARE\\CheckPoint\\VPN1 | grep BestRoutingSenderIP

  6. Restart all Check Point services (this interrupts all traffic):

    cpstop ; cpstart

Tunnel Health Monitoring

Dead Peer Detection (DPD) is an additional keepalive mechanism supported by the Check Point Security Gateway to test if VPN tunnels are active. DPD uses IPsec traffic to minimize the number of messages required to confirm the availability of a peer and requires an IPsec established tunnel. The DPD mechanism is based on IKE encryption keys only.

The feature also allows you to monitor permanent tunnels based on DPD for both IKEv1 and IKEv2.

In active mode, a peer that is configured as DPD receives DPD Hello requests at regular intervals if there is no incoming IPSec traffic for 10 seconds.

To test if a VPN tunnel is active:

Select a Tunnel health monitoring method

  • Tunnel test (Check Point Proprietary) – Works only between Check Point gateways.

  • DPD (Dead Peer Detection)

In DPD responder mode, the Check Point gateway sends the IKEv1 Vendor ID to peers from which the DPD Vendor ID was received and answers incoming DPD packets.

To enable DPD responder mode:

Select the checkbox.