Basic Site to Site VPN Configuration
Configuring a Meshed Community Between Internally Managed Gateways
To configure an internally managed VPN meshed community:
- Install and configure the Security Gateways as described in the R80.30 Installation and Upgrade Guide.
- In SmartConsole, double click on the Security Gateway object.
- In the General Properties page:
- Enter the gateway Name.
- Enter the IPv4 Address and IPv6 Address.
- In the Network Security tab, Select IPsec VPN.
- Click Communication and establish trusted communication with the Gateway.
- In the Network Management page, click Get Interfaces.
- After the interfaces show in the table, click Edit to open the Interface window.
- In the Interface window, define the general properties of the interface and the topology of the network behind it.
- In the Network Management > VPN Domain page, define the VPN domain one of:
The network Security Gateway objects are now configured, and need to be added to a VPN community.
Note - There is nothing to configure on the IPsec VPN page, regarding certificates, because internally managed Security Gateways automatically receive a certificate from the internal CA.
- Open the Object Explorer (Ctrl+E), and select VPN Communities.
- Click New > VPN Communities > Meshed Community.
The New Meshed Community window opens.
- In the Encrypted Traffic page, select Accept all encrypted traffic if you need all traffic between the Security Gateways to be encrypted. If not, then create applicable rules in the Security Policy Rule Base that allows encrypted traffic between community members (step 7).
- On the Gateways page, add the Security Gateways created in Step 1.
A VPN tunnel is now configured.
For information on other options, such as Encryption, Shared Secret, and Advanced, see: IPsec & IKE
- If you did not select Accept all encrypted traffic in the Encrypted Traffic page of the Community, build an access control policy.
For example:
Source
|
Destination
|
VPN
|
Service
|
Action
|
* Any
|
* Any
|
Meshed VPN Community
|
* Any
|
Accept
|
Where "Meshed VPN Community" is the VPN community you just defined.
Configuring a Star Community Between Internally Managed Gateways
A star VPN community is configured in much the same way as a meshed community, the difference being the options on the Star Community window:
- On the VPN Routing page - Select To center only.
- On the Gateways page:
- Central Gateways - Add the central Security Gateways.
- Central Gateways - Select Mesh central Security Gateways if you want the central Security Gateways to communicate.
- Satellite Gateways - Add the satellite Security Gateways.
Configuring a VPN with External Security Gateways Using Certificates
Configuring a VPN with external Security Gateways (those managed by a different Security Management Server) is more involved than configuring a VPN with internal Security Gateways (managed by the same Security Management Server). This is because:
- Configuration is performed separately in two distinct systems.
- All details must be agreed and coordinated between the administrators. Details such as the IP address or the VPN domain topology cannot be detected automatically but have to be supplied manually by the administrator of the peer VPN Security Gateways.
- The gateways are likely to use different Certificate Authorities (CAs). Even if the peer VPN Security Gateways use the Internal CA (ICA), it is still a different CA.
There are various scenarios when dealing with externally managed Security Gateways. The following description tries to address typical cases and assumes that the peers work with certificates. If this is not the case refer to Configuring a VPN with External Security Gateways Using a Pre-Shared Secret.
Note - Configuring a VPN with PKI and certificates is more secure than with pre-shared secrets.
To configure VPN using certificates, with the external Security Gateways as satellites in a star VPN Community:
- Obtain the certificate of the CA that issued the certificate for the peer VPN Security Gateways, from the peer administrator.
If the peer Security Gateway uses the ICA, then to obtain the CA certificate file, connect web browser to this portal:
http://<IP address of peer Security Gateway or Management Server
>:18264
- In SmartConsole, define the CA object for the CA that issued the certificate for the peer.
- Define the CA that will issue certificates for your side if the Certificate issued by ICA is not applicable for the required VPN tunnel.
You may have to export the CA certificate and supply it on the peer administrator.
- Define the Network Object(s) of the Security Gateway(s) that are internally managed. In particular, be sure to do the following:
- If the ICA certificate is not applicable for this VPN tunnel, then in the IPsec VPN page, generate a certificate from the applicable CA.
- Define the Network Object(s) of the externally managed Security Gateway(s).
- If it is not a Check Point Security Gateway, define an Interoperable Device:
In Object Explorer, click New > Network Object > More > Interoperable Device.
- If it is a Check Point Security Gateway, define an Externally Managed VPN Gateway:
In Object Explorer, click New > Network Object > Gateways and Servers > More > Externally Managed VPN Gateway.
- Set the various attributes of the peer Security Gateway.
In particular, be sure to do the following:
- For an Externally Managed Check Point Security Gateway:
In the General Properties page of the Security Gateway object, select IPsec VPN.
- Define the Topology.
- Define the VPN Domain with the VPN Domain information obtained from the peer administrator. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
- For an Externally Managed Check Point Security Gateway:
In the IPsec VPN page, define the Matching Criteria. Specify that the peer must present a certificate signed by its own CA. If feasible, enforce details that appear in the certificate as well.
- Define the Community.
These details assume that a Star Community is used, but you can also use a Meshed Community. If you are working with a Meshed community, ignore the difference between the Central Security Gateways and the Satellite Security Gateways.
- Agree with the peer administrator about the various IKE properties and set them in the Encryption page and the Advanced page of the community object.
- Define the Central Security Gateways. These are usually the internally managed ones. If no other Community is defined for them, decide whether or not to mesh the central Security Gateways. If they are already in a Community, do not mesh the central Security Gateways.
- Define the Satellite Security Gateways. These are usually the external ones.
- Click OK and publish the changes.
- Define the applicable Access Control rules.
- Add the Community in the VPN column, the services in the Service & Applications column, the desired Action, and the applicable Track option.
- Install the Access Control Policy.
Configuring a VPN with External Security Gateways Using Pre-Shared Secret
Configuring VPN with external Security Gateways (those managed by a different Security Management Server is more involved than configuring VPN with internal Security Gateways (managed by the same Security Management Server) because:
- Configuration is done separately in two distinct systems.
- All details must be agreed and coordinated between the administrators. Details such as the IP address or the VPN domain topology cannot be detected automatically but have to be supplied manually by the administrator of the peer VPN Security Gateways.
There are various scenarios when dealing with externally managed Security Gateways. The following description tries to address typical cases but assumes that the peers work with pre-shared secrets. If this is not the case refer to Configuring a VPN with External Security Gateways Using PKI.
Note - Configuring a VPN with PKI and certificates is considered more secure than with pre-shared secrets.
To configure a VPN using pre-shared secrets, with the external Security Gateways as satellites in a star VPN Community:
- Define the Network Object(s) of the Security Gateways that are internally managed. In particular, be sure to:
- In the General Properties page of the Security Gateway object, in the Network Security tab, select IPsec VPN.
- In the Network Management page, define the Topology.
- In the Network Management > VPN Domain page, define the VPN Domain. If it does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
- Define the Network Object(s) of the externally managed Security Gateway(s).
- If it is not a Check Point Security Gateway, define an Interoperable Device:
In Object Explorer click New > Network Object > More > Interoperable Device.
- If it is a Check Point Security Gateway, define an Externally Managed VPN Gateway:
In Object Explorer, click New > Network Object > Gateways and Servers > More > Externally Managed VPN Gateway.
- Set the various attributes of the peer Security Gateway. In particular, make sure to configure:
- In the Topology page, define the Topology and the VPN Domain with the VPN Domain information obtained from the peer administrator.
- If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
- Define the Community.
The following details assume that a Star Community was chosen, but a Meshed Community is an option as well. If you are working with a Mesh community, ignore the difference between the Central Security Gateways and the Satellite Security Gateways.
- Agree with the peer administrator about the various IKE properties and set them in the Encryption page and the Advanced page of the community object.
- Define the Central Security Gateways. These will usually be the internally managed ones. If there is no another Community defined for them, decide whether or not to mesh the central Security Gateways. If they are already in a Community, do not mesh the central Security Gateways.
- Define the Satellite Security Gateways. These will usually be the external ones.
- Publish the changes.
- Agree on a pre-shared secret with the administrator of the external Community members. Then, in the Shared Secret page of the community, select Use only Shared Secret for all external members. For each external peer, enter the pre-shared secret.
- Define the applicable Access Control rules in the Access Control Policy. Add the Community in the VPN column, the services in the Services & Applications column, the desired Action, and the applicable Track option.
- Install the Access Control Policy.
Firewall Control Connections in VPN Communities
Check Point Nodes communicate with other Check Point Nodes by means of control connections. For example, a control connection is used when the Security Policy is installed from the Security Management Server to a Security Gateway. Also, logs are sent from Security Gateways to the Security Management Server across control connections. Control connections use Secure Internal Communication (SIC).
Implied Rules in the Access Control Rule Base allow the Control connections. The management Server adds and removed the Implied Rules in the Access Control Rule Base when you select or clearing options in the Firewall page of the SmartConsole Global Properties.
Some administrators prefer not to rely on implied rules, and instead prefer to define explicit rules in the Access Control Rule Base. Check Point does not support replacing implied rules with explicit rules. See sk43401: How to completely disable FireWall Implied Rules.
Why Turning off Firewall Implied Rules Blocks 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 define explicit rules in place of the implied rules, you may still not be able to install the policy:
The administrator wishes to configure a VPN between Security Gateways A and B by configuring SmartConsole. To do this, the administrator must install a Policy from the Security Management Server to the Security Gateways.
- The Security Management Server successfully installs the Policy on Security Gateway A. As far as gateway A is concerned, Security Gateways A and B now belong to the same VPN Community. However, B does not yet have this Policy.
- The Security Management Server tries to open a connection to Security Gateway B in order to install the Policy.
- Security Gateway A allows the connection because of the explicit rules allowing the control connections, and starts IKE negotiation with Security Gateway B to build a VPN tunnel for the control connection.
- Security Gateway B does not know how to negotiate with A because it does not yet have the Policy. Therefore Policy installation on Security Gateway B fails.
The solution for this is to 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, you must make sure that control connections are not changed by the Security Gateways. To do this, 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 nevertheless encrypted and authenticated with Secure Internal Communication (SIC).
Discovering Which Services are Used for Control Connections
- In SmartConsole, click Menu > Global properties.
- On the Firewall page, make sure to select Control Connections.
- Click OK.
- In SmartConsole, from the left navigation panel, click Security Policies.
- Select the applicable Access Control Policy.
- From the toolbar above the policy, select Actions > Implied Rules.
The Implied Policy window opens.
- 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 VPN configuration, as described throughout this 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.