Support Center > Search Results > SecureKnowledge Details
How to set up VPN between on-premises Security Gateway and two Check Point Security Gateways in AWS Technical Level
Solution

The following article explains how to set up a VPN between an on-premises Check Point Security Gateway and two Check Point Security Gateways in Amazon Web Services (AWS) Virtual Private Cloud (VPC). This article is relevant for R77.30 only.

The two Security Gateways in VPC are deployed in two Availability Zones (AZs), thus providing redundancy even if one of the Security Gateways goes down or an entire AZ becomes unavailable.

Consider the following environment consisting of:

  • An on-premises network (172.16.0.0/16) protected by an on-premises Check Point Security Gateway.

  • A VPC consisting of 2 subnets (internal-subnet-1 and internal-subnet-2) each in a separate AZ (AZ1 and AZ2, respectively)

VPN connectivity is required between the on-premises network and each internal subnet in the VPC. To provide redundancy, two Check Point Security Gateways are deployed, one in each AZ.

When both Security Gateways in the VPC are operative, it is required that each Gateway encrypts the traffic of the AZ, in which it resides. When one of the Security Gateways is down, the other Security Gateway takes over and encrypts the traffic for the entire VPC.


With reference to the above diagram, we will be setting up the following resources using the following example values.

Resource Example
on-premises network 172.16.0.0/16
AWS region e.g. us-east-1
VPC 10.0.0.0/16 in us-east-1
AZ1 us-east-1a
AZ2 us-east-1b
external-subnet-1 10.0.0.0/24
internal-subnet-1 10.0.2.0/24
external-subnet-2 10.0.1.0/24
internal-subnet-2 10.0.3.0/24
GW 1 external address 10.0.0.10
GW 1 internal address 10.0.2.10
GW 2 external address 10.0.1.10
GW 2 internal address 10.0.3.10
public route table 10.0.0.0/16 local
0.0.0.0/0 internet-gateway
route table 1 (RT1) 10.0.0.0/16 local
172.16.0.0/16 10.0.2.10
route table 2 (RT2) 10.0.0.0/16 local
172.16.0.0/16 10.0.3.10


Prerequisites

It is assumed that the reader is familiar with general AWS concepts and services such as:

  • EC2 (Elastic Compute Cloud)
  • VPC (Virtual Private Cloud)
  • IAM (Identity and Access Management)
  • Cloud Formation

It is also assumed that the reader is familiar with:

  • Check Point VPN in general and in particular the Multiple Entry Point (MEP) feature
  • The Check Point Security Gateway product offering for AWS.

More information on MEP can be found in the VPN Administration Guide

 

Method of operation

We will use the Check Point VPN Multiple Entry Point feature. With MEP, the on-premises Gateway will:

  • Set up permanent VPN tunnels with both gateways.
  • Monitor the status of the 2 Gateways in VPC
  • When both gateways are up
    • Traffic going to AZ1, will be sent through GW 1
    • Traffic going to AZ2, will be sent through GW 2
  • If GW 1 is unavailable all traffic to the VPC would be sent through GW 2
  • If GW 2 is unavailable all traffic to the VPC would be sent through GW 1


In addition, a script running on the on-premises gateway will automatically modify the routing in the VPC so that traffic to the on-premises network is sent through the best available gateway as described in the table below.

VPC Internal subnets routing table associate:

State internal-subnet-1association internal-subnet-2 association
GW 1 up, GW 2 up RT-1 RT-2
GW 1 up, GW 2 down RT-1 RT-1
GW 1 down, GW 2 up RT-2 RT-2
GW 1 down, GW 2 down RT-1 RT-2


Procedure

Table of Contents

  • I - Basic VPC setup
  • II - VPN configuration
  • III - Install and set up the tunnel monitoring script

 

I - Basic VPC setup

Notes:

  • The steps in this section will only be briefly described as it is assumed the reader is already familiar with them.
  • You can completely automated the steps described in this section by using this Cloud Formation template

    Download template Direct Launch in CloudFormation Console

 

  1. Create a VPC
  2. Create an Internet Gateway (IGW)
  3. Associate the VPC and the IGW
  4. Create a public route table with a default route pointing to the IGW.
  5. In each AZ:
    • Create an external subnet
    • Create an internal subnet
  6. Associate the 2 external subnets with the public routing table
  7. In each AZ, launch a Check Point gateway with:
    • An interface on the public subnet
    • An interface on the internal subnet
  8. Connect to each gateway and complete the first time wizard
  9. Create a routing table (RT-1):
    • Add to RT-1 a route entry that routes all traffic to the on-premises network through the internal interface of GW 1 - this can be a 0.0.0.0/0 (default) route or just a route to the on-premises network.
    • Associate internal-subnet-1 with RT-1
  10. Create a routing table (RT-2):
    • Add to RT-2 a route entry that routes all traffic to the on-premises network through the internal interface of GW 2 - this can be a 0.0.0.0/0 (default) route or just a route to the on-premises network.
    • Associate internal-subnet-1 with RT-2


II - VPN configuration

  1. Open SmartDashboard

  2. Create a group to represent the internal subnet in AZ1:



  3. Create a network object to represent the internal subnets in AZ2:



  4. Create a group object to represent both internal subnets:



  5. Create a Gateway object for each Gateway in your VPC:



    Notes:
    • In the IPv4 Address field, enter the EIP associated with the gateway
    • Enable the IPSec VPN blade


  6. In the Topology tab:



    Notes:
    • The VPN domain should be set to internal_g1 (the internal subnet behind the Gateway)
    • The topology of the internal interface is set to internal_nets (which consists of all internal VPC subnets). This is in order to avoid anti-spoofing errors when a failover occurs.


  7. Repeat the steps above to create a gateway object for GW 2:





  8. Create a VPN star community object:





  9. Add GW1 and GW2 as the Center Gateways:



  10. Add the peer gateway as a Satellite Gateway:



    Note: mgmt in our case is the peer gateway

  11. Under Tunnel Management:

    • In permanent Tunnels, select "Set Permanent Tunnels" checkbox and "On all tunnels in the community"
    • In VPN Tunnel Sharing, select "One VPN tunnel per subnet pair"



  12. Under MEP, select "Select the closest gateway to destination (by VPN domain)" option:



  13. Install the policy on all 3 gateways.



III - Install and set up the tunnel monitoring script

  1. Download the tunnel-monitor.shar script, copy it to the on-premises Gateway.

    Note: Following AWS move to its own certificate authority (CA), the on-premises Gateways are unable to complete AWS API calls, causing the failover not to function. The tunnel-monitor.shar was updated to solve that issue. Existing customers should reinstall the new package for the environment to function properly.

  2. Connect to the on-premises Gateway with SSH and enter Expert mode.

  3. From the Expert mode, run:

       [Expert:]# chmod +x ./tunnel-monitor.shar
       [Expert:]# ./tunnel-monitor.shar
       [Expert:]# rm ./tunnel-monitor.shar


  4. Edit the monitor script configuration file $FWDIR/scripts/tunnel-monitor/conf.json:
     
    {
        "interval": 5,
        "loglevel": "info",
        "logfile": "/var/log/tunnel-monitor.log",
        "vpcs": [
            {
                "cred-file": "credentials.txt",
                "region": "us-east-1",
                "vpc": "vpc-863acce2",
                "gateways": [
                    {
                        "name": "gw1",
                        "address": "198.51.100.10",
                        "subnets": ["subnet-97e1b3ce"],
                        "rtb": "rtb-567fa732"
                    },
                    {
                        "name": "gw2",
                        "address": "203.0.113.20",
                        "subnets": ["subnet-28b35915"],
                        "rtb": "rtb-577fa733"
                    }
                ]
            }
        ]
    }
    
        

    Where:

    Attribute Valid values Comment
    interval Integer >= 5 Frequency in which the script operates
    loglevel String, 'none', 'info', 'debug' Log level
    logfile Path Path to the scripts log file
    vpcs See the table below See the table below


    For each VPC you want to monitor:

    Attribute Valid values Comment
    cred-file A path to a file containing AWS credentials or the literal string "IAM" See Credentials section below
    region AWS region  
    vpc AWS vpc  
    gateways See the table below See the table below

    Where gateways is a list of 2 Gateway objects each with the following attributes:

    Attribute Value values Comment
    name String The Gateway's name
    address IPv4 address The main IP address of the Gateway object
    subnets An array of VPC subnets The internal subnets in the gatewayÂ’s AZ
    rtb A VPC routing table The routing table that points to the Gateway's internal interface

    Credentials:

    The on-premises Gateway requires AWS credentials in order to obtain the current routes inside the VPC and to change subnet to route table associations.
    The credentials should have permission to perform the following API calls:

    • DescribeRouteTables
    • AssociateRouteTable
    • ReplaceRouteTableAssociation


    An appropriate IAM policy:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeRouteTables",
                    "ec2:AssociateRouteTable",
                    "ec2:ReplaceRouteTableAssociation"
                ],
                "Resource": [
                    "*"
                ]
            }
        ]
    }
      
        

    You can supply these credentials to the on-premises Gateway in 2 ways:

    1. Using IAM role
    2. Using a credential file

    IAM role:

    You can only use this option if the on-premises Gateway is also running in AWS. In this case, you could assign that Gateway an IAM role that is associated with the IAM policy above. If you chose to use this option specify "IAM" as the value next to the "cred-file" attribute.


    Credential file:

    Use this option if the on-premises Gateway is not running in AWS or an IAM role cannot be assigned to it.
    The credential file should contain an AWS AccessKeyId and AWSSecretKey in the following format:

    AWSSecretKey=ABCDabcd1234ABCDabcd1234ABCDabcd12345678
    AWSAccessKeyId=ABCDEFGHIJKLMNOP2222

    A template credential file can be found in $FWDIR/scripts/tunnel-monitor/credentials.txt

    To start the monitoring script, either reboot or run: $FWDIR/scripts/tunnel-monitor/monitor.sh

    Notes:

    • The script will automatically run whenever the on-premises gateway starts through /etc/rc.local
    • If you make changes to the configuration file, run the $FWDIR/scripts/tunnel-monitor/monitor.sh script to pick up the changes in configuration.


Validate your setup

  1. Open SmartView Monitor, select Tunnels on Community view, select the Community you create:

  2. When both Gateways are up, you should get:



  3. Send encrypted traffic over the VPN connection to an instance in AZ2.

  4. Verify that you see a log originating from GW 2 indicating that the traffic was carried over the VPN tunnel between the on-premises Gateway and GW 2:



  5. Shut down GW 2.

  6. In a few seconds, verify that SmartView Monitor should report that the tunnel with it is down:



  7. Verify that internal-subnet-2 is now associated with RT1.

  8. In SmartViewTracker, verify you see a log similar to:


     

    If you try to send traffic to the internal subnets in AZ2, you will receive a log from GW 1 similar to this:

  9. Start up GW 2.

  10. Confirm in SmartView Tracker that after the Gateway has started, VPN traffic to AZ2 now goes through GW 2:



FAQ

Show All

Troubleshooting

In case you are having issues:

  1. Confirm that the on-premises Gateway can make API calls to AWS:

    • Run the following command on the on-premises Gateway and confirm it does not output an error:

      curl_cli --cacert /opt/CPshrd-R77/conf/ca-bundle.crt https://ec2.us-east-1.amazonaws.com

    • Check the DNS settings

    • Make sure its Security Policy allows it to make outgoing https and http connections (http is used to retrieve an updated CRL)


  2. Consult the monitoring script log file /var/log/tunnel-monitor.log

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment