Configuring VPN Sites

In the VPN > Site to Site VPN Sites page you can configure remote VPN sites. For more on how to configure site to site VPN, go to VPN > Site to Site Blade Control.

When you add a new VPN site, these are the tabs where you configure these details:

  • Remote Site - Name, connection type, authentication method (preshared secret or certificate), and the Remote Site Encryption Domain.

  • Encryption - Change the default settings for encryption and authentication details.

  • Advanced - Enable permanent tunnels, disable NAT for this site, configure encryption method, and additional certificate matching.

To add a new VPN site:

  1. Click New.

    The New VPN Site window opens in the Remote Site tab.

  2. Enter the Site name.

  3. Select the Connection type:

    • Host name or IP address - Enter the IP address or Host name.

      If you select IP address, and it is necessary to configure a static NAT IP address, select Behind static NAT and enter the IP address.

      Note - Behind static NAT applies to IPv4 addresses only.

    • High Availability or Load Sharing - Configure a list of backup IP addresses in case of failure (High Availability) or to distribute data (Load Sharing). The appliance uses probing to monitor the remote site's IP addresses. In High Availability, you can configure one of the IP addresses as the primary.

      When you select this option, you must configure a probing method on the Advanced tab. The probing method monitors which IP addresses to use for VPN: ongoing or one at a time.

      Click New to add an IP address and set a Primary IP address if necessary for High Availability.

    • Only remote site initiates VPN - Connections can only be initiated from the remote site to this appliance. For example, when the remote site is hidden behind a NAT device. In this scenario, this appliance only responds to the tunnel initiation requests. This requires a secure method of remote site authentication and identification.

  4. Select an authentication method. This must match the authentication you used to configure this appliance as the other gateway's remote site.

    • Preshared secret - If you select this option, enter the same password as configured in the remote gateway and confirm it.

      Note - You cannot use these characters in a password or shared secret: { } [ ] ` ~ | ‘ " \ Maximum number of characters: 255

    • Certificate - The gateway uses its own certificate to authenticate itself. For more information, see VPN > Internal Certificate.

  5. Select the Remote Site Encryption Domain. Configure the conditions to encrypt traffic and send to this remote site.

    • Define remote network topology manually - Traffic is encrypted when the destination is included in the list of network objects. Click Select to select the networks that represent the remote site's internal networks. Click New to create network objects.

    • Route all traffic through this site - All traffic is encrypted and sent to this remote site. You cannot configure more than one remote site.

    • Encrypt according to routing table - If you use dynamic routing, encrypts traffic based on source or service and destination. You must create a virtual tunnel interface (VTI) in the Device > Local Network page and associate it with this remote site. You can then use this VTI to create routing rules. Traffic that matches these routing rules is encrypted and routed to the remote site.

    • Hidden behind external IP of the remote gateway - If the remote site is behind NAT and traffic is initiated from behind the remote site to this gateway. When you select this option, it is not necessary to define an encryption domain.

  6. Exclude networks - Select this option to exclude networks from the specified encryption domain. This may be useful if two gateways are in the same community and protect the same parts of the network.

  7. Click Apply.

In the Encryption tab you can change the default settings.

There are built in encryption settings' groups that only need to match in this configuration and in the remote site.

  • Default (most compatible)

  • VPN A - According to RFC 4308.

  • VPN B - According to RFC 4308.

  • Suite-B GCM-128 or Suite-B-GCM-256 - According to RFC 6379.

  • Custom - Select this option to decide (manually) which encryption method is used (optional).

In the Advanced tab:

Note - When you finish the new VPN site configuration, click Apply.

  • Settings

    • Select to configure if the remote site is a Check Point Security Gateway. To enable permanent VPN tunnels, Select the checkbox.

    • Select to disable NAT for this site. The original IP addresses are used even if hide NAT is defined.

  • Encryption method

    Select the IKE version:

    IKE Version

    Notes

    IKEv1

    • The modes for IKE negotiation are Main Mode and Aggressive Mode.

      For IKE negotiation, the Main Mode uses six packets, and the Aggressive Mode uses three packets.

      We recommend you use the Main Mode, which is more secure.

      By default, Enable aggressive mode is not selected and the Main Mode is used.

      Enable the Aggressive Mode only if necessary, and the other side of the VPN tunnel does not support the Main Mode. (Third party gateways primarily do not work in the Main Mode.)

      The Aggressive Mode is used to create a tunnel and one of the gateways is behind NAT. In this case, a pre-shared secret does not provide enough data for authentication in the Main Mode. Authentication must be done using a certificate and a gateway (peer) ID, or a secondary identifier couple that is available in the Aggressive Mode. The secondary identifier method is also available in IKEv2.

    • If you select Enable aggressive mode for IKEv1:

      • Use Diffie-Hellman group - Determines the strength of the shared DH key used in IKE phase 1 to exchange keys for IKE phase 2. A group with more bits ensures a stronger key but lower performance.

      • Initiate VPN tunnel using this gateway's identifier - When this gateway's IP address is dynamic and the authentication method is the certificate and the peer ID, you must enter the Gateway ID. For Type, select domain name or user name.

    IKEv2

    When you create a tunnel and one of the gateways is behind NAT without a certificate (uses a pre-shared secret), with IKEv2 protocol you can use a secondary identifier couple to allow authentication.

    In this case, the pre-shared secret is not enough.

    If you select Create IKEv2 VPN tunnel using these identifiers, configure these settings:

    • Peer ID - Enter the identifier.

    • Gateway ID - Select Use global identifier or Override global identifier (enter the new identifier).

    Prefer IKEv2, support IKEv1

    Configure the fields as explained for the first two options.

    • Additional Certificate Matching (does not apply when you use a pre-shared secret):

      When you select certificate matching in the Remote Site tab, you first need to add the CA that signed the remote site's certificate in the VPN > Certificates Trusted CAs page.

      In the Advanced tab, you can select to match the certificate to Any Trusted CA or an Internal CA.

      You can also configure more matching criteria on the certificate.

    • Probing Method

      This section is shown only when you select High Availability or Load Sharing for the connection type in the Remote Site tab.

      When the remote site has multiple IP addresses for VPN traffic, the correct address for VPN is discovered through one of these probing methods:

      • Ongoing probing - When a session is initiated, all possible destination IP addresses continuously receive RDP packets until one of them responds. Connections go through the first IP to respond (or to a primary IP if a primary IP is configured and active for High Availability), and stay with this IP until the IP stops responding. The RDP probing is activated when a connection is opened and continues a background process.

      • One time probing - When a session is initiated, all possible destination IP addresses receive an RDP session to test the route. The first IP to respond is chosen, and stays chosen until the VPN configuration changes.

Notes:

  • For more information on installing the certificate, see Managing Installed Certificates.

  • The initiator's gateway ID must be set in the responder gateway as the peer ID.

  • The Remote Access blade must be enabled for peer ID to work.

  • On the gateway that is not behind NAT, for Connection type, select Only remote site initiates VPN.

  • When you configure the remote site, do not select behind static NAT.

An initial tunnel test begins with the remote site. If you have not yet configured it, click Skip. The VPN site is added to the table.

Locally managed gateways can be part of these site to site communities:

  • VPN mesh community – All gateways are connected to each other, and each gateway handles its own internet traffic. Encrypted traffic is passed from networks in the encryption domain of one gateway to the networks in the encryption domain of the second gateway.

  • VPN star community – One gateway is the center and routes all traffic (encrypted and internet traffic of the remote peer) to the internet and back to the remote peer. The peer gateway is a satellite and is configured to route all its traffic through the center.

To configure a gateway as the center:

  1. Select the VPN site from the list.

  2. Click Edit.

    The Edit VPN Site window opens.

  3. In the Remote Site tab:

    • For Connection type, enter the IP address which is the public IP of the remote peer (satellite gateway).

    • In the Encryption domain, select the networks of the satellite gateway that will participate in the VPN.

  4. In the Advanced tab, select Allow traffic to the internet from remote site through this gateway.

  5. Click Apply.

    This gateway is now designated as the center. Hide NAT is done automatically in the center gateway.

To configure a gateway as a satellite:

  1. Select the VPN site from the list.

  2. Click Edit.

    The Edit VPN Site window opens.

  3. In the Remote Site tab:

    • For Connection type, enter the IP address which is the public IP of the remote peer (center gateway).

    • In the Encryption domain, select Route all traffic through this site.

  4. Click Apply.

    This gateway is now designated as a satellite.

You can configure more than one satellite gateway to route all traffic through the center gateway.

If you try to configure two gateways to be the center, an error message shows.

If you do not configure one gateway as a center, the site to site VPN acts like a mesh community and each gateway continues to handle its own traffic.

To run a tunnel test with a remote site:

Check Point uses a proprietary protocol to test if VPN tunnels are active. It supports any site-to-site VPN configuration.

Tunnel testing requires two Security Gateways and uses UDP port 18234. Check Point tunnel testing protocol does not support 3rd party Security Gateways.

  1. Select an existing site from the list.

  2. Click Test.

To edit a VPN site:

  1. Select the VPN site from the list.

  2. Click Edit.

  3. Make the relevant changes and click Apply.

To delete a VPN site:

  1. Select the VPN site from the list.

  2. Click Delete.

  3. Click OK in the confirmation message.

To disable or enable the VPN site:

  1. Select the VPN site from the list.

  2. Click Disable or Enable.

 

VPN Community Use Cases

Q1: A system administrator is responsible for 6 gateways and wants to share network resources between the satellite branches. Which type of VPN community is preferable?

A1: A star VPN community is preferable as every gateway does not have to create a VPN tunnel with all of the others. Instead, the 5 satellite peer gateways will each create one site to site star VPN community to the center gateway. Only the star gateway (center) must create a site to site from itself to each of the remote peers.

Q2: A center gateway handles all the traffic in the VPN community. When the gateway reboots, all the other gateways' internet traffic is affected, and they lose access to the remote peer encryption domain until the center gateway comes back up. How can the administrator avoid this downtime?

A2: In this case, a mesh community is better as each gateway can handle its own internet traffic and is not affected by any other gateway.