Additional Features

In This Section: Configuring VPN between the Transit CloudGuard Gateways and Your On-Premises Gateway Tagging a Spoke VPC Setting a Role on a Spoke VPC Account Multi-Hub Support Exporting Custom Routes to Spokes Enabling Custom Routes to Spokes Ignore Manually Created VPN Connections Ignore Manually Created Customer Gateways Changing the ASN of the Transit Gateway Running Transit and Auto-Scaling Simultaneously Deploying a Security Management Server Without an Internet Connection

Configuring VPN between the Transit CloudGuard Gateways and Your On-Premises Gateway

It is possible to connect your Corporate Gateway to the Transit hub. To do so, create a VPN tunnel on each CloudGuard Gateway towards the Corporate Gateway.

The customer manually performs the provisioning of VPN towards the Corporate Gateway.

• To create VPN and configure BGP on the on-premises gateway towards the Transit Gateways:

  Follow sk120534 - Section "(4-C) Creating the Transit VPC - Configure VPN Tunnel Interface on the on-premises Security Gateway".

• To configure BGP on the Transit VPC gateways toward the on-premises gateways:

  Follow sk120534 - Section "(5-C) Connecting Transit VPC to Spoke VPCs - Configure Gaia OS on CloudGuard Gateways for AWS".

For more information, see about the Transit VPC Architecture, see sk120534.

Tagging a Spoke VPC

Step	Description
1	Create the spoke VPC and its subnets.
2	Edit the VPC and add this tag: Tag key: x-chkp-vpn Tag value: <MANAGEMENT-NAME>/<VPN-COMMUNITY-NAME> Where: <MANAGEMENT-NAME> - Specifies the name of the Security Management Server. Use the same name you used when you executed the autoprov_cfg utility. <VPN-COMMUNITY-NAME> - Specifies the name of the VPN Community. Use the same name you used when you created the VPN Community.

To connect a spoke VPC to multiple VPN communities, see Multi-Hub Support.

To unlink a spoke, remove the tag. This deletes the transit configuration automatically.

Note - If an AWS Virtual Private Gateway (VGW) does not already exist, transit creates it and propagates routes from it, only to the main route table of the VPC. Make sure that all the subnets you want to use with transit, are associated with the main route table.

Setting a Role on a Spoke VPC Account

Important:

• This configuration is required only if you plan to deploy a spoke VPC in an AWS account, other than the AWS account, where the Transit VPC is deployed.
• You have to return to those steps for all other AWS accounts, into which you deploy a spoke.

Launch the Cross Account Permissions AWS CloudFormation template on the trustee (spoke) account.

Direct Link to AWS Cross Account Permissions Template.

For more information, see sk122074.

Parameters for deploying the STS Role template:

Parameter label (name)	Default	Description
Trusted Account ID (Trusted account)	Requires input	A 12-digit number that represents the ID of the Transit VPC account. Enter that number.
IAM Role Permissions (Permissions)	Read-only	Important - You must select Create with read-write permissions.

• The template creates an AWS IAM role with all the permissions required for the Security Management Server to provision resources in the spoke VPC account.
• To review your newly created trust relationship, find the new role in the AWS IAM dashboard. Confirm the Transit VPC account number appears on the Trust Relationship tab.

Use the value that is displayed on the Outputs tab to configure the environment afterwards.

Key	Description
Role	AWS ARN for the new role you created. Use this role in the STS Role field in the deployment of the Check Point Security Management Server.

Note - You will be able to add or remove additional spoke accounts later. To do that, edit the Security Management Server Role profile in AWS and add or remove ARNs.

Multi-Hub Support

You can connect a spoke VPC to more than one Transit Hub.

For example, the first Transit Hub serves for Internet outbound traffic and the second Transit Hub serves for the corporate and spoke-to-spoke traffic.

To configure Multi-Hub support:

Step	Description
1	Connect to the command line on the Check Point Security Management Server.
2	Log in to the Expert mode.
3	Use the config-community.sh script to configure a separate Star VPN Community for each Transit Hub: /etc/fw/scripts/autoprovision/config-community.sh "<VPN_COMMUNITY_NAME_1>" /etc/fw/scripts/autoprovision/config-community.sh "<VPN_COMMUNITY_NAME_2>"
4	Use the autoprov_cfg CLI tool to add both Star VPN communities to the Controller: autoprov-cfg set controller AWS -cn "<CONTROLLER_NAME>" -com "<VPN_COMMUNITY_NAME_1>,<VPN_COMMUNITY_NAME_2>"
5	Use the autoprov_cfg CLI tool to create a new template for each Transit Hub: autoprov_cfg add template -tn "<TEMPLATE_NAME_1>" -otp "<PASSWORD>" -ver R80.10 -po "<POLICY_NAME>" -vpn -vd "<VPN_DOMAIN_1>" -com "<VPN_COMMUNITY_NAME_1>" autoprov_cfg add template -tn "<TEMPLATE_NAME_2>" -otp "<PASSWORD>" -ver R80.10 -po "<POLICY_NAME>" -vpn -vd "<VPN_DOMAIN_2>" -com "<VPN_COMMUNITY_NAME_2>"
6	On the AWS CloudFormation service, deploy the Transit template for both hubs.
7	For each spoke VPC, add a tag. The tag will include information on all the Hubs, separated by a colon. Key: x-chkp-vpn Value: <MANAGEMENT_NAME>/<VPN_COMMUNITY_NAME_1>:<MANAGEMENT_NAME>/<VPN_COMMUNITY_NAME_2>

Important - If you add or remove a Transit Hub to an existing Hub, the configuration on all existing spokes is removed. This creates a Multi-Hub configuration for each spoke VPC. That causes reprovisioning of all the VPN connections and it may take time to finish. For example, when you design a Multi-Hub topology.

Expect downtime during the reconfiguration of the spoke VPCs. Schedule a maintenance window to perform these configuration steps. The amount of downtime it takes, depends on the number of tunnels you have.

Exporting Custom Routes to Spokes

By default, BGP settings export "all Internet (0.0.0.0/0)" CIDR to the spoke. This means that outgoing traffic from the spoke VPC is routed to the Transit Gateways.

There may be times that you want to export specific custom routes, instead of "all Internet". For example, in a Multi-Hub architecture where one hub handles the outbound traffic to the Internet, and the second Transit Hub serves for the spoke-to-spoke traffic. Another example is a single Transit hub environment, which enables spoke-to-spoke communication without allowing Internet access.

Enabling Custom Routes to Spokes

To configure a specific route, you have to configure two additional BGP routemaps:

Routemap	Description
spoke-routes	Name for a BGP routemap that contains all spoke CIDRs. This routemap is automatically created on the Transit Gateway and exported to the spokes, to enable all spoke-to-spoke traffic. Important - Do not use the name of a routemap that you have already defined on the Security Gateway, or a routemap that you want to manage manually. If you do so, this routemap will be overridden by the automation.
export-routes	Name for a BGP routemap that will also be exported to the spokes. The user has to create and manage this routemap on all Transit Gateways. This routemap can contain any routes you want to export to the spoke. For example, the route of a corporate network CIDR. Important - If you want to enable custom routes, you must enable the routes before you connect any spoke VPC to the Transit. If there are already spoke VPCs connected to the VPC and you want to enable custom routes, you have to disconnect them from the Transit: Remove the tag from the spoke VPC to disconnect it from Transit. Configure custom routes. Add the tag to reconnect the spoke.

To enable custom routes on the Security Management Server, run the config-community.sh script:

$FWDIR/scripts/autoprovision/config-community.sh "<VPN-COMMUNITY-NAME>" [<SPOKE-ROUTES> [<EXPORT-ROUTES>, <EXPORT-ROUTES> ...]]

Replace these variables with the names in your configuration:

• "<VPN-COMMUNITY-NAME>"
• <SPOKE-ROUTES> (there can only be one <SPOKE-ROUTE> map)
• <EXPORT-ROUTES> (multiple <EXPORT-ROUTE> names can be added, separated by a comma)

IMPORTANT

• After you add a new VPN Community, you must also add each Security Gateway of the new hub as a Center Gateway in the VPN Community. The Transit service automatically identifies new Transit CloudFormation stack deployments. Therefore, you have to add Security Gateways to the correct VPN Community that you defined with the autoprov_cfg for this configuration template.
• The config-community.sh does not add Security Gateways as hub.
• We recommend that you stop the service when you add a new hub.

Ignore Manually Created VPN Connections

The Transit service scans all VPN connections in the region of a spoke VPC and tries to create interoperable device objects and VTI that match these connections.

If you want to create a VPN connection to a Transit Hub CloudGuard Security Gateway manually, add a tag to the AWS VPN connection object. This will cause the automation to ignore it.

Key: x-chkp-vpn

Value: ignore

Ignore Manually Created Customer Gateways

As part of the Transit automation work, the Transit service is also responsible to create the AWS customer gateway objects on each spoke VPC region/account.

The service deletes all customer gateways when they are not referenced by a VPN Connection. If you want to preserve your manually created customer gateways, add a tag on the AWS customer gateway object. This will cause the automation to ignore it.

Key: x-chkp-vpn

Value: ignore

Changing the ASN of the Transit Gateway

Important - Changing the Autonomous System number can be dangerous and can harm the internal data structures used by the Transit service. Make sure to edit only the AS number digits when you change the comment field.

A unique AS value is set for the Transit Gateways as part of the CloudFormation Template attributes. You cannot change the AS value through the AWS CloudFormation templates or through SmartConsole. You can change it through the AWS Console, or the Gaia Portal.

To change the ASN on the Transit Gateway:

Step	Description
1	In the AWS Console, remove the x-chkp-vpn tag from all spoke VPCs. Wait for all the AWS VPN and Check Point resources to be removed. Make sure no interoperable devices remain that are related to the resources you removed.
2	On the Security Management Server, stop the service: Connect to the command line the Security Management Server. Log in to the Expert mode. Stop the service: service cme stop This ensures that no new tags on the spoke VPCs are identified during this process.
3	Configure the Autonomous System number on the Transit Gateway in one of these ways: In Gaia Clish: Connect to the command line on the Transit Gateway. Log in to the Gaia Clish. Configure the AS: set as <AS_Number> Save the configuration: save config In Gaia Portal: Connect with a web browser to the Transit Gateway at: https://<Gaia Management IP Address> From the left tree, click Advanced Routing > BGP. In the BGP Global Settings section, click the Change Global Settings button. In the Autonomous System section, select Local Autonomous System Number. Enter the AS number. Click Save.
4	On the Security Gateway examine the new AS number: Connect to the command line the Security Gateway. Log in to the Expert mode. Run: config-vpn show
5	Connect with SmartConsole to Security Management Server.
6	The Transit service uses the Comment field to store configuration attributes. Find the @ sign. The old AS value follows it. Edit the value and replace the old value with the new AS value. Example: {tags=managed-virtual-gateway|__once__|__load_balancer__|__template__MyTemplate|__vpn__192.168.1.1@65001}
7	Repeat the steps above on all Security Gateways in the Transit Hub.
8	Add tags back to all related Spoke VPCs.
9	On the Security Management Server, start the service: service cme start
10	Wait for the new resources to provision. New Customer gateway objects are created. VPN Tunnels and BGP configurations are created with the new AS value on each gateway.

Running Transit and Auto-Scaling Simultaneously

To run Check Point Auto Scaling in AWS on the same Security Management Server that runs Transit:

Step	Description
1	Connect to the command line the Security Management Server.
2	Log in to the Expert mode.
3	Use the autoprov_cfg CLI tool to add the -slb attribute to the main Controller: autoprov_cfg set controller AWS -cn "<CONTROLLER-NAME>" -slb
4	Use the autoprov_cfg CLI tool to create an additional template for the auto-scale gateway: autoprov_cfg add template -tn "<NEW-TEMPLATE-NAME>" -otp "<SIC-KEY>" -ver R80.10 -po "<POLICY-NAME>"

For more information about configuring Auto Scaling in AWS, see sk112575.

Deploying a Security Management Server Without an Internet Connection

It is mandatory that you have an Internet connection when you deploy the Security Management Server CloudFormation template. The CloudFormation template needs an Internet connection to confirm the deployment was successful.

If the Security Management Server instance cannot be reached over the Internet, the CloudFormation deployment will fail and the CloudFormation stack is reverted.

To deploy a Security Management Server without an Internet connection:

Step	Description
1	In the CloudFormation template: Go to Check Point Settings > Installation Type. Select Manual Configuration. Wait for the instance deployment to complete.
2	Connect with a web browser to the Security Management Server at: https://<Gaia Management IP Address>
3	Enter the username admin, and the password you entered on the CloudFormation template.
4	Click Login. The Gaia First Time Configuration Wizard opens.
5	Follow the instructions on the screen.