Forcepoint Next-Gen Firewall and AWS Transit Gateway
Table of contents
- Forcepoint Next-Gen Firewall and AWS Transit Gateway
- Summary
- Configure Forcepoint SMC
- Provision AWS S3 bucket for Lambda code
- Generate key pairs and identify AMI
- Unpack and configure SMC Connector
- Check SMC API is reachable
- Deploy Lambda code and CloudFormation Template
- Configuring Auto-scaling group
- Troubleshooting
- Appendix – Pem files
- Appendix – Configuration File
- Appendix – Engine states
License
These contents are licensed under Apache License, Version 2.0. http://www.apache.org/licenses/LICENSE-2.0
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE SITE AND ITS CONTENT IS PROVIDED TO YOU ON AN “AS IS,” “AS AVAILABLE” AND “WHERE-IS” BASIS. ALL CONDITIONS, REPRESENTATIONS AND WARRANTIES WITH RESPECT TO THE SITE OR ITS CONTENT, WHETHER EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF THIRD PARTY RIGHTS, ARE HEREBY DISCLAIMED
Document Revision
Version | Date | Author | Notes |
---|---|---|---|
0.1 | 21 August 2020 | Michael Nevin | First draft |
0.2 | 31 August 2020 | Mattia Maggioli | Review |
0.3 | 07 September 2020 | Neelima Rai | Added Troubleshooting chapter |
0.4 | 09 September 2020 | Mattia Maggioli | Minor updates |
0.5 | 23 November 2020 | Michael Nevin, Neelima Rai | Minor updates |
0.6 | 16 August 2022 | Ville Mattila | Update for v3.0 |
Summary
This guide provides step by step instructions to deploy and configure a technology stack on AWS that enables integration of Forcepoint Next Generation Firewall (NGFW) and AWS Transit Gateway.
The integration is set up using a CloudFormation template that deploys an autoscaling template connected with an AWS Transit Gateway using an AWS Lambda function to configure the NGFW engines in the existing Forcepoint Security Management Center (SMC) and provide connectivity for on-premise traffic to networks within AWS VPCs and vice versa.
The code and instructions provided enables system administrators to automatically:
-
Deploy all AWS resources necessary to setup NGFW Engines and AWS Transit Gateway
-
Connect Forcepoint NGFW engines deployed as EC2 instances from the autoscaling template with an existing Forcepoint SMC
-
Configure and connect on-premise and EC2-based NGFW engines to bridge traffic between on-premise and AWS workloads
A description of the workflow between the components involved in this POC is depicted in this diagram:
Demo
Source Code
Caveats
The integration described in this document was developed and tested with the following product versions:
-
Forcepoint NGFW 6.10.0
-
Forcepoint SMC 6.10.x, 6.11.x
This interoperability uses:
-
AWS CloudFormation: for modelling and provisioning AWS and third-party application resources in your cloud environment
-
AWS Transit Gateway: connects VPCs and on-premises networks through a central hub
-
AWS Lambda: to run code without provisioning or managing servers
-
AWS S3: an object storage service that offers industry-leading scalability, data availability, security, and performance
-
AWS EC2: a web service that provides secure, resizable compute capacity in the cloud
-
Amazon EventBridge a serverless event bus that makes it easier to build event-driven applications
-
Auto Scaling groups an Auto Scaling group contains a collection of Amazon EC2 instances that are treated as a logical grouping for the purposes of automatic scaling and management.
Implementation
This implementation requires the following resources:
-
fp-ngfw-aws-TransitGateway-autoscaling.zip available at this link: https://frcpnt.com/fp-ngfw-aws-transitgateway-latest
-
a single VPC, which will be created by the CloudFormation deployment workflow.
-
multiple Elastic IPs in AWS (based on number of engines running)
Please note the standard limit for each AWS region is 5 VPCs and 5 Elastic IPs (EIP), therefore the region chosen for the deployment must allow for the creation of a new VPC and new EIPs (the limit can be increased by contacting AWS support).
This implementation has been tested working with the following requirements:
-
Ubuntu 20.04.1 LTS (with at least 2 GB RAM and 20 GB free disk space)
-
Python 3.8
and the following Python modules:
-
fp-NGFW-SMC-python
-
crhelper
-
xmltodict
-
boto3
Networking requirements
The deployment and configuration tasks performed by the CloudFormation template involve network traffic between the existing SMC and NGFW engines installed on AWS as EC2 instances. Therefore, network traffic to/from AWS and on-premise locations must be allowed accordingly.
Please refer to Appendix B of this document to identify the necessary ports and protocols needed to allow SMC API, NGFW engines and IPSEC network traffic.
Configure Forcepoint SMC
Forcepoint SMC must be reachable from the AWS components that provision the necessary configuration between the NGFW engines hosted in AWS and the existing SMC using the SMC API. If SMC is not already reachable from outside the private company network, do as follows:
-
Sign into the SMC.
-
Navigate to Configuration > Administration.
-
Expand Access Rights and select API Clients.
-
Right-click API Clients and select New API Client. This will open the API Client Properties.
-
Add a name then click Generate Authentication Key.
-
Store the authentication key in a safe location as it will be needed in the following chapters.
-
Select the Permissions tab and choose Unrestricted Permissions (Superuser) using the radio button, then click OK.
-
In the side menu go to Certificates and select TLS Credentials.
-
Right-click TLS Credentials and select New TLS Credentials: enter a name for the certificate and enter the publicly accessible IP address into the Common Name [CN] field. Leave all other fields to the existing default values, then select Next >.
-
On the next screen select the option Self-Sign then Finish.
-
Right-click the newly created Credential and select Properties.
-
From the Certificate properties window select the Certificate tab, then copy the entire content including the lines
—–BEGIN CERTIFICATE—–
and
—–END CERTIFICATE—–
Store the certificate in a safe location since it will be used in the next chapters of this guide. Click OK.
-
Close the Certificate window and in the side menu expand Other Elements and right-click Locations. Select New Location. In the Location Properties window that opens enter cloud in the Name field using only lower-case characters, then click OK.
-
In the SMC header select Home then in the side menu select Others. Right-click Management Server and select Properties…
-
From the General tab select Exceptions…
-
In the Exceptions window select Add… and choose the location cloud created in the previous steps. Select cloud and enter the public IP of the SMC into the Contact Addresses section, then click OK.
-
Navigate to the SMC API tab and select Enable.
-
From the Server Credentials section click the option Select… and from the Select Element windows select the TLS Credentials that were created earlier.
-
From the Server TLS Cryptography Suite Set section, click the option Select and from the Select Element window select the option NIST(SP 800-52 Rev.2) Compatible TLS Cryptographic Algorithms
Click Select and then OK in the Management Server-Properties window when finished. Click Yes next.
-
Back in the Home tab of the SMC right-click Log Server and select Properties, then add an exception same as previously done at step 16.
Provision AWS S3 bucket for Lambda code
Code of the AWS Lambda functions deployed by CloudFormation will be stored in a folder inside an S3 bucket. An existing bucket can be used, or a new one can be provisioned.
-
From the console of AWS search for S3 and select it from the drop-down menu.
-
In the S3 page select Create new Bucket (or use an existing bucket if you already have one).
-
Create a folder named exactly Lambda-Functions (case specific) in the chosen bucket, either new or existing.
-
Within the Lambda-Functions folder create another folder named config-smc (case specific): this is where the code for the AWS Lambda function will be uploaded to.
-
Store the name of the bucket into a safe location since it will be needed in the next chapters of this guide.
Generate key pairs and identify AMI
The Amazon Machine Image (AMI) ID is required to deploy the NGFW engines within an AWS region. Both the AMI ID and the name of the AWS Region will be used in the configuration file used in this integration.
-
Using the AWS console search for EC2. Select it from the drop down.
-
On the left navigation bar, in the Network & Security section, select Key Pairs.
-
Select Create key pair in the top right.
-
On the next page, name your key ngfw-tgw-keypair (all lower case). Select file format pem and then Create Key Pair. This will direct you back to the page where you created the key and will automatically download the keypair file: save this file in a safe location as it will be needed to access the EC2 instances deployed as part of this integration.
-
Once the key pair is created, select Instances from the left navigation area, then Launch Instance to be able to choose an Amazon Machine Image.
-
In the AMI wizard search for Forcepoint NGFW and select the tab AWS Marketplace on the left navigation area. One of the options will be Forcepoint NGFW (BYOL) - Next Generation Firewall. Click Previous versions link below that.
-
On the next page select Continue to Configuration.
-
On the next page select the region you want to use, everything else can be left as default. The AMI ID will appear below the region drop-down menu: save this value in a safe location as will be needed in the next chapters of this guide.
Unpack and configure SMC Connector
-
Download the latest version of fp-ngfw-aws-TransitGateway-autoscaling.zip available at this link: https://github.com/Forcepoint/fp-bd-aws-transitgateway-ngfw/releases/latest to a directory on your Linux machine and unzip it.
-
Open config.json and smc.pem with a text editor and add the necessary values to each field. For the smc.pem file, refer to the step 12 of the chapter Configure Forcepoint SMC. A description with examples of each field is provided in the Appendix – Configuration file and Appendix – Pem files chapters of this document.
Check SMC API is reachable
-
In the folder where fp-ngfw-aws-TransitGateway-autoscaling.zip was unpacked,run the following command:
chmod +x ApiTest
-
Check config.json and smc.pem are configured correctly. The certifcate’s FQDN must be resolvable with DNS
-
Run the ApiTest with the following command:
./ApiTest
-
The user should see a message similar to the one below if the SMC API can be reached successfully:
Your API Client: 'smc-api-client' can be reached
Deploy Lambda code and CloudFormation Template
Code for AWS Lambda functions must be packed in advanced, before it’s made available to AWS Lambda.
-
On the Linux machine where the file fp-ngfw-aws-TransitGateway-autoscaling.zip was unzipped open a terminal window and navigate to the unzipped directory and run the script named package.sh, this will create 2 files:
-
autoscale-tg-ngfw.json: this is the file that will be uploaded to CloudFormation
-
myDeploymentPackage.zip: this archive will be uploaded to the S3 bucket
-
-
Navigate back to the AWS console and go to the S3 bucket that will be used to store the archive. In the config-smc folder upload myDeploymentPackage.zip.
-
Now search for CloudFormation in the AWS console. Navigate to CloudFormation.
-
The console will look different if you already have a stack created in the region. Select the region you will be deploying to (same as the one used inside the configuration file) using the drop-down menu in the top right of the page. Select Create Stack > With new resources(standard).
-
In the Specify template section choose Upload a template file and then select Choose file. Upload the autoscale-tg-ngfw.json template file created in step 1. Select Next.
-
Enter a name for the stack. Click Next.
-
Scroll to the bottom of the Configure stack options page and select Next.
-
On the Review NGFW-TransitGateway, scroll to the bottom of the page. Tick the box to allow for the necessary requirements. Click Create stack to proceed.
Please note: to prevent unexpected failures in the deployment workflow, the AWS Security Groups are configured in a permissive way allowing both inbound and outbound traffic. This must be changed as soon as deployment is completed, allowing only traffic from intended sources. Outbound traffic should be controlled as well based on existing security policies within the organization.
Configuring Auto-scaling group
-
From the AWS webpage search for EC2
-
Along the left navigation bar select Auto Scaling Groups
-
From this page select the group name that looks like this: xxxxx-NGFWAutoscalingGroup-xxxxx
-
From the group details select the edit button in the top right corner
-
Increase the desired capacity as well minimum capacity and maximum capacity as necessary and click update when finished
Optional, but recommended
The auto-scaling group is deployed without a dynamic scaling policy, this is to give the user flexibility around customizing this. They can be configured in a dew options like Average CPU, network in and network out.
Once the deployment is completed, NGFW engines listed inside the SMC web interface will be displayed with green color within 5 minutes.
Please refer to Appendix – Engine states for more information on the different status colors visible in the SMC UI during the configuration of the NGFW engines.
Troubleshooting
Follow these steps to identify issues impacting the normal operation of the integration described in this document.
Validate the prerequisites
Make sure the prerequisites described in the Summary chapter are all satisfied:
-
Check the versions of Forcepoint NGFW and Forcepoint SMC in use are listed as compatible
Forcepoint NGFW 6.10.x and later Forcepoint SMC 6.10.x and later
-
Verify the integration is operating on an Ubuntu 20.04.1 LTS machine with at least 2 GB RAM and 20 GB free disk space
-
Verify necessary ports are open on the SMC machine to allow SMC API, NGFW engines and IPSEC network traffic (refer to Appendix B of this document)
-
Make sure the user selects the same AWS region for the below steps:
-
Generating the keypair ngfw-tgw-keypair
-
AMI id for Forcepoint NGFW (BYOL) – Next Generation Firewall
-
When creating stack on AWS Cloudformation
-
-
Check the user has downloaded the necessary files from the following location:
https://github.com/Forcepoint/fp-bd-aws-transitgateway-ngfw/releases/latest
Check network connectivity
Make sure firewalls or other security appliances are not impacting the network connectivity necessary for the operation of all components involved in this integration:
-
Check the host Ubuntu machine has internet connectivity: execute the following command on the host machine:
ping -c 2 www.aws.com
Once done check the result is similar to below:
PING www.aws.com (10.10.120.12) 56(84) bytes of data.
64 bytes from 10.10.120.12 (10.10.120.12): icmp_seq=1 ttl=128 time=179 ms
64 bytes from 10.10.120.12 (10.10.120.12): icmp_seq=1 ttl=128 time=181 ms
When testing connection from on-prem to AWS protected network. Make sure that protected network’s subnet has a correct routing to TGW. By default NGFWs announces itself as default gateway to transit gateway.
Check dependencies are installed
Make sure the software dependencies needed by the components involved into this integration are installed:
-
Check python3.8 is installed: Execute following command on host machine:
python3 –version
Check the output is similar to below:
Python 3.8.2
-
Check pip3 is installed: Execute the following command on the host machine:
pip3 –version
Check the output is similar to below:
pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)
Check all components are configured and running properly
Make sure the products and services involved into this integration are configured as expected and they are running:
- Check the AWS Cloudformation stack gets created properly:
Make sure the user sees a CREATE_COMPLETE status for the newly created stack as shown in the picture below:
- Check the NGFW engines are installed properly:
Once the stack creation is successful, within 10 minutes the NGFW engines will be displayed in the SMC UI with green color if all operations were successful:
Appendix – Pem files
There are two .pem files mentioned in this document:
YOUR_AWS_KEY_PAIR.pem | This is the key generated by AWS when the key pair is created. This key is not needed for this integration but should be kept if you ever need to SSH into the EC2 instances. |
Smc.pem | This file is included in the fp-ngfw-aws-TransitGateway-v1. This file will be populated with the certificate created in the SMC in step 12 of the chapter Configure Forcepoint SMC |
Appendix – Configuration File
This table provides a description for the values required in the config file.
Field | Example or Default | Notes | Requires to be changed |
---|---|---|---|
url | https://13.25.14.2:8082 | The public endpoint of the SMC, used for accessing the SMC API from Internet. | Yes |
api_key | abcdefgh1234567 | API key necessary to utilise the SMC API. | Yes |
api_version | 6.10 | Version of the SMC API to be used. Default is 6.8. | No |
region | ap-south-1 | This is the region of AWS you will be using to deploy the CloudFormation template to. | Yes |
availability_zone_1 | ap-south-1a | This is the first availability zone of the AWS region you will be using to deploy the CloudFormation template to. | Yes |
availability_zone_2 | ap-south-1b | This is the second availability zone of the AWS region you will be using to deploy the CloudFormation template to. | Yes |
availability_zone_3 | ap-south-1c | This is the third availability zone of the AWS region you will be using to deploy the CloudFormation template to. | no |
ngfw_ami | ami-021207f5865d6b9a9 | AMI ID of the NGFW EC2 instance you will be deploying with CloudFormation | Yes |
lambda_bucket_name | smc-lambda-bucket | Name of the bucket used to host the AWS Lambda code that will be deployed by the CloudFormation template | Yes |
vpc_network | 100.64.0.0/16 | The VPC subnet where AWS scale group instantiates Forcepoint NGFW VMs | No |
availability_zone_1_subnet | 100.64.1.0/16 | The VPC AZ-1 subnet where AWS scale group instantiates Forcepoint NGFW VMs | No |
availability_zone_2_subnet | 100.64.2.0/16 | The VPC AZ-2 subnet where AWS scale group instantiates Forcepoint NGFW VMs | No |
availability_zone_3_subnet | 100.64.3.0/16 | The VPC AZ-3 subnet where AWS scale group instantiates Forcepoint NGFW VMs | No |
cloud_formation_name_prefix | my-fp-scaleset | The name prefix that is used in CloudFormation when ScaleGroup is created | No |
cloud_formation_name_prefix | my-fp-scaleset | The name prefix that is used in CloudFormation when ScaleGroup is created | No |
logserver_pool | LOGSERVER-01, LOGSERVER-02 | The name of Log servers as comma separated list | No |
location | cloud | The SMC location element for SMC and Log Server | No |
protected_network | 10.0.0.0/8 | The network is that routed locally and not put to VPN | No |
policy_name | transit_gw_policy | The Policy name used for NGFW VMs | No |
Appendix – Engine states
NGFW engines deployed in AWS won’t be displayed on Forcepoint SMC until the CloudFormation stack has been created in full. During the operations of the CloudFormation workflow, engines status will change as the configuration and setup process progresses.
Here is a list of the possible engine statuses, with explanation.
- Engines initial creation: NGFW engines deployed as EC2 instances have been created and have contacted the SMC
-
Engines waiting for configuration and policy upload: NGFW engines are waiting for policy upload after initial contact is completed. At this point the AWS Lambda has not triggered yet: configuration of the engines is the next step.
-
Engines have been configured and policy is being uploaded: At this point the AWS Lambda has been triggered, and policy upload has started.
- Policy has been uploaded: After the policy has finished uploading it will initially look like it has not succeeded. This is state is expected and only temporary: it will change to normal operating status momentarily.
The image above shows the first NGFW engine in an error state (even though the policy has been uploaded) while the second engine is still uploading.
The image below shows the first NGFW engine has completed uploading the policy and is now in normal working status, while the second NGFW engine has now finished receiving the policy and appears in an error state. This state will change to green shortly after, and both engines will display no error.
- Engines are connected and traffic flows without problems: both NGFW engines are connected and there are no errors