Support Center > Search Results > SecureKnowledge Details
CloudGuard for AWS - Transit VPC Architecture
Solution

Table of Contents

  1. Overview
  2. Solution Components
  3. Deploying Check Point Security Management Server
  4. Creating the Transit VPC
    1. Configure AWS
    2. Deploy CloudGuard Gateways for AWS
    3. Configure VPN Tunnel Interface on the on-premises Security Gateway
    4. Configure VPN Tunnel in Check Point SmartConsole
    5. Configure BGP on CloudGuard Gateway for AWS
  5. Connecting Transit VPC to Spoke VPCs
    1. Configure AWS
    2. Configure connection between Spoke VPC to Transit VPC
    3. Configure Gaia OS on CloudGuard Gateways for AWS
    4. Configure VPN in Check Point SmartConsole
  6. Configuring Remote Access VPN to the Transit VPC
  7. Troubleshooting
  8. Related Documentation
  9. Related Solutions
  10. Revision History

 

Click Here to Show the Entire Article

The article below provides manual deployment instructions for the Transit VPC architecture.
The Security Transit VPC automated solution is now available.

It is strongly recommended to use the Transit VPC for AWS Deployment Guide.

(1) Overview

The Amazon Global Transit Network is used to perform transitive routing between spoke networks through a central hub. Use this document to deploy a hub-and-spoke network topology that routes all traffic through a network transit center, a Transit VPC.

The Transit VPC simplifies network management and minimizes the number of connections needed to connect multiple Amazon VPCs and remote networks. You can create as many virtual networks as necessary and design different options for connecting the networks to each other.

Use Check Point CloudGuard together with the Transit VPC. CloudGuard delivers comprehensive security for cloud workloads and assets with VPC perimeter security services, seamless security segmentation between VPCs, and automatically established IPsec VPN connectivity between cloud environments. The solution automatically connects spoke VPCs to a central security hub VPC for seamless security inspection, VPN and NAT services.

CloudGuard integrates simply with AWS. Once the Security Management Server and security hub are deployed, every new or existing VPC that is specifically tagged is automatically configured to route all traffic. The traffic is routed via an AWS managed VPN gateway into the security hub. The VPN gateways are also added as IPsec interoperable devices. The gateways are added to the automatically established route-based VPN process, (powered by Border Gateway Protocol (BGP)), to propagate network route changes to on-premises and in cloud tenants.

The solution provides the Check Point award winning Threat Prevention suite in a transit architecture. It offers industry leading Firewall (per NSS and Gartner), IPS, HTTPS Inspection, Anti-Bot and Anti-Virus, and Zero-day protection engines. These Threat Prevention features safeguard published applications, Internet-bound traffic, and inbound access to cloud assets with complete security visibility and event analysis.

The Transit VPC architecture is recommended for several common security use cases.

Hybrid cloud

With a hybrid cloud setup, you can connect your on-premises and cloud environments, and cloud assets can have secured access to on-premises assets. The connection is established via a secured VPN connection between your Check Point Security Appliance and a CloudGuard Gateway for AWS. You can also implement a secure connection with AWS Direct Connect tunnels. For example, a front-end server in the cloud can connect to an on-premises backend database to retrieve confidential data or business logic. (see Diagram 1 below).

Diagram 1: Centralized Cloud Perimeter with Direct Connect to On-Premises

A Hybrid Cloud setup enables cloud assets to have secured access to on-premises assets. For example, a front-end server in the cloud can connect to an on-premises backend database to retrieve confidential data or business logic.

In some cases a spoke VPC needs a direct internet access that does not traverse via the VPN connection (for example if the spoke hosts a public facing application with high throughput). In such cases, it is recommended to deploy an additional DMZ/Northbound Transit VPC that is connected by VPC peering to the relevant spokes.
Please note that due to the fact that VPC peering is only possible within a region, an additional DMZ/Northbound Transit VPC must be deployed per region.

Diagram 2: Transit VPC with DMZ spokes


Cloud Perimeter

The Transit VPC, as a cloud perimeter, provides Threat Prevention and Access Control to the spoke VPCs. Each VPC can be deployed in multiple Availability Zones and provide security services to multiple spoke VPCs in the environment.

Only the center VPC has access to the Internet and the spokes are limited to private subnets. All traffic to and from the spoke VPCs, is steered via the center VPC and security controls are concentrated in a single central VPC.

Transparent Proxy

The transparent proxy provides secured proxy services to the spoke VPCs. It is transparent in that the security proxy services are seamless and do not require topological changes to the protected spoke VPCs. With this solution, you do not need a CloudGuard Gateway for AWS in each of the spoke VPCs. The solution relies on VPN connections to the center (hub) VPC for Internet-bound connections.

DevOps and application owners can use the transparent proxy to deploy solutions in designated VPCs, rely on AWS native security controls only, and have advanced Threat Prevention, Next Generation Firewall, and compliance, seamlessly from the center VPC. (see Diagram 1 above).

Important note on automatic failover:

To ensure automatic failover in case of CloudGuard Gateway for AWS failure or complete AZ failure, the recommended architecture described in this document relies on BGP dynamic routing protocol established between the AWS VPN gateways, CloudGuard Gateways for AWSs in the Transit VPC and the on-premises Security Gateway (if Hybrid Cloud is required). In case of such failure within the Transit VPC, the converged components use BGP to detect the failure and update routing tables automatically to recover connectivity. This process may take some time (between a few seconds to a few minutes) depending on BGP configurations and region.
Simplification of on-premises connectivity to Transit VPC by using Domain based VPN:

The solution below discusses connecting the on-premises with the Transit gateway using route based VPN and VTIs.

If it is preferred to use domain based VPN configuration, skip the on-premises configuration below and use Transit VPC architecture for customers using domain-based VPN configuration instead.

This article covers the manual configurations and procedures for deploying the solution.

 

(2) Solution Components

Show / Hide this section

Transit VPC deployment consist of 3 primary segments (internal components may vary based on the exact use case required, specifically, if an on-premises connection is required for Hybrid Cloud, and in case Direct Connect service is used):

  1. Check Point Security Management Server deployment - the management server is responsible for managing the CloudGuard Gateways for AWS, providing centralized policy control, logging, threat analysis, updates and more essential functions. The management server can be deployed on-premises or in the cloud, in a dedicated VPC or inside the Transit VPC. The deployment and configuration of Check Point management server is described in Section 3.

  2. On-premises IPsec tunnels to AWS Transit VPC - static or dynamic routing based VPN connections to an unattached VPN Gateway (required for using Direct Connect) or to VPC attached VPN Gateway (for non-Direct Connect setup). This setup requires the creation of a star community as the Hybrid Cloud infrastructure. The configuration of IPsec tunnels between on-premises Security Gateway and AWS VPN gateway is described in Section 4.

  3. Transit VPC IPsec tunnels to satellite (spoke) VPCs - static or dynamic routing based VPN connections between Check Point CloudGuard Gateways for AWS and VPN Gateways, or CloudGuard Gateways for AWS in Spoke VPCs. This setup requires the creation of a second star community as the Transit solution infrastructure. The configuration of IPsec tunnels between CloudGuard Gateways for AWS on the Transit VPC and AWS VPN gateway / CloudGuard Gateway for AWS in the spoke VPCs is described in Section 5.

Diagram 3: VPN Communities



The design patterns described in this document do not include VPC Peering and rely on standard VPN connections to allow flexibility and cross-region deployment. The design patterns focus on Route Based VPN communities with end to end BGP convergence using VTIs rather than Domain Based VPN to allow flexibility and large-scale deployments. When connecting a single VPC to an on-premises deployment, a Domain-Based VPN that offers simplified configurations may be used.

The following sections describe the deployment of Hybrid Cloud infrastructure with AWS without Direct Connect.
Since the spoke VPCs are added dynamically, we must use dynamic routing protocols as well, which in turn means that we must use route based VPN connections between the transit and spoke VPCs. Additionally, to propagate the Spoke to corporate traffic and vice versa via the Transit VPC we again need to dynamic routing (since the spokes are not directly connected to the corporate network)
Additional use cases and cloud formations for detecting and reacting on the creation of new satellite VPCs will be added to this article in the future.

 

(3) Deploying Check Point Security Management Server

Show / Hide this section

The latest recommended version of Security Management Server / Multi-Domain Security Management Server as of Oct 2017, is Check Point R80.10.
For version R80, make sure you are using R80 image Take 132 or higher.
The Security Management Server / Multi-Domain Security Management Server can be deployed either in AWS, or on-premises.

In order to be able to control the CloudGuard Gateways for AWS:

  • The Management Server must be able to initiate connections to the CloudGuard Security Gateways.
  • The CloudGuard Security Gateways should be able to initiate connections to the Management Server (e.g., for sending logs).

The Management Server can communicate with the CloudGuard Gateways over either private IP addresses or public IP addresses.
Communication over private IP addresses is possible in any one of the following cases:

  • The management is in the same VPC as the CloudGuard Security Gateways.
  • The management is in another VPC that is peered with the VPC, in which the CloudGuard Security Gateways are deployed.
  • The management is in an on-premises network that has connectivity to the VPC over Direct Connect.
  • The management is in an on-premises network that has connectivity to the VPC over a VPN connection.

In all other cases, the Management Server and CloudGuard Gateways  communicate with each other using public IP addresses.

Procedures:

  • Deploying a Management Server in AWS

    Follow the instructions in this section if you plan to deploy your Management Server in AWS.

    Use the following AWS CloudFormation template to deploy the management:

    The template takes the following parameters:

    Parameter Description
    VPC A preexisting VPC, into which to deploy the Management Server.
    External/Internal Subnet A preexisting Subnet in the VPC.
    Installation Type Management or Standalone.
    Instance Type An AWS instance type to use for the Management Server.
    CloudGuard Version R80.10-BYOL or R80.10-PAYG-NGTP.
    KeyName The EC2 Key Pair to allow SSH access to the instance.
    Administrator Address Addresses of allowed SmartConsole, Gaia Portal and SSH clients in CIDR notation.
    Shell (Optional) The administrator shell when logged into the Management Server.
    Password Hash The administrator user password hash (hint, compute the hash using "openssl passwd -1 [PASSWORD]").
    Primary Management Determines if this is the Primary Management Server or not. The default is "true".
    SIC Key Secure Internal Communication (SIC) Activation key. This parameter is only mandatory when deploying a Secondary Management Server.

  • Deploying a Management Server on-premises

    Follow the standard procedure to install a Check Point Management Server on-premises.
    Refer to the relevant R80.10 Documentation:

 

(4) Creating the Transit VPC

Click Here to Show the Entire Section

  • (4-A) Creating the Transit VPC - Configure AWS

    Show / Hide this subsection

    1. Connect to the VPC's Management Console.

    2. Create the VPC:

      Example:

    3. Next, you must create the subnet, which is the actual network block where your EC2 instance resides.

      Note: It is important to recommended to create two subnets in different Availability Zones for the Transit VPC solution.

      Example:


    4. Create the Route Table:

      Example:

      Example:


      Notes:

      • Add default route to the Internet Gateway (IGW).
      • Do not forget to associate the subnet(s) to the routing tables.

  • (4-B) Creating the Transit VPC - Deploy CloudGuard Gateways for AWS

    Show / Hide this subsection

    You can deploy 2 CloudGuard GWs in the Transit VPC using the Check Point CloudFormation templates:

    sk111013 - AWS CloudFormation Templates

     

  • (4-C) Creating the Transit VPC - Configure VPN Tunnel Interface on the on-premises Security Gateway

    Show / Hide this subsection

    Diagram 4: Example VPN Topology 



    Before performing these steps, prepare unique IP addresses to be assigned to the VPN Tunnel interfaces.

    Procedure:

    1. Connect with a web browser to the Gaia Portal of your on-premises Security Gateway.

    2. In the Network Management section, click on the Network Interfaces page.

    3. In the Interfaces section, click on the Add button, and in the drop-down menu click on the VPN Tunnel option (also known as VTI).

    4. Configure the VPN Tunnel interface.

      1. Make sure the box Enable is checked.

      2. In the VPN Tunnel ID field, select any unique value (e.g., 1).

      3. In the Peer field, enter the name of the CloudGuard for AWS Security Gateways deployed in the Transit VPC as it appears in the SmartConsole.

      4. In the VPN Tunnel Type section, select the option Numbered.

        • In the Local Address field, enter a unique IP address.
          Note: This IP address must be on a different subnet than the IP addresses configured on the CloudGuard Gateway itself and can be any unique IP.
          Note: When you configure the other VTI terminus on the CloudGuard for AWS Gateway deployed in the Transit VPC this will match the value of the Remote Address.

        • In the Remote Address field, enter another unique IP address.
          Note: When you configure the other VTI terminus on the CloudGuard for AWS Gateway deployed in the Transit VPC this will match the value of the Local Address.

        Example:


      5. Click OK.

      6. Repeat the steps (4-B) and (4-C) for the VPN tunnel connecting the second CloudGuard for AWS Gateway:

        • In the Peer field, enter the name of the 2nd CloudGuard for AWS Security Gateway deployed in the Transit VPC as it appears in the SmartConsole.

    5. Connect with a web browser to the Gaia Portal of your CloudGuard for AWS Security Gateway.

    6. Repeat steps 2-4 for your CloudGuard for AWS Gateway.
      1. In the Peer field, enter the name of the on-premises Security Gateway as it appears in the SmartConsole
      2. In the Local Address field, enter the value used in the on-premises Remote Address field.
      3. In the Remote Address field, enter the value used in the on-premises Local Address field.

    7. This can alternatively be configured from clish:
      1. For the on-premises Security Gateway:

        add vpn tunnel #1 type numbered local <LOCAL-ADDRESS#1> remote <REMOTE-ADDRESS#1> peer <CloudGuard-A>

        add vpn tunnel #2 type numbered local <LOCAL-ADDRESS#2> remote <REMOTE-ADDRESS#2> peer <CloudGuard-B>

        set interface vpnt#1 state on

        set interface vpnt#2 state on

        save config

      2. For the CloudGuard for AWS Security Gateways:

        add vpn tunnel #1 type numbered local <REMOTE-ADDRESS#> remote <LOCAL-ADDRESS#> peer <ON-PREM>

        set interface vpnt#1 state on

        save config

  • (4-D) Creating the Transit VPC - Configure VPN Tunnel in Check Point SmartConsole

    Show / Hide this subsection

    1. Configure your on-premises Security Gateway object:

      1. Connect with SmartConsole to Security Management Server / Domain Management Server.

      2. Open the object of your on-premises Security Gateway.

      3. Click on the Network Management pane.

      4. Re-fetch the interface configuration.

      5. New Point-to-Point interfaces named vpnt<NUMBER> will be added with their IP addresses.

      6. Click on OK.

    2. Configure your CloudGuard Gateway for AWS object:

      1. Connect with SmartConsole to Security Management Server / Domain Management Server.

      2. Open the object of your CloudGuard Gateway for AWS.

      3. Expand the Network Management section - click on the VPN Domain pane.

      4. Select the option Manually defined:

        1. In the right corner of this field, click on the ellipsis [...]

        2. Click on the New...

        3. Go to the Group menu.

        4. Click on the Simple Group...

          Example:

        5. Enter some unique name and click OK (do not add any objects to this group)

          Example:

        6. In the right corner of this field, click on the ellipsis [...] - select the new empty Group object

          Example:

      5. Click on OK.

      6. Repeat this configuration for the other CloudGuard Gateways for AWS.

    3. Create a new Star VPN community:

      1. On the left Navigation Toolbar, click on the SECURITY POLICIES app.

      2. In the lower Access Tools section, click on the VPN Communities.

      3. At the top, click on the [*] icon - click on the Star Community.

        Example:

      4. Enter the name of this VPN community.

      5. In the left tree, click on the Gateways pane:

        1. In the Center Gateways section, add your on-premises Security Gateway.

        2. In the Satellite Gateways section, add your CloudGuard Gateway for AWS.

        Example:

      6. In the left tree, click on the Encryption pane:

        1. In the Encryption Method section, select the option IKEv1 for IPv4 and IKEv2 for IPv6 only

        2. In the Encryption Suite section, select the option Custom encryption suite and configure the desired encryption settings.

        3. In the More section, check the box use Perfect Forward Secrecy and select Group 2 (1024 bit)

        Example:

      7. In the left tree, click on the Tunnel Management pane:

        1. Check the box Set Permanent Tunnels

        2. Configure the desired settings (e.g., refer to sk113561 - VPN Tunnel to Amazon Web Services (AWS) is unstable)

          Example:


      8. Click OK.

      9. If your Check Point Management Server is hidden behind NAT, you might need to follow
        sk32648 - Site-to-site VPN using certificates issued by the ICA (Internal Certificate Authority) fails with error.

    4. In the Global Properties window under VPN click on Advanced and enable VPN Directional Match in VPN Column


    5. Create an explicit Access Policy rule:

      1. In the upper Access Control section, click on the Policy.

      2. Create an explicit Access Policy rule to allow the required services over the VPN tunnels.

        Example:

        Source Destination VPN Services &
        Applications        		 Action Track Install On Time
        Relevant objects Relevant objects Community→Community
         Community→Internal_clear 
         Internal_clear→Community         		 Relevant Services Accept Log Relevant Security Gateway object Any

    6. Publish the session and install the Access Policy.

    7. Check that VPN Tunnel is established (Phase1 and Phase2).

  • (4-E) Creating the Transit VPC - Configure BGP on the on-premises Security Gateway and on the CloudGuardGateway for AWS

    Show / Hide this subsection

    This section shows how to configure BGP between the on-premise Security Gateway and CloudGuard Gateway for AWS.

    The commands provided below have to be issued in Gaia Clish.

    For details, refer to R80.10 Gaia Advanced Routing Administration Guide and sk95967 - BGP on Gaia OS.

    1. Configure BGP on your on-premises Security Gateway:

      Description and Comments Syntax
      1. Configure the local AS number

      The Border Gateway Protocol (BGP) uses the Autonomous System Number to identify a routing domain that is administered as a unit that presents a unified routing policy to the outside world. You can read more about Autonomous System Number at IANA or APNIC FAQ.      		 set AS <COPORATE_AS_VALUE>
      2. Configure eBGP and the remote AS (The AS that is configured on the CloudGuard for AWS Gateway) set bgp external remote-as <REMOTE_AS_VALUE> on
      3. Define the new BGP peer - CloudGuard Gateway for AWS, based on the tunnel IP addresses that were configured earlier.

      <REMOTE_VTI_IP> is the IPv4 of the BGP peer Enable the specified external BGP peer group. A peer group must be enabled before any peer in the group can be configured. 

      Routing information is exchanged with another BGP router by establishing a peer connection. This peer connection must be configured on both routers. If both peers have the same Autonomous System (AS) number, then the peers must be configured as internal peers. Otherwise, the peers must be configured as external peers. 
      		 set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> on
      4. (Optional) Configure to detect if the BGP peer is down with ping (it can help in case fast recovery is needed).

      Enable or disable ping for this peer using 'on' or 'off'. 
      If ping is enabled and an established BGP peer stops responding to pings, then after a configured number of missed pings (set using 'set bgp ping count #'), the BGP peer will be forced from an established state to reconnect manually.
      Peers with this feature enabled must be able to receive and respond to echo requests, or they will not function correctly. If this feature is disabled for this peer, it will continue to handle BGP connections according to the protocol without any assistance from pings to verify connectivity.      		 set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> ping on

      5. Accept med (metric) attributes recived from external peer.

      		 set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> accept-med on

    2. Configure the route maps for BGP route redistribution and import route filtering on your on-premises Security Gateway:

      NOTE: Incoming BGP routes are not installed into the routing kernel by default. To install incoming routes, a “route map” is needed.

      Description and Comments Syntax
      1. Create a route map to filter inbound routes
      		 set routemap <NAME_IN> id <ID_NUMBER> on
      2. Specify which networks will be matched.

      <REMOTE_NETWORK> is the received network that we want to install into the routing table (this is what the Perimeter advertises.
      		 set routemap <NAME_IN> id <ID_NUMBER> match network <REMOTE_NETWORK> [all | between | exact | off]
      3. Associate the inbound routemap to the BGP peer (which routes are expected to be received from the BGP peer). set bgp external remote-as <REMOTE_AS_VALUE> peer <remote VTI IP> import-routemap <NAME_IN> preference <1- 65535> on
      4. Configure redistribution using a route map (This is what the perimeter advertises) set routemap <NAME_OUT> id <ID_NUMBER> on
      5. Configure matched routing protocol. If this match condition is not specified the default in this case is to export only BGP routes to the BGP protocol. set routemap <NAME_OUT> id <ID_NUMBER> match protocol <PROTOCOL> 
      6. Specify which networks will be matched.

      <LOCAL_NETWORK> is the specific network to advertise into BGP      		 set routemap <NAME_OUT> id <ID_NUMBER>  match network <LOCAL_NETWORK> [all | between | exact | off]
      7. Associate the outbound routemap to the BGP peer
      (which routes are expected to be advertised to the BGP peer).      		 set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> export-routemap <NAME_OUT> preference <1-65535> on

      3. NOTE: Additional fine tuning can be done using routmap commands.

    3. Save the configuration:

      save config

      Verify the BGP neighborship:

      show bgp peers

      Note: The "State" column should show "Established". Any other state means that BGP neighborship is down.

      Example output:

        Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer

PeerID           AS           Routes  ActRts  State             InUpds  OutUpds  Uptime  
    1.1.193.1        65001        2       2       Idle              2       1        00:01:35
    4. Repeat steps (4-E) 1-3 to configure the BGP and routemap for each of your CloudGuard for AWS Security Gateways.

      At the end of this process the output of the 'show bgp peers' command should show the status as Established.

(5) Connecting Transit VPC to Spoke VPCs

Click Here to Show the Entire Section

Background

Show / Hide this subsection

The following procedure is required for connecting spoke VPCs (in Check Point VPN terminology referred to as satellites) to the Transit hub VPC (in Check Point VPN terminology referred to as center).
This procedure configures the AWS VPN gateways as interoperable VPN device in Check Point Security Management Server, establishes the VPN tunnels, and sets the BGP between the center CloudGuard Gateways for AWS and the VPN Gateways in the Spoke VPCs.

The suggested architecture is also valid for Spoke VPCs in different regions. BGP configuration is also required to allow proper convergence of the topology and automatic failover in case of AZ or Gateway failures. To allow BGP convergence on top of IPsec tunnels, VTI must be configured on the Check Point devices. Note this setup does not support load sharing for the same Spoke VPC connection or for communication between spokes. At any given time, only a single CloudGuard Gateway for AWS on the Transit VPC maintains the tunnels between spoke VPCs. This solution does support route based load sharing via BGP configuration.

Diagram 5: Example Topology

Procedure

  • (5-A) Connecting Transit VPC to Spoke VPCs - Configure AWS

    Show / Hide this subsection

    1. Connect to the VPC's Management Console.

    2. Create the Spoke VPC:

      Example:

    3. Next, you must create the subnet, which is the actual network block where your EC2 instance resides..

      Naturally, you can configure multiple subnets for the same VPC.

      Example:

    4. Create the Route Table:

      Example:

      Example:

      Destination Target Status Propagated
      10.0.0.0/16 local Active No

      Notes:

      • Do not forget to associate the subnet(s) to the routing tables.
      • Propagate the routes - it allows your virtual private gateway to automatically propagate routes to the route tables so that you do not need to enter VPN routes into your route tables manually.

    Notes:

    • When defining your route table, make sure to route the relevant traffic via the VGW.

    • Do not forget to associate the subnet(s) to the routing tables.

    • Propagate the routes - it allows your virtual private gateway to automatically propagate routes to the route tables,
      so that you do not need to enter VPN routes into your route tables manually.

  • (5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC

    Show / Hide this subsection

    Configure VPN connection between your Spoke and each of the CloudGuard Gateways for AWS (that serve as the "customer gateways").

    Notes:

    • Important - Creating AWS VPN Connection objects requires the user to define an inside IP address size /30 CIDR for each tunnel.
      While creating a VPN Connection, AWS can automatically generate those CIDRs. However, it is highly recommended to manually set, and also to maintain those private CIDRs.
      This is because AWS does not guarantee that the CIDRs will not collide cross accounts and cross regions.
      If Checkpoint Transit hub Gateways are connected to duplicate IP addresses, it might lead to an unexpected result and it is not supported.
    • In the example below, we will use Spoke-A VPC as the name of the VPC.
    • Repeat these steps for both CloudGuard Gateways in the Transit VPC.

    Procedure:

    1. In the VPC Dashboard, go to the Virtual Private Gateways and create a new Virtual Private Gateway ("Spoke-A-VGW").

      Example:

    2. Attach the Virtual Private Gateway to your VPC (VPC for "SpokeA").

    3. Go to the VPN Connections section and select Create VPN Connection:

      1. In the Virtual Private Gateway field, select the Virtual Private Gateway you created in the previous step.

      2. In the Customer Gateway row, select New.

      3. In the IP Address field, enter the public IP address of the Customer Gateway ("CloudGuard_A").

      4. In the BGP ASN field, enter an ASN, or leave the default value.

      5. In the Routing Options row, select Dynamic (requires BGP).

      6. Under Tunnel Option, make sure to set manual and unique values of IP addresses /30 CIDR ranges for the Inside IP CIDR fields.
        7. Click on Yes, Create button.

      Note: For redundancy, AWS Virtual Private Gateways have two IP addresses and generate two VPN tunnels per gateway.

      Example:

    4. In the VPN Connections, select the newly created VPN connection and click on the Download Configuration:

      1. In the Vendor field, select Generic.

      2. In the Platform field, select Generic.

      3. In the Software field, select Vendor Agnostic.

      4. Click the Yes, Download button.

      Example:

    5. Open the downloaded configuration file and fill the following table.

      These parameters will be used later to configure the CloudGuard Gateway side.

      Example of configuration for Tunnel 1 Example:

      Name Example
      TUN1-IKE-SA-PRE-SHARED-KEY O7X4GgkHgGeeT_.j5CiljBEEF1lXPJ6y
      TUN1-OUTSIDE-VIRTUAL-PRIVATE-GATEWAY 52.21.15.173
      TUN1-OUTSIDE-CUSTOMER-GATEWAY 52.26.75.35
      TUN1-INSIDE-CUSTOMER-GATEWAY 169.254.44.170
      TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY 169.254.44.169

      Example of configuration for Tunnel 2:

      Name Example
      TUN2-IKE-SA-PRE-SHARED-KEY SDFeVGmEedr7_xjTBcawdutE_tTWmetS
      TUN2-OUTSIDE-VIRTUAL-PRIVATE-GATEWAY 52.21.218.247
      TUN2-OUTSIDE-CUSTOMER-GATEWAY 52.26.76.52
      TUN2-INSIDE-CUSTOMER-GATEWAY 169.254.44.182
      TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY 169.254.44.181

      Example of configuration common to both tunnels:

      Name Example
      CUSTOMER-GATEWAY-IP-ADDRESS 198.51.100.10
      CUSTOMER-GATEWAY-ASN 65000
      VIRTUAL-PRIVATE-GATEWAY-ASN 7224
      NEIGHBOR-HOLD-TIME 30
      IPSEC-DPD-INTERVAL 10
      IPSEC-DPD-RETRIES 3
      TCP-MSS-ADJUSTMENT 1387
      TUNNEL-INTERFACE-MTU 1500

  • (5-C) Connecting Transit VPC to Spoke VPCs - Configure Gaia OS on CloudGuard Gateways for AWS

    Show / Hide this subsection

    • (5-C-i) Configure Virtual Tunnel Interface (VTI) and initial BGP

      1. Connect to the command line (over SSH) to your CloudGuard Gateway for AWS.

      2. Log in to the Gaia Clish.

      3. Run the following commands:

        Notes:

        • Replace the variables in the commands surrounded by {} with the values you filled in the tables in the section
          "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC".
        • "AWS_VPC_Tun1" and "AWS_VPC_Tun2" are the names of the interoperable devices in SmartConsole
          (make sure they match when you create the VTI, or when you create the peer's gateway in SmartConsole).
        • The numbers #1 and #2 represent available tunnel numbers.
          Run 'show interfaces' to see the currently configured vpnt interfaces (if any exist), and use the next consecutive number.
        • Clish commands are provided to facilitate easier automation. It is also possible to configuring the VTI via the Gaia Web-UI as described in section "(4-C) Creating the Transit VPC - Configure VPN Tunnel Interface on the on-premises Security Gateway"

        add vpn tunnel #1 type numbered local {TUN1-INSIDE-CUSTOMER-GATEWAY} remote {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} peer AWS_VPC_Tun1

        add vpn tunnel #2 type numbered local {TUN2-INSIDE-CUSTOMER-GATEWAY} remote {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} peer AWS_VPC_Tun2

        set interface vpnt#1 state on

        set interface vpnt#1 mtu {TUNNEL-INTERFACE-MTU}

        set interface vpnt#2 state on

        set interface vpnt#2 mtu {TUNNEL-INTERFACE-MTU}

        save config

    • (5-C-ii) Configure BGP on the CloudGuard for AWS Security Gateway

      Similar to section "(4-E) Creating the Transit VPC - Configure BGP on the on-premises Security Gateway and on the CloudGuard for AWS Security Gateway" , this section shows how to configure BGP between the CloudGuard Gateway for AWS and the AWS VGW.

      The commands provided below have to be issued in Gaia Clish.

      For details, refer to R80.10 Gaia Advanced Routing Administration Guide and sk95967 - BGP on Gaia OS.

      1. Configure BGP on your CloudGuard for AWS Security Gateway:

        set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} on

        set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} holdtime {NEIGHBOR-HOLD-TIME}

        set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} keepalive 10

        (optional) set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN1-INSIDE-VIRTUAL-PRIVATE-GATEWAY} ping on

        set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} on

        set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} holdtime {NEIGHBOR-HOLD-TIME}

        set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} keepalive 10

        (optional) set bgp external remote-as {VIRTUAL-PRIVATE_GATEWAY-ASN} peer {TUN2-INSIDE-VIRTUAL-PRIVATE-GATEWAY} ping on

        save config

      2. Configure the route maps for BGP route redistribution and import route filtering on your on-premises Security Gateway:

        Description and Comments Syntax
        1. Create a route map to filter inbound routes
        		 set routemap <NAME_IN> id <ID_NUMBER> on
        2. Specify which networks will be matched.

        <REMOTE_NETWORK> is the received network that we want to install into the routing table (this is what the Perimeter advertises.
        		 set routemap <NAME_IN> id <ID_NUMBER> match network <REMOTE_NETWORK> [all | between | exact | off]
        3.Associate the inbound routemap to the BGP peer (which routes are expected to be received from the BGP peer). set bgp external remote-as <REMOTE_AS_VALUE> peer <remote VTI IP> import-routemap <NAME_IN> preference <1- 65535> on
        4. Configure redistribution using a route map (This is what the perimeter advertises) set routemap <NAME_OUT> id <ID_NUMBER> on
        5. Configure matched routing protocol. If this match condition is not specified the default, in this case, is to export only BGP routes to the BGP protocol. set routemap <NAME_OUT> id <ID_NUMBER> on

        set routemap <NAME_OUT> id <ID_NUMBER>         match network 0.0.0.0/0 exact

        set routemap <NAME_OUT> id <ID_NUMBER #2> match protocol static

        6. Specify the ‘aspath-prepend-count’ value for this route.

        The <VALUE>, in this case, is used to define the active member for the specific spoke. The CloudGuard for AWS with the lower value will be the active member for this spoke. 

        As-path-prepend-count description (from Gaia CLI prompt):

        Causes the local Autonomous System (AS) number to be affixed to the beginning of the AS path when routes matching the Route Map are advertised via BGP.

            Value:  1 - 25

        The provided value indicates the number of times the local AS number should be prepended. 

        This action only applies to BGP, and only applies when exporting routes via the "export-routemap" command. The action is otherwise ignored.

        		 set routemap <NAME_OUT> id <ID_NUMBER> action aspath-prepend-count value <VALUE>
        7. Associate the outbound routemap to the BGP peer. set bgp external remote-as <REMOTE_AS_VALUE> peer <REMOTE_VTI_IP> export-routemap <NAME_OUT> preference <1-65535> on

        NOTE: Additional fine tuning can be done using routmap commands.

      3. Save the configuration:

        save config

        Verify the BGP neighborship:

        show bgp peers

        Note: The "State" column should show "Established". Any other state means that BGP neighborship is down.

        Example output:

          Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer

        PeerID                  AS         Routes      ActRts       State                InUpds      OutUpds    Uptime  
169.254.64.125    7224      1              1              Established        1              1              00:01:35
        169.254.63.52     7224      1              0              Established        1              1              00:02:21
      4. In cases where spoke to spoke communication is a requirement the exported routemap must be updated. 
        set routemap <NAME_OUT> id <ID_NUMBER #2> on
        set routemap <NAME_OUT> id <ID_NUMBER #2> match network <TARGET_SPOKE_VPC> all
        set routemap <NAME_OUT> id <ID_NUMBER #2> action aspath-prepend-count <VALUE>

        <NAME_OUT>  - Is the same routemap configured in step 2.
        <VALUE>- This value will designate the active/standby CloudGuard for AWS members. This value must be consistent across all spokes to avoid asymetric routing.  

        For spokes in the same AS (share a region), the user should allow autonomous system override (as_override) on each CloudGuard Gateway for AWS in the Transit VPC:

        set bgp external remote-as <REMOTE_AS> peer <REMOTE_PEER> as-override on
save config

  • (5-D) Connecting Transit VPC to Spoke VPCs - Configure VPN in Check Point SmartConsole

    Show / Hide this subsection

    1. Connect with SmartConsole to Security Management Server / Domain Management Server.

    2. Create a new Interoperable Device:

      1. Go to the Objects menu - go to the More object types menu - go to the Network Object menu - go to the More menu - click on the New Interoperable Device...

      2. Configure the general properties of this Interoperable Device:

        • In the Name field, enter the exact peer used for the first VTI (e.g., AWS_VPC_Tun1).

        • In the IPv4 Address field, enter the {TUN1-OUTSIDE-VIRTUAL-PRIVATE-GATEWAY}
          (refer to section "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC")

        Example:

      3. Configure the topology of this Interoperable Device:

        1. Click on the Topology pane.

        2. In the VPN Domain section, select the option Manually defined.

        3. In the right corner of this field, click on the ellipsis [...]

        4. If you have already created an empty group in a previous section, you can use that group and skip the next four steps. 

        5. Click on the New...

        6. Go to the Group menu.

        7. Click on the Simple Group...

          Example:

        8. Enter some unique name and click on OK (do not add any objects to this group)

          Example:

        9. In the right corner of this field, click on the ellipsis [...] - select the new empty Group object

          Example:

        10. Click OK

    3. Create additional Interoperable Devices for the second tunnel and the tunnels from the second CloudGuard for AWS Security Gateway.
      (refer to section "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC").

    4. Configure your Transit VPC CloudGuard for AWS Security Gateway objects:

      1. Open the object of your Transit VPC CloudGuard for AWS Security Gateway.

      2. Click on the Topology pane.

      3. Click on the Get Interfaces with Topology button to update the topology with the information on the vpnt interfaces.

      4. In the VPN Domain section, select the option Manually defined.

      5. In the right corner of this field, click on the ellipsis [...] - select the empty Group object you created earlier in Step 2 (in the Interoperable Device properties).

      6. Expand the IPsec VPN group and click on Link Selection.

      7. Click on the Statically NATed IP: radial button and enter your {TUN1-OUTSIDE-CUSTOMER-GATEWAY} (CloudGuard for AWS Gateway EIP)


      8. Click OK.

    5. Create a new Star VPN community:

      1. On the left Navigation Toolbar, click on the SECURITY POLICIES app.

      2. In the lower Access Tools section, click on the VPN Communities.

      3. At the top, click on the [*] icon - click on the Star Community.

        Example:

      4. Enter the name of this VPN community.

      5. In the left tree, click on the Gateways pane:

        1. In the Center Gateways section, add your Transit VPC CloudGuard for AWS Security Gateways.

        2. In the Satellite Gateways section, add your Interoperable Devices.

        Example:

      6. In the left tree, click on the Encryption pane:

        1. In the Encryption Method section, select the option IKEv1 for IPv4 and IKEv2 for IPv6 only

        2. In the Encryption Suite section, select the option Custom encryption suite and configure the encryption settings.
          Important Note: These settings must match the settings in the configuration file you downloaded from AWS
          (refer to "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC")

        3. In the More section, check the box use Perfect Forward Secrecy and select Group 2 (1024 bit)

        Example:

      7. In the left tree, click on the Shared Secret pane:

        1. Select the option Use only Shared Secret for all external members

        2. The objects of the Interoperable Devices should already appear.

        3. Configure the pre-shared secret as found in the configuration file you downloaded from AWS
          (refer to section "(5-B) Connecting Transit VPC to Spoke VPCs - Configure connection between Spoke VPC to Transit VPC")

        Example:


      8. In the left tree, click on the Advanced pane:

        1. In the IKE (Phase 1) section, in the Renegotiate IKE security associations every (minutes) field, enter the value 480

        2. In the IKE (Phase 2) section, in the Renegotiate IPsec security associations every (seconds) field, leave the default value 3600

        Example:

      9. Click OK.

    6. Add explicit rules to allow traffic between the Spoke networks and the Transit VPC.

      1. On the left Navigation Toolbar, click on the SECURITY POLICIES app.

      2. In the upper Access Control section, click on the Policy.

      3. Add explicit relevant rules.

    7. Publish the session and install the Access Policy on all relevant Security Gateways.

    8. Optional: It is recommended to enable the Dead Peer Detection (DPD).

      Refer to sk97746 - New VPN features in R77.10 and VPN Administration Guide (R77.X, R80, R80.10).

      Important Note: If you change these settings, then it is necessary to install the Access Policy on all relevant Security Gateways.

    9. Optional: It is recommended to enable TCP MSS Clamping.

      Enabling TCP MSS Clamping is required in most instances. Depending on your ISP, the MSS value supplied by AWS may work correctly.
      However, internal testing has shown that sometimes it is necessary to adjust the MSS on Check Point Gateway as low as 1380 bytes.

      Refer to sk101219 - New VPN features in R77.20 - section "(2) MSS adjustments for Clear and IPsec traffic".

      Important Note: If you change these settings, then it is necessary to install the Access Policy on the on-premises Security Gateway.

    10. Test the environment by initiating end-to-end connections according to the policy.

      Note: At the end of this proceedure there should be four tunnels per spoke (each VGW has 2 tunnels for redundancy, connected to two differnt CloudGuard for AWS Security Gateway).

 

(6) Configuring Remote Access VPN to the Transit VPC

Show / Hide this subsection

This section explains how to configure Remote Access VPN to a corporate gateway, so that it allows a Remote Access client to reach a spoke VPC network.

Note: The procedure below describes a basic working configuration that can be customized according to more specific needs.

Prerequisites

The environment is already configured with:
  • AWS CloudGuard Transit gateways with BGP routes to the spoke VPC
  • Site-to-Site VPN with BGP routes between transit gateways and corporate gateway
  • Users and (optional) user groups that should connect as VPN clients
Configuration on SmartConsole
  1. Under 'Network Objects > Network', create the following objects:
    1. Spoke VPC network
    2. Corporate network
    3. (optional) Network for Office Mode (you can also use the default Office Mode pool)
  2. Under 'Network Objects > Groups > Network Groups', create a "Corporate Encryption Domain" group and add to it the spoke and corporate networks, as well as VTI address on corporate gateway.
  3. Under VPN communities, edit RemoteAccess community (this community is created by default).
    1. Add the corporate gateway as Participating Gateway.
    2. (optional) Under Participate User Group, add the user group you want to use.
  4. Edit the corporate gateway object.
    1. Navigate to 'Network Management > VPN Domain', click on "Set domain for Remote Access Community…". Select RemoteAccess, click on "Set…" and use the Corporate Encryption Domain group you created before.
    2. Navigate to 'IPSec VPN > Link Selection', click "Source IP address settings…" and verify that it is set to "Automatic".
    3. Navigate to 'VPN Clients > Office Mode', select "Allow Office Mode to all users". Select option "Manual (using IP pool)" and set your Office Mode network object
    4. Navigate to 'VPN Client > Remote Access', enable "Support Visitor Mode", and leave the service as "HTTPS".
  5. Install policy on all gateways.
Configuration of BGP on the gateways
  1. Connect to clish on the corporate gateway.
  2. Add a static route from the Office Mode network to the external interface.
  3. Add a route to the routemap exported to the transit gateways with the Office Mode network.
  4. Connect to clish on the transit gateway.
  5. Add a route to the routemap imported from the corporate gateway with the Office Mode network.
Configuration example:

(172.16.10.0/24 = Office Mode network range, eth0 = external interface of corporate gateway, ExportAWS = corporate routemap exported to transit, ImportCorp = AWS routemap imported from corporate)

On the corporate gateway:
corporate_gw> set static-route 172.16.10.0/24 nexthop gateway logical eth0 on
corporate_gw> show route static
[...]
S         172.16.10.0/24     via 0.0.0.0, eth0, cost 0, age 11136

corporate_gw> show configuration routemaps
[...]
set routemap ExportAWS id 10 on
set routemap ExportAWS id 10 allow
set routemap ExportAWS id 10 match network 172.16.10.0/24 all
set routemap ExportAWS id 10 match protocol static
    # set bgp external remote-as 65002 peer 10.0.0.2 export-routemap ExportAWS preference 10 on
You should now see the Office Mode route advertised to the AWS BPG peers
corporate_gw> show bgp peers advertise
BGP Neighbor 10.0.0.2 eBGP (AS 65002)
IPv4 Route          MED         LocalPref   Nexthop          Communities
[...]
172.16.10/24        0           N/A (eBGP)  10.0.0.1
On the AWS gateways:
Transit-A> show configuration routemaps
set routemap ImportCorp id 10 on
set routemap ImportCorp id 10 allow
set routemap ImportCorp id 10 match network 172.16.10.0/24 all
# set bgp external remote-as 65001 peer 10.0.0.1 import-routemap ImportCorp preference 10 on

You should see the Office Mode network route received from corporate

Transit-A> show bgp peers received
BGP Neighbor 10.0.0.1 eBGP (AS 65001)
IPv4 Route          MED         LocalPref   Nexthop          Communities
[…]
172.16.10/24        None        N/A (eBGP)  10.0.0.1

The configuration is done and you can now test if a Remote Access client connected to Corporate can reach AWS spoke networks.

 

(7) Troubleshooting

Show / Hide this subsection

In this section we will show an example of the clish configuration for an environment based on Diagram 6.
Diagram 6: Test environment


Clish configuration from each Security Gateway:

On the Corporate Security Gateway:
 
# Numbered VTI
 
add vpn tunnel 1 type numbered local 169.255.254.100 remote 169.255.254.101 peer Spoke-A
add vpn tunnel 2 type numbered local 169.255.254.102 remote 169.255.254.103 peer Spoke-B

# Configure the routemaps for the spokes
 
set routemap Spoke-A-In id 10 on
set routemap Spoke-A-In id 10 allow
set routemap Spoke-A-In id 10 match network 10.10.0.0/16 all
set routemap Spoke-B-In id 10 on
set routemap Spoke-B-In id 10 allow
set routemap Spoke-B-In id 10 match network 10.20.0.0/16 all
set routemap Spoke-Out id 10 on
set routemap Spoke-Out id 10 allow

   # We do not want the Corporate Security Gateway to act as the default gateway for the spokes.
 
set routemap Spoke-Out id 10 match network 0.0.0.0/0 exact restrict on
set routemap Spoke-Out id 10 match protocol static

  # Local corporate static routes
 
set routemap Spoke-Out id 20 on
set routemap Spoke-Out id 20 allow
set routemap Spoke-Out id 20 match network 192.168.0.0/16 all
set routemap Spoke-Out id 20 match protocol static
# Configure BGP
 
set bgp external remote-as 65002 on
set bgp external remote-as 65002 peer 169.255.254.101 on
set bgp external remote-as 65002 peer 169.255.254.101 accept-med on
set bgp external remote-as 65002 peer 169.255.254.101 ping on
set bgp external remote-as 65002 peer 169.255.254.101 export-routemap "Spoke-Out" preference 10 on
set bgp external remote-as 65002 peer 169.255.254.101 import-routemap "Spoke-A-In" preference 10 on
set bgp external remote-as 65002 peer 169.255.254.101 import-routemap "Spoke-B-In" preference 20 on
set bgp external remote-as 65002 peer 169.255.254.103 on
set bgp external remote-as 65002 peer 169.255.254.103 accept-med on
set bgp external remote-as 65002 peer 169.255.254.103 ping on
set bgp external remote-as 65002 peer 169.255.254.103 export-routemap "Spoke-Out" preference 10 on
set bgp external remote-as 65002 peer 169.255.254.103 import-routemap "Spoke-A-In" preference 10 on 
 set bgp external remote-as 65002 peer 169.255.254.103 import-routemap "Spoke-B-In" preference 20 on

On CloudGuard-A Security Gateway:

# Numbered VTI tunnels
 
add vpn tunnel 1 type numbered local 169.255.254.101 remote 169.255.254.100 peer Corporate-GW
add vpn tunnel 2 type numbered local 169.254.64.110 remote 169.254.64.109 peer CloudGuard-A_To_Spoke-A_Tun1
add vpn tunnel 3 type numbered local 169.254.65.174 remote 169.254.65.173 peer CloudGuard-A_To_Spoke-A_Tun2
add vpn tunnel 4 type numbered local 169.254.65.198 remote 169.254.65.197 peer CloudGuard-A_To_Spoke-B_Tun1
add vpn tunnel 5 type numbered local 169.254.65.154 remote 169.254.65.153 peer CloudGuard-A_To_Spoke-B_Tun2
# Configure the routemap
 
  # Routemap towards the Corporate Network
 
set routemap Corporate-In id 10 on
set routemap Corporate-In id 10 allow
set routemap Corporate-In id 10 match network 192.168.0.0/16 all
set routemap Corporate-Out id 10 on
set routemap Corporate-Out id 10 allow

   # aspath-prepend-count value set to 1 to designate CloudGuard-A as the active member for network 10.10.0.0/16 (Spoke A)
 
set routemap Corporate-Out id 10 match network 10.10.0.0/16 all
set routemap Corporate-Out id 10 action aspath-prepend-count value 1
set routemap Corporate-Out id 20 on
 set routemap Corporate-Out id 20 allow

  # aspath-prepend-count value set to 2 to designate CloudGuard-A as the standby member for network 10.20.0.0/16 (Spoke B)
 
set routemap Corporate-Out id 20 match network 10.20.0.0/16 all
set routemap Corporate-Out id 20 action aspath-prepend-count value 2

   # Routemap towards Spoke-A

set routemap Spoke-A-In id 10 on
set routemap Spoke-A-In id 10 allow
set routemap Spoke-A-In id 10 match network 10.10.0.0/16 all
set routemap Spoke-A-Out id 10 on
 set routemap Spoke-A-Out id 10 allow

    # Set CloudGuard-A as the active default gateway member for Spoke-A (This setting can alternate between spokes)
 
set routemap Spoke-A-Out id 10 match network 0.0.0.0/0 exact
set routemap Spoke-A-Out id 10 match protocol static
set routemap Spoke-A-Out id 10 action aspath-prepend-count value 1
set routemap Spoke-A-Out id 20 on
 set routemap Spoke-A-Out id 20 allow

  # Network 10.20.0.0 (Spoke B) is advertised to Spoke-A with an aspath-prepend-count value set to 1 to designate CloudGuard-A as the active  member for spoke to spoke communication (Spoke-A will be the active member for spoke to spoke communication  across all spokes)
 
set routemap Spoke-A-Out id 20 match network 10.20.0.0/16 all
set routemap Spoke-A-Out id 20 action aspath-prepend-count value 1

   # Routemap towards Spoke-B
 
set routemap Spoke-B-In id 10 on
set routemap Spoke-B-In id 10 allow
set routemap Spoke-B-In id 10 match network 10.20.0.0/16 all
set routemap Spoke-B-Out id 10 on
set routemap Spoke-B-Out id 10 allow

   # Set CloudGuard-A as the standby default gateway member for Spoke-B (This setting can alternate between spokes)
 
set routemap Spoke-B-Out id 10 match network 0.0.0.0/0 exact
set routemap Spoke-B-Out id 10 match protocol static
set routemap Spoke-B-Out id 10 action aspath-prepend-count value 2
set routemap Spoke-B-Out id 20 on
 set routemap Spoke-B-Out id 20 allow

  # Network 10.10.0.0 (Spoke A) is advertised to Spoke-B with an aspath-prepend-count value set to 1 to designate CloudGuard-A as the active member for spoke to spoke communication (Spoke-A will be the active member for spoke to spoke communication across all spokes)
 
set routemap Spoke-B-Out id 20 match network 10.10.0.0/16 all
set routemap Spoke-B-Out id 20 action aspath-prepend-count value 1

# Configure BGP
 
set bgp external remote-as 7224 on
set bgp external remote-as 7224 peer 169.254.64.109 on

   # Since Spoke A and Spoke B are both in the same AS this setting is required to allow spoke to spoke communication
 
set bgp external remote-as 7224 peer 169.254.64.109 as-override on
set bgp external remote-as 7224 peer 169.254.64.109 holdtime 30
set bgp external remote-as 7224 peer 169.254.64.109 keepalive 10
set bgp external remote-as 7224 peer 169.254.64.109 export-routemap "Spoke-A-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.64.109 import-routemap "Spoke-A-In" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.153 on
set bgp external remote-as 7224 peer 169.254.65.153 as-override on
set bgp external remote-as 7224 peer 169.254.65.153 holdtime 30
set bgp external remote-as 7224 peer 169.254.65.153 keepalive 10
set bgp external remote-as 7224 peer 169.254.65.153 export-routemap "Spoke-B-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.153 import-routemap "Spoke-B-In" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.173 on
set bgp external remote-as 7224 peer 169.254.65.173 as-override on
set bgp external remote-as 7224 peer 169.254.65.173 holdtime 30
set bgp external remote-as 7224 peer 169.254.65.173 keepalive 10
set bgp external remote-as 7224 peer 169.254.65.173 export-routemap "Spoke-A-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.173 import-routemap "Spoke-A-In" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.197 on
set bgp external remote-as 7224 peer 169.254.65.197 as-override on
set bgp external remote-as 7224 peer 169.254.65.197 holdtime 30
set bgp external remote-as 7224 peer 169.254.65.197 keepalive 10
set bgp external remote-as 7224 peer 169.254.65.197 export-routemap "Spoke-B-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.197 import-routemap "Spoke-B-In" preference 10 on
set bgp external remote-as 65001 on
set bgp external remote-as 65001 peer 169.255.254.100 on
set bgp external remote-as 65001 peer 169.255.254.100 ping on
set bgp external remote-as 65001 peer 169.255.254.100 export-routemap "Corporate-Out" preference 10 on
 set bgp external remote-as 65001 peer 169.255.254.100 import-routemap "Corporate-In" preference 10 on

On CloudGuard-B Security Gateway:

# Numbered VTI
 
add vpn tunnel 1 type numbered local 169.255.254.103 remote 169.255.254.102 peer Corporate-GW
add vpn tunnel 2 type numbered local 169.254.64.142 remote 169.254.64.141 peer CloudGuard-B_To_Spoke-A_Tun1
add vpn tunnel 3 type numbered local 169.254.66.38 remote 169.254.66.37 peer CloudGuard-B_To_Spoke-A_Tun2
add vpn tunnel 4 type numbered local 169.254.67.122 remote 169.254.67.121 peer CloudGuard-B_To_Spoke-B_Tun1
 add vpn tunnel 5 type numbered local 169.254.65.218 remote 169.254.65.217 peer CloudGuard-B_To_Spoke-B_Tun2

# Configure the routemap
 
  # Routemap towards the Corporate Network
 
set routemap Corporate-In id 10 on
set routemap Corporate-In id 10 allow
set routemap Corporate-In id 10 match network 192.168.0.0/16 all
set routemap Corporate-Out id 10 on
 set routemap Corporate-Out id 10 allow

  # aspath-prepend-count value set to 2 to designate CloudGuard-B as the standby member for network 10.10.0.0/16 (Spoke A)
 
set routemap Corporate-Out id 10 match network 10.10.0.0/16 all
set routemap Corporate-Out id 10 action aspath-prepend-count value 2
set routemap Corporate-Out id 20 on
 set routemap Corporate-Out id 20 allow

  # aspath-prepend-count value set to 1 to designate CloudGuard-B as the active member for network 10.20.0.0/16 (Spoke B)
 
set routemap Corporate-Out id 20 match network 10.20.0.0/16 all
set routemap Corporate-Out id 20 action aspath-prepend-count value 1

  # Routemap towards Spoke-A
 
set routemap Spoke-A-In id 10 on
set routemap Spoke-A-In id 10 allow
set routemap Spoke-A-In id 10 match network 10.10.0.0/16 all
set routemap Spoke-A-Out id 10 on
 set routemap Spoke-A-Out id 10 allow

  # Set CloudGuard-B as the standby default gateway member for Spoke-A (This setting can alternate between spokes)
 
set routemap Spoke-A-Out id 10 match network 0.0.0.0 exact
set routemap Spoke-A-Out id 10 match protocol static
set routemap Spoke-A-Out id 20 on
 set routemap Spoke-A-Out id 20 allow

  # Network 10.20.0.0 (Spoke B) is advertised to Spoke-A with an aspath-prepend-count value set to 2 to designate CloudGuard-B as the standby member for spoke to spoke communication (Spoke-B will be the standby member for spoke to spoke communication across all spokes)
 
set routemap Spoke-A-Out id 20 match network 10.20.0.0/16 all
set routemap Spoke-A-Out id 20 action aspath-prepend-count value 2
  # Routemap towards Spoke-B
set routemap Spoke-B-In id 10 on
set routemap Spoke-B-In id 10 allow
set routemap Spoke-B-In id 10 match network 10.20.0.0/16 all
set routemap Spoke-B-Out id 10 on
 set routemap Spoke-B-Out id 10 allow

  # Set CloudGuard-B as the active default gateway member for Spoke-B (This setting can alternate between spokes)
 
set routemap Spoke-B-Out id 10 match network 0.0.0.0/0 exact
set routemap Spoke-B-Out id 10 match protocol static
set routemap Spoke-B-Out id 10 action aspath-prepend-count value 1
set routemap Spoke-B-Out id 20 on
 set routemap Spoke-B-Out id 20 allow

  # Network 10.10.0.0 (Spoke A) is advertised to Spoke-B with an aspath-prepend-count value set to 2 to designate CloudGuard-B as the standby member for spoke to spoke communication (Spoke-B will be the standby member for spoke to spoke communication across all spokes )
 
set routemap Spoke-B-Out id 20 match network 10.10.0.0/16 all
set routemap Spoke-B-Out id 20 action aspath-prepend-count value 2

# Configure BGP
 
set bgp external remote-as 7224 on
set bgp external remote-as 7224 peer 169.254.64.141 on

  # Since Spoke A and Spoke B are both in the same AS this setting is required to allow spoke to spoke communication
 
set bgp external remote-as 7224 peer 169.254.64.141 as-override on
set bgp external remote-as 7224 peer 169.254.64.141 holdtime 30
set bgp external remote-as 7224 peer 169.254.64.141 keepalive 10
set bgp external remote-as 7224 peer 169.254.64.141 export-routemap "Spoke-B-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.64.141 import-routemap "Spoke-B-In" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.217 on
set bgp external remote-as 7224 peer 169.254.65.217 as-override on
set bgp external remote-as 7224 peer 169.254.65.217 holdtime 30
set bgp external remote-as 7224 peer 169.254.65.217 keepalive 10
set bgp external remote-as 7224 peer 169.254.65.217 export-routemap "Spoke-A-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.65.217 import-routemap "Spoke-A-In" preference 10 on
set bgp external remote-as 7224 peer 169.254.66.37 on
set bgp external remote-as 7224 peer 169.254.66.37 as-override on
set bgp external remote-as 7224 peer 169.254.66.37 holdtime 30
set bgp external remote-as 7224 peer 169.254.66.37 keepalive 10
set bgp external remote-as 7224 peer 169.254.66.37 export-routemap "Spoke-B-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.66.37 import-routemap "Spoke-B-In" preference 10 on
set bgp external remote-as 7224 peer 169.254.67.121 on
set bgp external remote-as 7224 peer 169.254.67.121 as-override on
set bgp external remote-as 7224 peer 169.254.67.121 holdtime 30
set bgp external remote-as 7224 peer 169.254.67.121 keepalive 10
set bgp external remote-as 7224 peer 169.254.67.121 export-routemap "Spoke-A-Out" preference 10 on
set bgp external remote-as 7224 peer 169.254.67.121 import-routemap "Spoke-A-In" preference 10 on
set bgp external remote-as 65001 on
set bgp external remote-as 65001 peer 169.255.254.102 on
set bgp external remote-as 65001 peer 169.255.254.102 ping on
set bgp external remote-as 65001 peer 169.255.254.102 export-routemap "Corporate-Out" preference 10 on
 set bgp external remote-as 65001 peer 169.255.254.102 import-routemap "Corporate-In" preference 10 on


The output of 'show bgp peers':

Corporate> show bgp peers
Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
PeerID           AS           Routes  ActRts  State             InUpds  OutUpds  Uptime
169.255.254.101  65002        2       1       Established       22      3        07:25:16
 169.255.254.103  65002        2       1       Established       23      3        07:25:10

CloudGuard-A> show bgp peers
Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
PeerID           AS           Routes  ActRts  State             InUpds  OutUpds  Uptime
169.254.64.109   7224         1       1       Established       1       2        02:24:47
169.254.65.153   7224         1       1       Established       1       7        04:14:22
169.254.65.173   7224         1       0       Established       3       6        04:13:45
169.254.65.197   7224         1       0       Established       1       7        04:13:39
 169.255.254.100  65001        1       1       Established       3       22       07:25:25

CloudGuard-B> show bgp peers
Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
PeerID           AS           Routes  ActRts  State             InUpds  OutUpds  Uptime
169.254.64.141   7224         1       1       Established       1       2        01:42:10
169.254.65.217   7224         1       1       Established       1       2        01:42:22
169.254.66.37    7224         1       0       Established       1       2        01:42:04
169.254.67.121   7224         1       0       Established       1       5        04:14:32
 169.255.254.102  65001        1       1       Established       3       23       07:25:50

The routes received/advertised from CloudGuard-A:

CloudGuard-A> show bgp peers advertise
BGP Neighbor 169.254.64.109 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
0.0.0.0/0           None         N/A (eBGP)  169.254.64.110
10.20/16            None         N/A (eBGP)  169.254.64.110
BGP Neighbor 169.254.65.153 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
0.0.0.0/0           None             N/A (eBGP)   169.254.65.154
10.10/164           None         N/A (eBGP)   169.254.65.154
BGP Neighbor 169.254.65.173 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
0.0.0.0/0           None          N/A (eBGP)  169.254.65.174
10.20/16            None          N/A (eBGP)  169.254.65.174
BGP Neighbor 169.254.65.197 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
0.0.0.0/0           None          N/A (eBGP)  169.254.65.198
10.10/16            None          N/A (eBGP)  169.254.65.198
BGP Neighbor 169.255.254.100 eBGP (AS 65001) IPv4 Route          MED         LocalPref   Nexthop          Communities
10.10/16            None          N/A (eBGP)  169.255.254.101
 10.20/16            None          N/A (eBGP)  169.255.254.101


CloudGuard-A> show bgp peers received
BGP Neighbor 169.254.64.109 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
10.10/16            None        N/A (eBGP)  169.254.64.109
BGP Neighbor 169.254.65.153 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
10.20/16            None        N/A (eBGP)  169.254.65.153
BGP Neighbor 169.254.65.173 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
10.10/16            None        N/A (eBGP)  169.254.65.173
BGP Neighbor 169.254.65.197 eBGP (AS 7224)
IPv4 Route          MED         LocalPref   Nexthop          Communities
10.20/16            None        N/A (eBGP)  169.254.65.197
BGP Neighbor 169.255.254.100 eBGP (AS 65001)
IPv4 Route          MED         LocalPref   Nexthop          Communities
 192.168/16          None        N/A (eBGP)  169.255.254.100

 

Show / Hide this section

 

 

(10) Revision History

Show / Hide revision history

Date Description
18 Oct 2017
  • Improved design of this article
17 Oct 2017
  • First release of this article

Configure route maps for BGP route redistribution and import route filtering. 

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