How to set up a Site-to-Site VPN with a 3rd-party remote gateway

Solution ID	sk53980
Product	IPSec VPN
Version	All
Platform / Model	All
Date Created	13-Sep-2010
Last Modified	06-Aug-2017

Introduction

This document describes how to set up a VPN connection between a Check Point gateway and a 3rd party Interoperable Device.

There are 3 main sections:

1. New VPN Check Point Gateway configuration.
2. Interoperable Device and VPN community configuration.
3. Required Firewall Rule Base definition.
   

Table of Contents

• Configuring Check Point Security Gateway with VPN
• Configuring the Interoperable Device and VPN community
• Defining VPN encryption domain for Interoperable Device
• Creating a rule for the traffic
• Completing the procedure
• Troubleshooting
• Related solutions and documentation

Configuring Check Point Security Gateway with VPN

Note: If you have a fresh installed Check Point Gateway that is also defined as Security Management server and should be used as a VPN Gateway, start from step 6.
In most cases this Gateway has the  icon and is named "gw-<number>".

To create Check Point Security Gateway:

1. In the Network Object right-click on Check Point and Security Gateway/Management.
   
   
   
2. Click Wizard Mode
   
   
   
3. Enter
   
   1. Gateway name
   2. Gateway platform
   3. IPv4 address
      
      
   
   
4. Click Next and enter the one-time password as defined on Check Point Security Gateway during installation.
   
   
   
5. Click Next after trusted communication established, then click Finish.
   
   
   
6. In the General Properties window of your Security Gateway, make sure the 'IPSec VPN' checkbox is selected.
   
   
   
7. Define VPN encryption domain for your Gateway. Make sure that you have at least one internal and one external interfaces. VPN encryption domain will be defined to all networks behind internal interface.
   
   
   
8. Click Accept
   
   
   
9. Click OK and close the Gateway dialog
   
   

Configuring the Interoperable Device and VPN community

Create an object to represent the peer gateway.

1. Right-click the white space of Network Objects and select: New -> Others -> Interoperable Device
   
   
   
   
2. Give the gateway a name, IP address, and (optional) description in the properties dialog window that is displayed and click OK.
   
   
   
3. In the SmartDashboard IPSec VPN tab, right-click in the open area on the top panel and select: New -> Meshed Community.
   
   
   
4. A Meshed Community Properties dialog pops up.
   In the General menu, enter your VPN community name:
   
   
   
5. In the Participating Gateways menu click: Add, select your both gateways objects, and click OK.
   
   
   
6. In the Encryption menu, you can change the Phase 1 and Phase 2 properties.
   You can also define which IKE version should be used. For IKEv1 leave the default, for IKEv2 select IKEv2 only.
   
   Note: Make a note of the values you select in order to set the peer to match them.
   
   
   
7. In the Tunnel Management menu you can define how to setup the tunnel.Note: The recommended tunnel sharing method is one VPN tunnel per subnet pair (default).
   This shares your network on either side of the VPN and makes the Phase 2 negotiation smooth. It also requires fewer tunnels to be built for the VPN.
   If you need to restrict access over the VPN, you can do that later through your security Rule Base.
8. For preshered authentication, expand the Advanced Settings menu and select: Shared Secret.
   Select the 'Use only Shared Secret for all External members' checkbox.
   Select your peer gateway from the entries in the list below and click Edit to edit the shared secret.Note: remember this secret, as your peer will need it to set up the VPN on the other end.
   
   
   
   
9. Expand the Advanced Settings menu and select: Advanced VPN Properties. Here, you can modify the more advanced settings regarding Phase 1 and 2.Note: Keep note of the values used. It is also a good idea to select:
   Disable NAT inside the VPN community so you can access resources behind your peer gateway using their real IP addresses, and vice versa.
10. Click OK on the VPN community properties dialog to exit back to the SmartDashboard.
    You may see the following message:
    
    
    
11. We are about to address the VPN domain setup in the next section, so click Yes to continue.
    Now you can see your VPN community defined:
    
    
    

Defining VPN encryption domain for Interoperable Device

You now need to define your VPN encryption domains.
If you have not already done so, create network objects to represent your local networks and the peer networks they will be sharing with you.

To define VPN encryption domains:

1. From the Network Objects menu, right click on Networks and select Network to define a new network. In the following image, we are creating a network to represent our peer's internal network that they will be sharing with Check Point VPN gateway:
   
   
   
2. If you or your peer is sharing more than one network over the tunnel, create groups to represent each side's VPN domain. From the Network Objects menu, right click on Groups, select Groups and then Simple Group...In this example, only one network is shared, so the group will have only one object included, but you can put as many networks in this group as you want to share.
   
   Note: it is important not to add groups within a group as this can impact performance. Make sure the group is "flat".
   
   Give your group a meaningful name such as: Local_VPN_Domain.
   Click OK once you have added all of your local networks and then repeat the procedure to create a group to represent your peer's shared networks.
3. Open the properties for the peer gateway and select the group/network that represents its VPN domain:
   
   
   
4. Click OK to complete the peer gateway configuration.

Creating a rule for the traffic

Now, you have both objects set up for VPN and you have defined your community. All that is left is to create a rule for the traffic.

Here is where you should restrict access if it is required.

To create a rule for the traffic:

1. To allow VPN traffic, you should add the relevant rules to your Firewall Rule Base.
   Navigate Rule Base, Firewall -> Policy
   
   
   
2. Decide where in your rule base you need to add your VPN access rule and right click the number on the rule just above where you want it and select: Add Rule -> Below.
   
3. You should explicitly set the VPN community in the VPN column on your rule, you have created before.
   In the VPN column, right-click the Any Traffic icon and select: Edit Cell....
   
   
   
   Select the: Only connections encrypted in specific VPN Communities option button and click Add.
   Select the VPN community created in the above steps and click OK and then OK again.
   
   
   
4. In this example, we are allowing any service/any host across the tunnel in both directions. Your rule should now show the VPN community in the VPN column:
   
   
   
   

Completing the procedure

1. Install the policy to your local Check Point gateway.
   
2. Once the remote side has setup their VPN to match, verify that you have secure communication with their site.

Troubleshooting

1. Problem: Traffic is dropped by 3rd party gateway and main IP configuration was defined to internal IP address for Check Point Gateway.
   
   Generally, it is recommended to define main gateway IP address with external IP (in Check Point Gateway – General Properties). In some cases, for example: StandAlone gateway, administrator wants to define main IP address as internal IP in order to allow managing from internal network.
   
   In this case, VPN link selection should be changed.
   Open Check Point gateway properties dialog, select IPSec VPN -> Link Selection and click Source IP address settings...
   In opened dialog, select Selected address from topology table and select relevant external IP address, used by remote peer
   
   
   
   
2. Problem: IKE keys were created successfully, but there is no IPsec traffic (relevant for IKEv2 only).
   
   In some cases, remote peer chooses NAT-T encapsulation but Check Point gateway sends traffic without this encapsulation. As a result, a remote peer drops the IPsec traffic since it expecting NAT-T.
   
   There are two workarounds available to resolve this problem:
   
   1. If IKEv2 is required by remote peer, NAT-T should be disabled.
      
      To do so, open Check Point gateway properties dialog, select IPSec VPN -> VPN Advanced and clear 'Support NAT traversal (applies to Remote Access and Site to Site connections)' checkbox:
      
      
      
      Note: This solution is not suitable for gateways participating in the Remote Access community.
      
   2. If IKEv2 is not required, in the SmartDashboard, go to Community -> Encryption and change configuration to IKEv1.
   
   

Related solutions and documentation

• sk16452 - Information on IPSec Interoperability between Check Point VPN-1 and third party VPN vendors. (3rd parties)
• sk108600 - VPN Site-to-Site with 3rd party
• sk36968 - S2S VPN between Check Point Security gateway and Cisco DAIP

Site to Site Tunnel Status Monitoring

In R80.10 SmartConsole - Click on Log and Monitor then Click on New Tab  then go to External App  Tunnel and User Monitoring at the bottom as shown below

R80.10 IPS Protections in Detect

With R80.10, the new default profile "Optimized" sets all newly downloaded IPS protections to be in state "detect (staging)" or "inactive".

1. We start with the general page. It has settings in which a protection should be in detect, prevent, or inactive.

2. Then, in the "updates" page, we see that newly downloaded protections are automatically set to "Detect". This means that:

1. If a newly downloaded protection was supposed to be in "prevent", it will be set as "detect (staging)".
2. If a newly downloaded protection was supposed to be in "detect", it will be set as "detect (staging)".
3. If a newly downloaded protection was supposed to be in "inactive", it will remain inactive.

 

3. Sometimes an IPS update issues an update to an existing protection. In this case, the updated protection is back to "newly downloaded protection" state, which leaves it as either in "detect (staging)" or "inactive".

It is important to remember these things, because it requires you to manage your staging protections - otherwise they will not be in Prevent mode.

You can do that either from:

1. IPS Protections page with the filter for "Staging" status

 

2. Logs that appear in the query page for "IPS --> Staging"

You can also automate some of this work:

1. Apply additional configuration which excludes some protections from the "Detect (Staging)" status, leaving them with Prevent or Detect or Inactive.

 

2. Automatically change protections to Inactive based on tags.

3. Using the show threat-protections and set threat-protection API commands, you can create an automatic reaction which automatically changes the action from "Detect (Staging)" to "Prevent" or "Inactive" based on custom decision factors.

set threat-protection name "Aggressive Aging" overrides.remove.1 "New profile 1" overrides.remove.2 "New Profile 2"

Keeping threats from impacting your organization doesn’t have to be challenging! Join Threat Prevention Expert Nick McKerral to learn how to implement Threat Prevention Best Practices using Check Point Infinity:

• Learn how to activate the IPS, AB, AV blades in R80.10
• Learn how to activate and utilize Threat Emulation and Extraction to protect web and email
• Learn all about Check Point’s new inline threat extraction capabilities
• Learn about Sandblast Agent with browser based Threat Emulation, Extraction, Anti-phishing, domain credential protection capabilities, and more!

Watch the recording: TechTalk: Advanced Threat Prevention Best Practices Video 

Answers to questions we did not get to during the session will be summarized and answered below.

R80.10 - Tutorial

Tutorial: Creating Host Objects with the R80 Management API

Management API Reference

R80.10 Best Practices – Migrating from R77.30

R80.10 Unified Access Control policy

The CPView Utility

Configure Checkpoint Identity Awareness

Configuring CheckPoint Identity Awareness

Identity Awareness allows you to enforce access based on user and computer identity. It integrates with both Active Directory and non Active Directory networks and will authenticate employees and guests. When integrated with Active Directory the connection is clientless and authentication is transparent to the user.

There are five “identity sources” which Identity Awareness can use to acquire identities:-

• AD Query
• Browser-Based Authentication
• Endpoint Identity Agent
• Terminal Servers Identity Agent
• Remote Access

This post describes the basics of how to configure Identity Awareness, integrate with Active Directory (AD Query method) and configure a rule to require authentication for accessing the internet.

Configuring Identity Awareness

Open the properties of the CheckPoint gateway

Tick the “Identity Awareness” software blade

Select the correct gateway that will be used to identify users

Select the “AD Query” method for acquiring identity

Select an Active Directory, entering Domain Administrator credentials when prompted, click Connect to establish a connection

Once the connection between the gateway and Active Directory has been establish go to the “Users and Administrators” tab in SmartDashboard

Right click “Access Roles” and click “New Access Roles”

Name the new “Access Role” appropriately eg “Allowed_Internet_Access”

Specify “Networks” if you wish to allow access from

Click the “Users” tab

Click “Specific users/groups”, click the green + button and browse to the location of the user or group

Click the “Machines” tab, click the green + button and specify the machines or group of machines you wish to allow access from

Click OK to finish configuration of the new “Access Role”

Either create a new firewall rule or modify an existing rule to specify the source of the new “Access Role”

Before…

After…

When a user who is a member of the AD group “Allowed Internet Access” is logged on to the computer “XP” from the internal subnet defined as “Net_Internal” they will be allowed access

However the same user accessing the internet from a machine not specified in the access rule will be dropped.

When the user attempts to make the connection and not all conditions are met, the connection will be dropped and NO warning or error message will be displayed. The captive portal webpage could be enabled to prompt the users for a username and password or even explain why they are not allowed access.

In testing in my lab I have found out that a connection which meets network, user and computer conditions will be allowed access, but when the user is logged off and another user logs on who is NOT a member of the correct group allowing internet access they are allowed access. I believe this is because the gateway still assumes the connection is still from the same user/computer source so is therefore access is allowed. In most scenarios this would not matter if the same user used the same computer, I can imagine in schools where users share computers this would be an issue. Further investigation required…..

Configure Checkpoint Application Control

Configuring Check Point Application Control

Check Point Application Control software blade allows firewall administrators to identify traffic and allow/block based on type of application, time and bandwidth etc. When used with the Identity Awareness software blade users and groups access to sites can be controlled by the security policy. In this post I am using Check Point R75.46 running Gaia on an open server and will run through the basics of setting up Application Control to block Social Network sites and allow all other traffic.

Configuring Application Control

Login to the SmartDashboard

Click on the firewall object and enable “Application Control” by ticking the box. Click OK

Click the “Application & URL Filtering” tab

Click “Policy”

Add a new rule called “Block social network sites”

Define source as “Any” and destination “Internet”

Add “Application/Sites”, a window will appear, search for “Social Networking” category. You can either select the entire category or specify certain sites you wish to block

The selected site(s) will appear in the bottom left hand window. Click Ok once happy

Select the “Action” as “Block” and display “Blocked Message”

Create another rule BELOW the “Block social network sites” and allow “Any Recognized” sites

Testing

On a client machine, open your internet browser

Browse to Facebook or Linkedin or Myspace or another social networking site. You should be presented with a “Page Blocked” webpage.

If required, the block screen message is fully customisable, to do this go to the “UserCheck” tab and edit

Open SmartView Tracker and select “Application and URL Filtering” security blade, you will be able to identify the sites and categories of the websites allowed or denied.

Integration with Identity Awareness

Refer to a previous blog post on how to configure Identity Awareness here

Once IA is configured and you have defined groups linked to Active Directory, you can modify the policy to create rules to allow/block sites based on group membership.

Troubleshooting

During testing I noticed the database was not up to date, this was confirmed on the “Overview” screen in the “Message and Action Items” on the right side of the screen. The error “Application database update failed on 1 Security Gateway” indicated the Firewall was unable to

“Application Control: Update failed. Could not reach ‘secureupdates.checkpoint.com’. Check DNS and Proxy configuration on the gateway.”

As the error states check DNS, simple fix just ensure the gateway itself is configured with DNS servers that can resolve external websites. This can be configured either using the WebGUI or CLI

Using Gaia the commands are:-

LABFW1> set dns primary ipv4 –address X.X.X.X

LABFW1> set dns secondary ipv4-address X.X.X.X

From the WebGUI

After a while the Application Control database should automatically update itself.