Forcepoint Next-Gen Firewall High Availability with Azure Resource Manager
Table of contents
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 | 10 November 2020 | Dlo Bagari | First draft |
0.2 | 11 November 2020 | Mattia Maggioli | Review |
0.3 | 12 November 2020 | Neelima Rai | Added Troubleshooting chapter |
Summary
This guide provides step by step instructions to deploy and configure Forcepoint Next Generation Firewall using a high availability topology (Active-Active mode) in Azure using an Azure Resource Manager (ARM) template to deploy the entire stack.
The code and instructions provided enable system administrators to automatically:
-
Deploy two standalone Forcepoint Next Generation Firewall engines
-
Configure the engines to operte in Active-Active mode and to report to an existing Forcepoint Security Management Center (SMC)
-
Deploy and configure all Azure network components involved in the stack.
The ARM template is designed to deploy and configure the following resources within the Azure account of the user:
-
External Load Balancer (Internet-facing).
-
Internal Load Balancer.
-
Virtual Networks (if not already existing) with 3 subnets: subnet-0-security, subnet-1-front and subnet-2-back.
Subnets subnet-1-front and subnet-2-back are intended for connecting customer’s workloads. -
Two instances of Forcepoint Next Generation Firewall engines either in the same Availability Zone using Availability Sets or into two different Availability Zones.
-
Two NICs one for each Forcepoint Next Generation Firewall engine
-
Azure components instrumental to operate the entire stack: Storage accounts, Route Tables, Security Groups and Public IP addresses
A description of the workflow between the components deployed to Azure in this POC is depicted in this diagram:
Demo
Source Code
Requirements
-
Azure account with active subscription
-
Forcepoint Security Management Center with a public FQDN or IP address
-
A Windows machine with PowerShell (used to convert TLS certificates)
The following activities are out of the scope of this document and therefore left to the system administrator, as part of ordinary maintenance procedures to be put in place within the existing infrastructure.
-
configuration of appropriate hygiene procedures to handle logs produced during any step of the solution workflow
-
monitoring of the scripts, services, and applications involved in the solution
Configure Forcepoint Security Management Center
Create a self-signed certificate for the Forcepoint Security Management Center API
-
Login to your SMC machine.
-
Select Configuration, then browse to Administration.
-
Browse to Certificates > TLS Credentials.
-
Right-click TLS Credentials, then select New TLS Credentials.
-
In the Name field, enter a unique name for the certificate.
-
In the Common Name field, enter the fully qualified domain name (FQDN) or the public IP address that the SMC API service uses.
-
Add the same FQDN or IP address that you entered in the Common Name field as the Subject Alternative Name.
-
Click Edit next to the Subject Alternative Name field.
-
If you have a fully qualified domain name (FQDN): click Add, select DNS from the drop-down list in the Type cell, double-click Value cell, then enter the FQDN.
-
If you use a public IP address to access the SMC API: click Add, select IP address from the drop-down list in the Type cell, double-click Value cell, then enter the public IP address for SMC API connections
-
-
From the signing options, select Self-Sign then click Finish.
-
Right-click the certificate element just created in the above steps, then select Properties.
-
On the Certificate tab, click Export, then save the certificate file. Click OK.
-
Convert the exported certificate to base64 string using any Windows machine with Windows PowerShell ISE
-
Open Windows PowerShell ISE and load the content of the exported certificate into a variable, replacing the red text with the path to the exported certificate, using the following command:
$pfx_cert = get-content 'C:\Users\Demo\Downloads\certificate1604078668615.crt' -Encoding Byte
-
Convert the exported certificate to Base64 string using the following command:
[System.Convert]::ToBase64String($pfx_cert)
-
Save the output of the above command in a secure location, since it will be needed in the next steps described in this document.
Enable the SMC API
-
Go back to the SMC portal. Select Home, then browse to Others > Management Server.
-
Right-click the Management Server, then select Properties.
-
On the SMC API tab, select Enable.
-
In the Host Name field, enter the FQDN or public IP address for SMC that is used in the certificate for the SMC API.
-
Click Select next to the Server Credentials, then select the TLS Credentials element that contains the certificate you have created for the SMC API.
-
Click OK, and Yes.
Create an SMC API Client.
-
Select Configuration, then browse to Administration.
-
Browse to Access Rights.
-
Right-click API Clients then select New API Client.
-
In the Name field, enter a name for the API Client element.
-
Use the automatically generated authentication key or click Generate Authentication Key to generate a new one. This key appears only once, so make sure to save the value in the Authentication Key field in a secure location since it will be needed in the next steps described in this document.
-
On the Permissions tab, select Unrestricted Permissions (Superuser).
-
Select Configuration, then browse to Administration.
-
Click OK.
Create a Location element for elements that contact the SMC servers.
-
Select Configuration, then browse to Administration.
-
Browse to Other Elements > Locations.
-
Right-click Locations, then select New Location.
-
Enter a name in the Name field.
-
Click OK.
Configure Management Server
-
Select Home, then browse to Others > Management Server.
-
Right-click the Management Server, then select Properties.
-
In the Default field within the Contact Addresses section, enter the default contact address for the Management Server
-
For NGFW 6.4, enter the external (public) IP address of the Management Server.
-
For NGFW 6.5 and higher, enter the internal IP address of the Management Server.
-
-
Click Exceptions > Add, select the Location element that you created, then click Select.
-
In the Contact Addresses cell, enter the IP address then click OK.
-
For NGFW 6.4, enter the internal IP address of the Management Server
-
For NGFW 6.5 and higher, enter the external (public) IP address of the Management Server.
-
-
Click OK to close the Management Server Properties dialog box and then click Yes.
Configure Log Server
-
Browse to Others > Log Server, right-click Log Server, then select Properties.
-
In the Default field in the Contact Addresses section, enter the default contact address for the Log Server.
-
For NGFW 6.4, enter the external IP address of the Log Server.
-
For NGFW 6.5 and higher, enter the internal IP address of the Log Server.
-
-
To configure contact address exceptions for the Log Server, click Exceptions.
-
Click Add, select the Location element that you created, then click Select.
-
In the Contact Addresses cell, enter the IP address, then click OK.
-
For NGFW 6.4, enter the internal IP address of the Log Server.
-
For NGFW 6.5 and higher, enter the external IP address of the Log Server.
-
-
Click OK to close the Log Server Properties dialog box and then click Yes.
Create Firewall Policy
Skip this section if your existing Security Management Center already has one Firewall Policy that you’d like to apply to the two engines deployed in Azure.
To create a Firewall Policy:
-
Select Configuration > NGFW > Policies.
-
Right-click Policies and select New > Firewall Policy.
-
Give a name to your Firewall policy
-
Select Firewall Template
-
Click OK
Configure Azure and deploy the template
Step 1: Create Azure Resource Group for Forcepoint NGFW HA
-
Sign into the Azure portal at the link https://portal.azure.com/.
-
Click Resource groups
-
Click Add.
-
Enter the following values:
-
Subscription: select your Azure subscription.
-
Resource group: enter a new resource group name
-
Region: select an Azure location
-
-
Click Review + Create
-
Click Create. It takes a few seconds to create a Resource Group.
Step 2: Download Forcepoint NGFW HA ARM Template
-
Download fp-ngfw-ha-arm-template.tar.gz from https://frcpnt.com/fp-ngfw-ha-arm-template-latest
-
Decompress fp-ngfw-ha-arm-template.tar.gz with the following command:
tar -zxvf fp-ngfw-ha-arm-template.tar.gz
The output of the above command is a directory named fp-ngfw-ha-arm-template which contains two .json files:
-
fp-ngfw-ha-template.json
-
fp-gfw-ha.parameters.json
Step 3: Edit and deploy the templateto Azure Resource Management
-
From the search box in the Azure portal menu, type deploy then select Deploy a custom template.
-
Select Build your own template in the editor.
-
Select Load file, and then follow the instructions to load fp-ngfw-ha-template.json downloaded in step two of this section.
-
Click Save
-
Select Edit parameters
-
Select Load file, and then follow the instructions to load fp-ngfw-ha-parameters.json downloaded in step two of this section. Do not click Save after uploading the parameter file.
-
Once you have loaded the parameter file into parameters editor, edit the following parameters:
-
Line 6: Parameters.location.value: the name of the Azure Region where the resources will be deployed. For example:
-
Line 9: Parameters.engineUsername.value: username that will be used to login into Forcepoint NGFW engine VMs.
For example:
-
Line 12: parameters.sshkey.value: NGFW engine username public ssh key. To find more about how to generate ssh keys, visit: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mac-create-ssh-keys. For example:
-
parameters.vnet: these parameters represent the Virtual Network (VNet) for the deployment. If the VNet does not exist it will be created. User needs to
-
specify the name for the VNet and its Resource Group
-
if the VNet exists, change the value vnet.value.newOrExisting to existing and modify the other VNet addressPrefix and subnets names parameters to not overlap with existing subnets adressPrefix.
-
line 45: parameters.sku.value: choose the type of NGFW licensing model. Options are
-
Pay as you go: enter the value ngfw_payg
-
Bring your own license: enter the value ngfw_byol. If this option is used, the NGFW engines will pull a license from the ones available in the SMC.
-
-
Line 48: parameters.ImageVersion.value: the version for the Forcepoint NGFW engine image. Available versions can be identified as explained in the Appendix A of this document.
-
Line 51: parameters.engineVMSize.value: the size of the Azure VM. The size must be available in the Azure region selected for the deployment.
-
Line 57: parameters.smcContactAddress.value: enter the public IP address or FQDN of the SMC API.
-
Line 63: parameters. smcContactApikey.value: enter the SMC API key generated in the section Enable the SMC API.
-
Line 69: Parameters.smcCertificate.value: enter the Bas64 string for the certificate created in the section Create a self-signed certificate for the SMC API of this document.
-
Line 72: parameters.ploicyName.value: enter the Policy name created in the section Create Firewall Policy of this document
-
Line 78: parameters.engineLocation.value: enter the engine Location name created in the section Create a Location element for elements that contact the SMC servers.
-
Line 81: parameters.logServerPool.value: the name of the Log Servers as displayed inside Forcepoint Security Management Center.
-
Line 86: parameters.useZones.value: set true to use Availability Zones of Azure.
Not all Azure locations provide Availability Zones. Set this to false if the stack is deployed in a location that does not support Availability Zones: Availability Set will be used instead to deploy both NGFW engines in the same datacentre within different fault domains and update domains.
-
If parameters.useZones.value is set to true, then you need to choose two different availability zones, one for each Forcepoint NGFW engine instance.
For example, to choose availability zones 1 and 2:
-
Once all parameters are defined, click Save to save all changes made to the parameters file.
![](./media/image30.png)
-
-
Select the Resource group you have created
-
Click Review + create
-
Click Create to start the deployment
The deployment may take up to 5 to 10 minutes to finish.
Once deployment is completed, two NGFW Engines will be displayed inside Forcepoint SMC.
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:
-
Forcepoint Security Management Center with a public FQDN or IP address
-
A Windows machine with PowerShell (used to convert TLS certificate).
-
Check the user can download the file with the below command:
wget –content-disposition https://frcpnt.com/fp-ngfw-ha-arm-template-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 machine used for downloading the file has connectivity to the internet: execute the following command on the machine:
ping -c 2 <SMC public IP here>
Once done check the result is similar to below:
PING <SMC public IP> (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
Check all components are configured and running properly
Make sure the products and services involved in this integration are configured as expected and they are running:
-
Verify the Azure deployment completed with no errors. It should complete within 10 minutes:
Once deployment is completed, two NGFW Engines will be displayed inside Forcepoint SMC. Validate the network configuration of the newly deployed stack as described in the Appendix B - End to end test.
Appendix A – How to find NGFW Engine versions available in Azure
-
Sign into the Azure portal at the link https://portal.azure.com/.
-
In the search bar on top of the portal enter Marketplace and click it once displayed in the results.
-
In the search bar of the Marketplace type Forcepoint Next and click Forcepoint Next Generation Firewall
-
Click the tile named Forcepoint Next Generation Firewall, select Forcepoint single NGFW then click Create.
-
Without entering and values, switch to NGFW Configuration step of the creation wizard and click in the drop-down menu name NGFW Engine version: this will display all available NGFW versions that can be deployed with the Azure Resource Manager template
Appendix B – End to end test
To ensure you have done all the steps currently and the two Forcepoint NGFW Engines are working fine, follow the following steps to create a test bed.
-
Create a Windows Server 16 machine in the subnet-1-front subnet.
-
In the Azure portal search for Virtual Machines, and select Virtual machines.
-
Click Add and select Virtual machine
-
Select a Resource Group for this Virtual Machine
-
Virtual machine name: give a name to this virtual machine
-
For Region, select the Azure region where you have deployed the ARM template.
-
For Image: select a Windows Server 2016 image
-
In the Administrator account section: enter a username and a password, saving both in a secure location since they will be needed at a later time.
-
In the Inbound port rules section, select None for Public inbound ports.
-
Click Next: Disk
-
Click Next: Networking
-
Select the Virtual network used (or created if not already existing) by the ARM template
-
Select the subnet subnet-1-front
-
For the public IP: select None
-
Click Review + Create
-
Click Create
It will take 2-3 minutes to create the VM
-
-
Add a rule to the External Load Balancer to forward the RDP traffic to its Backend pool
-
In the Azure portal search for Load Balancers and select it.
-
Click the External Load Balancer which has been created by the ARM template (the load balancer which ends with -externallb)
-
Under the Setting section, click Load balancing rules
-
Click Add
-
Give a name to this rule.
-
For Port: add 3389
-
For Backend Port add: 3389
-
Click OK to save the rule
-
-
Add a rule to the Firewall Policy used with the Forcepoint NFGW engines to allow RDP to the Windows Server 2016 you have created.
-
Login to your Forcepoint SMC
-
Select Configurations > Policies > Firewall policies and find the policy used in the ARM template.
-
Right-click on your policy name and select Edit Firewall Policy ….
-
Click Yes
-
Add a new Rule
-
For testing purposes over a limited time period only, allow all traffic for IPv4 Access from any source to any destination with any service. Do not do this in a production environment, define the firewall rule with specific source IPs instead, so that only the intended user testing the deployment will have access via Remote Desktop to the Windows Server 2016 machine hosted in Azure.
-
Click IPv4 NAT
-
Set Source to ANY
-
Set Destination to $$ DHCP Interface 1.ip
-
Set Service to any
-
Right-click NAT and select Edit NAT
-
Configure Source Translation as per this screenshot:
-
Click Destination Translation, select Translate Type as Translate Destination.
-
Click Translate Destination.
-
Click on Address, enter the private IP address of the Windows Server 2016 VM you have created, and click OK.
-
The configuration for Translate Destination would look like in the screenshot below:
-
The final configuration for IPv4 NAT will look as in the screenshot below:
-
Click the Save and install icon: this will deploy the policy to both Forcepoint NFGW Engine instances on Azure.
-
-
Login to the Windows Server 2016 using Remote Desktop.
-
On any Windows machine, search for Remote Desktop Connection.
-
Enter the DNS name or the public IP address of the External Load Balancer and click Connect.
If all configuration settings are corect, you will be asked to enter the credentials to login to the Windows Server 2016 machine.
-