Basic Site to Site VPN Configuration

It is more complex to configure VPN with external Security Gateways (those managed by a different Security Management ServerClosed Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server.) than to configure VPN with internal Security Gateways (managed by the same Security Management ServerClosed Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server.) because:

  • There are two systems to configure separately.

  • Administrators of the peer VPN Security Gateways must coordinate with each other and agree on all details. The administrators must manually supply details such as the IP address and the VPN domain topology. These details cannot be detected automatically.

Configuring a Star or Meshed Community Between Internally Managed Security Gateways

See VPN Communities.

Configuring a VPN with External Security Gateways Using Certificates

This section applies to typical configurations of a VPN with External Security Gateways, and assumes that the peers work with certificates. If this is not the case, see Configuring a VPN with External Security Gateways Using Pre-Shared Secret.

To configure a VPN with an externally managed peer, you and the peer administrator must choose the same Certificate Authority (CA) for communication between the two peers.

Even if each of the peer VPN Security Gateways uses a Check Point Internal CA (ICAClosed Internal Certificate Authority. A component on Check Point Management Server that issues certificates for authentication.), if they are not managed by the same Security Management Server then their ICAs are different.

Example - A Check Point Security Gateway located at a headquarters office and a peer Check Point Security Gateway located at a branch office are managed separately. Each peer Security Gateway uses a different Check Point ICA and has different parameters for encryption. The administrators of the two networks must agree on a CA for communication between the two peers.

Note - Configuring a VPN with PKI and certificates is more secure than with pre-shared secrets.

Configuring a VPN with External Security Gateways Using Pre-Shared Secret

Administrators of the peer VPN Security Gateways must coordinate with each other and agree on all details. The administrators must manually supply details such as the IP address and the VPN domain topology. These details cannot be detected automatically.

There are many possible scenarios for VPN with external Security Gateways. The next procedure is meant for typical cases and assumes that the peers work with pre-shared secrets. If the peers do not work with pre-shared secrets, see Configuring a VPN with External Security Gateways Using Certificates".

Note - It is more secure to configure a VPN with public key infrastructure (PKI) and certificates than with pre-shared secrets.

Firewall Control Connections in VPN Communities

Check Point Nodes communicate with other Check Point Nodes through control connections. For example a Security Management Server and a Security Gateway use a control connection when the Security Policy is installed from the Security Management Server to the Security Gateway. In addition, Security Gateways send logs to the Security Management Server across control connections. Control connections use Secure Internal Communication (SICClosed Secure Internal Communication. The Check Point proprietary mechanism with which Check Point computers that run Check Point software authenticate each other over SSL, for secure communication. This authentication is based on the certificates issued by the ICA on a Check Point Management Server.).

Implied Rules in the Access Control Rule BaseClosed All rules configured in a given Security Policy. Synonym: Rulebase. allow the Control connections. The Management Server adds and removes the Implied Rules in the Access Control RuleClosed Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. Base when you select or clear options in the SmartConsole > Menu > Global properties > Firewall page.

Some administrators do not rely on implied rules, and instead define explicit rules in the Access Control Rule Base. Check Point does not support replacing implied rules with explicit rules. See sk43401.

Why Turning off Implied Rules Blocks Firewall Control Connections

If you turn off implicit rules, you may not be able to install an Access Control Policy on a remote Security Gateway. Even if you configure explicit rules rather than implied rules, you may still not be able to install the policy:

To configure a VPN between Security Gateways A and B through SmartConsole, the administrator must install a Policy from the Security Management Server to the Security Gateways.

  1. The Security Management Server successfully installs the Policy on Security Gateway A. Security Gateway A recognizes that Security Gateways A and B now belong to the same VPN Community. However, Security Gateway B does not yet have the Policy.

  2. The Security Management Server opens a connection to Security Gateway B to install the Policy.

  3. Security Gateway A allows the connection because of the explicit rules that allow the control connections. Security Gateway A starts IKE negotiation with Security Gateway B to build a VPN tunnel for the control connection.

  4. Security Gateway B cannot negotiate with Security Gateway A because it does not yet have the Policy. Therefore, Policy installation on Security Gateway B fails.

Make sure that control connections do not have to pass through a VPN tunnel.

Allowing Firewall Control Connections Inside a VPN

If you turn off implied rules, make sure that control connections are not changed by the Security Gateways. Add the services that are used for control connections to the Excluded Services page of the Community object. See sk42815 for details.

Note - Although control connections between the Security Management Server and the Security Gateway are not encrypted by the community, they are still encrypted and authenticated with Secure Internal Communication (SIC).

Discovering Which Services are Used for Control Connections

  1. In SmartConsole, click Menu > Global properties.

  2. On the Firewall page, select Control Connections.

  3. Click OK.

  4. In SmartConsole, from the left panel, click Security Policies.

  5. Select the applicable Access Control Policy.

  6. From the toolbar above the policy, select Actions > Implied Rules.

    The Implied Policy window opens.

  7. Examine the Access Control Rule Base to see what Implied Rules are visible. Note the services used in the Implied Rules.

Simplified and Traditional Modes

By default, VPN configuration works with Simplified mode. Simplified mode uses VPN Communities for Site to Site VPNClosed An encrypted tunnel between two or more Security Gateways. Synonym: Site-to-Site VPN. Contractions: S2S VPN, S-to-S VPN. configuration, as described in this Administration Guide.

Traditional mode is a different, legacy way to configure Site to Site VPN where one of the actions available in the Security Policy Rule Base is Encrypt. When Encrypt is selected, all traffic between the Security Gateways is encrypted. For details about Traditional Mode, see the R77 versions VPN Administration Guide.

In a policy package, all layers must use the same VPN mode.