FortiOS 6.4 AWS Cookbook
FortiOS 6.4 AWS Cookbook
Version 6.4
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://fortiguard.com/
FEEDBACK
Email: techdoc@fortinet.com
By combining stateful inspection with a comprehensive suite of powerful security features, FortiGate Next Generation
Firewall (NGFW) technology delivers complete content and network protection. This solution is available for deployment
on AWS.
In addition to advanced features such as an extreme threat database, vulnerability management, and flow-based
inspection, features including application control, firewall, antivirus, IPS, web filter, and VPN work in concert to identify
and mitigate the latest complex security threats.
The security-hardened FortiOS operating system is purpose-built for inspecting and identifying malware and supports
direct Single Root I/O Virtualization (SR-IOV) for higher and more consistent performance.
FortiGate-VM for AWS supports active/passive high availability (HA) configuration with FortiGate-native unicast HA
synchronization between the primary and secondary nodes. When the FortiGate-VM detects a failure, the passive
firewall instance becomes active and uses AWS API calls to configure its interfaces/ports.
FortiGate-VM also supports active/active HA using elastic load balancing, as well as auto scaling.
Highlights of FortiGate-VM for AWS include the following:
l Delivers complete content and network protection by combining stateful inspection with a comprehensive suite of
powerful security features.
l IPS technology protects against current and emerging network-level threats. In addition to signature-based threat
detection, IPS performs anomaly-based detection, which alerts users to any traffic that matches attack behavior
profiles.
l New Docker application control signatures protect your container environments from newly emerged security
threats. See FortiGate-VM on a Docker environment.
FortiGate-VM supports the following instance types on AWS. Supported instances in the AWS marketplace listing may
change without notice and vary between bring your own license (BYOL) and on-demand models. See Order types on
page 11. As of May 2018, C3 and M-series instances no longer appear as recommended instances.
When you run FortiGate-native active-passive HA, each FortiGate-VM instance requires four network interfaces (port 1
to port 4). For details, see Deploying FortiGate-VM active-passive HA on AWS within one zone on page 115.
For up-to-date information on each instance type, see the following links:
l Amazon EC2 Instance Types
l Elastic Network Interfaces
C5.18xlarge 72 15
You can apply a smaller FortiGate-VM license if you are OK with consuming less CPU than is present on your instance.
See Models on page 9.
To change your instance type to the recommended C5 instance type, ensure that ENA is enabled. Otherwise the
instance does not boot up properly.
In the following example, after changing the instance type to C5, ENA is not enabled. The example shows changing the
ENA support attribute to true:
$ aws ec2 describe-instances --instance-ids i-xxxxxxx --query "Reservations[].Instances
[].EnaSupport"
[]
$ aws ec2 modify-instance-attribute --instance-id i-xxxxxxx --ena-support
$ aws ec2 describe-instances --instance-ids i-xxxxxxx --query "Reservations[].Instances
[].EnaSupport"
[
true
]
BYOL and on-demand deployments support the following regions. See Order types on page 11.
Instance support may vary depending on the regions.
For details about regions, see Regions and Availability Zones.
EU (Frankfurt) eu-central-1
EU (Ireland) eu-west-1
EU (London) eu-west-2
EU (Paris) eu-west-3
EU (Stockholm) eu-north-1
AWS China is supported but does not appear with these regions when you log into the AWS portal. To use AWS
resources on AWS China, you must have an AWS China account separate from your global AWS account.
FortiGate-VM for AWS China only supports the BYOL licensing model. To activate it, you must obtain a license. See
Deploying on AWS China on page 30.
FortiGate-VM is available with different CPU and RAM sizes. You can deploy FortiGate-VM on various private and
public cloud platforms. The following table shows the models conventionally available to order, also known as BYOL
models. See Order types on page 11.
Minimum Maximum
FG-VM01/01v/01s 1 1
FG-VM02/02v/02s 1 2
FG-VM04/04v/04s 1 4
FG-VM08/08v/08s 1 8
FG-VM16/16v/16s 1 16
FG-VM32/32v/32s 1 32
FG-VMUL/ULv/ULs 1 Unlimited
The v-series and s-series do not support virtual domains (VDOMs) by default. To add VDOMs,
you must separately purchase perpetual VDOM addition licenses. You can add and stack
VDOMs up to the maximum supported number after initial deployment.
Generally there are RAM size restrictions to FortiGate-VM BYOL licenses. However, these restrictions are not
applicable to AWS deployments. Any RAM size with certain CPU models are allowed. Licenses are based on the
number of CPUs only.
Previously, platform-specific models such as FortiGate-VM for AWS with an AWS-specific orderable menu existed.
However, the common model is now applicable to all supported platforms.
For information about each model's order information, capacity limits, and adding VDOMs, see the FortiGate-VM
datasheet.
The primary requirement for the provisioning of a FortiGate-VM may be the number of interfaces it can accommodate
rather than its processing capabilities. In some cloud environments, the options with a high number of interfaces tend to
have high numbers of vCPUs.
The licensing for FortiGate-VM does not restrict whether the FortiGate can work on a VM instance in a public cloud that
uses more vCPUs than the license allows. The number of vCPUs indicated by the license does not restrict the
FortiGate-VM from working, regardless of how many vCPUs are included in the virtual instance. However, only the
licensed number of vCPUs process traffic and management. The rest of the vCPUs are unused.
The following shows an example for a FGT-VM08 license:
You can provision a VM instance based on the number of interfaces you need and license the FortiGate-VM for only the
processors you need.
Order types
On AWS, there are usually two order types: BYOL and on-demand.
BYOL offers perpetual (normal series and v-series) and annual subscription (s-series) licensing as opposed to on-
demand, which is an hourly subscription available with marketplace-listed products. BYOL licenses are available for
purchase from resellers or your distributors, and the publicly available price list, which is updated quarterly, lists prices.
BYOL licensing provides the same ordering practice across all private and public clouds, no matter what the platform is.
You must activate a license for the first time you access the instance from the GUI or CLI before you can start using
various features.
With an on-demand subscription, the FortiGate-VM becomes available for use immediately after you create the
instance. The marketplace product page mentions term-based prices (hourly or annual).
For BYOL and on-demand deployments, cloud vendors charge separately for resource consumption on computing
instances, storage, and so on, without use of software running on top of it (in this case the FortiGate-VM).
For BYOL, you typically order a combination of products and services including support entitlement. New s-series SKUs
contain the VM base and service bundle entitlements for easier ordering. On-demand includes support, for which you
must contact Fortinet Support with your customer information. See Support Information on the marketplace product
page.
To purchase on-demand, all you need to do is subscribe to the product on the marketplace. However, you must contact
Fortinet Support with your customer information to obtain support entitlement. See Creating a support account on page
12. For the latest on-demand pricing and support details, see the FortiGate-VM on-demand marketplace product page.
On-demand FortiGate-VM instances do not support the use of virtual domains (VDOMs). If
you plan to use VDOMs, deploy BYOL instances instead.
On-demand and BYOL licensing and payment models are not interchangeable. For example,
once you spin up a FortiGate-VM on-demand instance, you cannot inject a BYOL license on
the same VM. Likewise, you cannot convert a FortiGate-VM BYOL instance to on-demand.
When using a FortiGate-VM on-demand instance prior to version 6.4.2, the FortiOS GUI may display expiry dates for
FortiGuard services. However, these expiries are automatically extended for as long as the on-demand instance's
lifespan. You do not need to be concerned about the expiry of FortiGuard services. For example, the following
screenshot shows 2038/01/02.
FortiGate-VM for AWS supports on-demand and BYOL licensing models. See Order types on page 11.
To make use of Fortinet technical support and ensure products function properly, you must complete certain steps to
activate your entitlement. The Fortinet support team can identify your registration in the system thereafter.
First, if you do not have a Fortinet account, create one at Customer Service & Support.
BYOL
You must obtain a license to activate the FortiGate-VM. If you have not activated the license, you will see the license
upload screen when you log in to the FortiGate-VM and cannot proceed to configure the FortiGate-VM.
You can obtain licenses for the BYOL licensing model through any Fortinet partner. If you do not have a partner, contact
awssales@fortinet.com for assistance in purchasing a license.
After you purchase a license or obtain an evaluation license (60-day term), you receive a PDF with an activation code.
1. Go to Customer Service & Support and create a new account or log in with an existing account.
2. Go to Asset > Register/Activate to start the registration process.
On-demand
1. Deploy and boot the FortiGate-VM on-demand Elastic Compute Cloud (EC2) instance and log into the FortiGate-
VM GUI management console.
2. From the Dashboard, copy the FortiGate-VM serial number.
3. Go to Customer Service & Support and create a new account or log in with an existing account.
4. Go to Asset > Register/Activate to start the registration process.
5. In the Registration page, enter the serial number, and select Next to continue registering the product. Enter your
details in the other fields.
6. After completing registration, contact Fortinet Customer Support and provide your FortiGate instance's serial
number and the email address associated with your Fortinet account.
FortiGate-VM AWS on-demand instances can obtain FortiCare-generated licenses and register to FortiCare.
The valid license allows you to register to FortiCare to use features including FortiToken with the FortiGate-VM
instance.
The FortiGate-VM must be able to reach FortiCare to receive a valid on-demand license. Ensure connectivity to
FortiCare (https://directregistration.fortinet.com/) by checking all related setup on security groups, access control lists,
Internet gateways, route tables, public IP addresses, and so on.
If you created the FortiGate-VM in a closed environment or it cannot reach FortiCare, the FortiGate-VM self-generates
a local license as in previous versions of FortiOS. You can obtain a FortiCare license, ensure that the FortiGate-VM is
able to connect to FortiCare, then run the execute vm-license command to obtain the license from FortiCare.
When deploying a FortiGate-VM on-demand instance for AWS, you will use the FGT_VM64_AWS-v6-buildXXXX-
FORTINET.out image. After deployment with this image, running get system status results in output that
includes the following lines:
Version: FortiGate-VM64-AWS v6.2.2,buildXXXX,XXXXXX (GA)
Virus-DB: 71.00242(2019-08-30 08:19)
Extended DB: 1.00000(2018-04-09 18:07)
To upgrade a FortiGate-VM AWS on-demand instance from FortiOS 6.2.1 and earlier to 6.2.2:
3. Run get system status results in output that includes the following lines:
Version: FortiGate-VM64-AWS v6.2.2,buildXXXX,XXXXXX (GA)
Virus-DB: 71.00246(2019-08-30 12:19)
Extended DB: 1.00000(2018-04-09 18:07)
Extreme DB: 1.00000(2018-04-09 18:07)
IPS-DB: 14.00680(2019-08-30 02:29)
IPS-ETDB: 0.00000(2001-01-01 00:00)
APP-DB: 14.00680(2019-08-30 02:29)
INDUSTRIAL-DB: 14.00680(2019-08-30 02:29)
Serial-Number: FGTAWS1234567890
4. For future upgrades, use the FGT_VM64_AWS-v6-buildXXXX-FORTINET.out image to retain on-demand status.
You cannot directly upgrade a FortiGate-VM AWS on-demand instance from 6.2.1 or earlier to 6.2.3 and later
versions. You must first follow the procedure detailed above.
When deploying a FortiGate-VM on public cloud, you determine the license type (on-demand or BYOL) during
deployment. The license type is fixed for the VM's lifetime. The image that you use to deploy the FortiGate-VM on the
public cloud marketplace predetermines the license type.
1. Connect to the FortiOS GUI or CLI and back up the configuration. See Configuration backups.
2. Deploy a new FortiGate-VM instance with the desired license type. If deploying a BYOL instance, you must
purchase a new license from a Fortinet reseller. You can apply the license after deployment via the FortiOS GUI or
bootstrap the license and configuration during initial bootup using custom data as described in Bootstrapping the
FortiGate-VM at initial bootup using user data on page 21.
3. Restore the configuration on the FortiGate-VM instance that you deployed in step 2. As with the license, you can
inject the configuration during initial bootup. Alternatively, you can restore the configuration in the FortiOS GUI as
described in Configuration backups.
4. If you deployed an on-demand instance in step 2, register the license. To receive support for an on-demand
license, you must register the license as described in Creating a support account on page 12.
The most basic deployment consists of one FortiGate-VM with two elastic network interfaces (ENIs) facing a public
subnet and private subnet, with the FortiGate-VM deployed inline between the two subnets. A single FortiGate-VM
protects a single virtual private cloud (VPC) with a single availability zone (AZ). The public subnet's default gateway is an
AWS Internet gateway, and the FortiGate-VM's private subnet-facing ENI is the private subnet's default gateway.
Protected EC2 instances such as web servers, database servers, or other endpoints are assumed to exist in the private
subnet. One elastic/public IP address or IPv4 DNS name must be allocated to the FortiGate-VM in the public subnet for
you to access the FortiGate-VM remotely via HTTPS or SSH over the Internet for initial configuration.
General AWS security best practices can be found at AWS Security Best Practices.
In addition to following the general AWS guidelines, there are best practices to follow when deploying FortiGate-VM for
AWS.
By default, when you deploy FortiGate-VM, there is a predefined security group that you can select based on Fortinet's
recommendation. The following ports are allowed in the predefined security group assuming immediate and near-future
needs.
Protocol/ports Purpose
TCP 80 HTTP
TCP 3000 Not immediately required, but typically used for incoming
access to web servers, and so on
TCP 8080
Outgoing Any
FortiGate-specific open ports are explained in Fortinet Communication Ports and Protocols.
To configure bare-minimum access that gives the most strict incoming access, allow only TCP 443 to access the
FortiGate-VM GUI console as mentioned in Connecting to the FortiGate-VM on page 98 and close all other ports. You
may want to allow ICMP for pinging, and so on, as needed.
Administrative access
This is rather an ordinary consideration than AWS-specific to secure the FortiGate-VM and protect it by configuring
allowed and restricted protocols and ports in corporate security scenes.
One example is to configure the local admin access to one of the FortiGate-VM's local network interfaces. Log into the
GUI, go to Network > Interfaces, then chose the desired port to configure under Administrative Access.
To configure general firewall policies to protect VMs in the networks, refer to Setting up a Windows Server in the
protected network on page 101 or the FortiOS documentation for details.
IAM roles
To deploy FortiGate-VM on the marketplace, you must log into the AWS portal as an AWS user. Your organization's
administrator may have granted permissions via certain IAM roles. AWS security best practices explain when and in
what use cases you need IAM roles. How you manage IAM users and roles is up to your organization.
When deploying FortiGate-VM on marketplace web or EC2 console, your AWS account must have appropriate
permissions, including being able to subscribe to AWS resources through the marketplace, access EC2 resources,
browse AWS resource groups, and so on.
Login credentials
By default, you can log into the FortiGate-VM through HTTPS or SSH using the username "admin" and the FortiGate-
VM's instance ID as the initial password. SSH also requires your AWS key.
The instance ID is relatively secure as it is visible only within the AWS portal or by running the AWS CLI. However, it
may be viewable to those who have access to AWS resources but should not have access to the FortiGate-VM within
the same organization. It is strongly recommended to change the initial password the first time you log in or activate the
license. You can also create other administrative users using more complex character strings than "admin" in a manner
difficult to guess, or add two-factor authentication or other methods to secure login.
FortiGate-VM for AWS is an Elastic Compute Cloud (EC2) instance with an Elastic Block Store (EBS) volume attached.
The following lists AWS services and components that you must understand when deploying FortiGate-VM for different
purposes:
Service/component Description
Virtual private cloud (VPC) This is where the FortiGate-VM and protected VMs are situated and users control
the network. The public-facing interface is routed to the Internet gateway, which
is created within the VPC.
EC2 FortiGate-VM for AWS is an EC2 VM instance. Every instance has a unique
instance ID.
Subnets, route tables You must appropriately configure FortiGate-VM with subnets and route tables to
handle traffic.
Internet gateways The AWS gateway as a VPC component that allows communication between
instances in your VPC and the Internet.
Elastic IP address (EIP) At least one public IP address must be allocated to the FortiGate-VM to access
and manage it over the Internet.
Security groups AWS public-facing protection. Allow only necessary ports and protocols.
AMI A special type of deployable image used on AWS. You can launch FortiGate-VM
(BYOL) directly from the publicly available FortiGate AMI instead of using the
marketplace. See Deploying from BYOL AMI on page 26.
The on-demand AMI is launchable but does not allow you to properly boot up as it
is not intended to be deployed from AMI.
CloudFormation Templates FortiGate instances can be deployed using CFTs where tailor-made resource
(CFT) instantiation is defined. Fortinet provides CFTs for the following use cases:
l Deploying FortiGate-native A-P HA
Service/component Description
Auto Scaling Auto scaling can automatically scale out by instantiating additional FortiGate-VM
instances at times of high workloads. See Deploying auto scaling on AWS on
page 39.
To run auto scaling, you must enable/subscribe to coexisting AWS services:
l Route 53
l API gateway
l Load Balancer
l CloudWatch
l Lambda
l SNS
l DynamoDB
These services are not always required for AWS auto scaling in general, but are
predefined in Fortinet-provided Lambda scripts.
Load Balancer Also called Elastic Load Balancer (ELB). A network load balancer automatically
distributes traffic across multiple FortiGate-VM instances when configured
properly. Topologies will be different depending on how you distribute incoming
and outgoing traffic and cover AZs. There are two use cases to use LB with
FortiGate-VM:
l Deploying and configuring ELB-based HA/load balancing on page 104
l Used in conjunction with auto scaling. See Deploying auto scaling on AWS
on page 39.
Monitoring
Service/component Description
CloudWatch Monitoring service for various AWS resources. You can use CloudWatch in three
scenarios with FortiGate-VM:
l Monitor FortiGate-VM instance health and alert when needed.
Service/component Description
Lambda AWS Lambda lets you run certain scripts and codes without provisioning servers.
Fortinet provides Lambda scripts for:
l Running auto scaling
Service/component Description
l GuardDuty integration
API Gateway It acts as a front door by providing a callback URL for the FortiGate-VM to send
its API calls and process FortiGate-VM config-sync tasks to synchronize OS
configuration across multiple FortiGate-VM instances at the time of auto scaling
scale-out. It is required if the config-sync feature needs to be incorporated into
auto scaling.
If you are installing and configuring your applications on Amazon EC2 dynamically at instance launch time, you will
typically need to pull and install packages, deploy files, and ensure services are started. The following bootstrapping
instructions help simplify, automate, and centralize FortiGate-VM NGFW deployment directly from the configuration
scripts stored in AWS S3. This is also called "cloud-init".
IAM roles need S3 bucket read access. This example applies the existing AmazonS3ReadOnlyAccess policy to the role
by adding the following code or selecting S3ReadOnlyAccess from the policy list in adding to the role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
If you need further instructions, please refer to the AWS documentation on IAM Roles for Amazon EC2.
1. On the AWS console, create an Amazon S3 bucket at the root level for the bootstrap files.
2. Upload the license file and configuration file(s) to the S3 bucket. In this example, one license file and two
configuration files are uploaded. For example, let's have the following FortiOS CLI command statement in the
config file:
config sys global
set hostname jkatocloudinit
end
This is to set a hostname as part of initial configuration at first-time launch.
3. Amazon S3 creates the bucket in a region you specify. You can choose any AWS region that is geographically close
to you to optimize latency, minimize costs, or address regulatory requirements. To choose a region, use the
following code:
{
"bucket" : "jkatoconf",
"region" : "us-east-2",
"license" : "/FGVM020000130370.lic",
"config" : "/fgtconfig-init.txt"
}
Although the S3 bucket and the firewall can be in different regions, it is highly recommended that they are in the
same region in order to speed up the bootstrapping process.
Follow the normal procedure to launch the instance from the AWS marketplace.
When selecting the VPC subnet, the instance must with the role that was created and specify the information about the
license file and configuration file from the AWS S3 bucket previously configured under Advanced Settings. In this
example, the role name is jkato-ec2-s3.
After you launch the FortiGate-VM for the first time and log into the management GUI, FortiOS validates the license
instead of displaying the license upload prompt.
After logging in, you can see that the license was activated and that the specified hostname was configured.
Check the serial number that you have with the license.
You can view the cloud-init log in Log & Report > System Events.
You can deploy FortiGate-VM outside the marketplace launcher if you want to install it manually from the AMI for some
reason, such as if your organization does not allow access to the AWS marketplace website. There are AMI images
publicly available in various regions for the versions already listed in the marketplace. This deployment works only with
AMI for BYOL licensing. Deploying from AMI designed for on-demand is not supported.
If you want to install the latest FortiGate-VM versions immediately after release from Fortinet but you do not see them
published in the marketplace or publicly available in the AWS portal, you can always deploy older versions of FortiGate-
VM available on the marketplace or the AWS portal as publicly available AMIs, then upgrade using the ".out" upgrade
files, which are available at Customer Service & Support.
b. Find the desired public AMI from the list of AMI IDs corresponding to your region.
7. Click Next: Add Tags. You can add tags for convenient management.
8. Click Next: Configure Security Groups. Here it is important to allow some incoming ports. Allow TCP port 8443 for
management from the GUI. You can also allow TCP port 22 for SSH login. Allow other ports where necessary as
noted. The use of ports is explained in the FortiOS documentation.
22 SSH
10443 SSLVPN
9. Click Review and Launch. If everything looks good, go to next by clicking Launch.
10. Then select the appropriate keypair, then click Launch Instance. It may take 15 to 30 minutes to deploy the
instance. To access the FortiGate and complete post-install setup, see Connecting to the FortiGate.
Deploying FortiGate-VM for AWS China has separate requirements than deploying FortiGate-VM for global AWS. To
use AWS resources on AWS China, you must have an AWS China account separate from your global AWS account.
FortiGate-VM for AWS China only supports the BYOL licensing model. To activate it, you must obtain a license.
Complete the following steps to deploy FortiGate-VM on AWS China:
1. Creating a support account on page 12
2. Creating a VPC and subnets on page 31
3. Attaching the new VPC Internet gateway on page 31
This section shows you how to create an AWS VPC and create two subnets in it. For many steps, you have a choice to
make that can be specific to your own environment.
1. Change your language to English and log into the AWS Management Console.
2. Go to Services > Networking > VPC.
3. Go to Virtual Private Cloud > Your VPCs, then select Create VPC.
4. In the Name tag field, set the VPC name.
5. In the CIDR block field, specify an IPv4 address range for your VPC.
6. In the Tenancy field, select Default.
7. Select Yes, Create.
8. Go to Virtual Private Cloud > Subnets, then select Create Subnet. Create a public subnet (in this example,
Subnet1) and a private subnet (Subnet2), as shown in this example. Both subnets belong to the VPC that you
created.
This section shows how to connect the new VPC to the Internet gateway. If you are using the default VPC, the Internet
gateway should already exist.
1. Go to Virtual Private Cloud > Internet Gateways, then select Create internet Gateway.
2. In the Name tag field, set the Internet gateway name, then select Create.
1. In the Services-EC2 Dashboard, go to INSTANCES > Instances, then select Launch Instance.
2. Select AWS Marketplace. Search for FortiGate. Click Select.
3. Select an instance type, then select Next: Configure Instance Details.
4. Configure the instance details:
a. In the Network field, select the VPC you created.
b. In the Subnet field, select the public subnet.
c. In the Network interfaces section, you see the entry for eth0 that was created for the public subnet. Select
Add Device to add another network interface (in this example, eth1), and select the private subnet.
d. When you have two network interfaces, a global IP address is not assigned automatically. You must manually
assign a global IP address later. Select Review and Launch, then select Launch.
e. Select an existing key pair or create a new key pair. Select the acknowledgment checkbox. Select Launch
Instances.
f. To easily identify the instance, set a name for it in the Name field.
g. Go to NETWORK & SECURITY > Elastic IPs, select a global IP address that is available for use. Select
Actions > Allocate new address. If you do not have a global IP address available to use, create one.
Network interfaces section in the lower pane of the page (Interface ID and Private IP Address fields). Select
Associate. A message is displayed indicating the address association was successful. Note that if the Internet
Gateway isn't associated with a VPC, the elastic IP assignment will fail.
To connect to the FortiGate-VM, you need your login credentials, the FortiGate-VM's EIP, SSH client, and an FTP
server.
The default username is admin and the default password is the instance ID.
1. You can find the public IP address in the EC2 management console. Select Instances and look at the Public IP
field in the lower pane.
2. Each public IP address in China should obtain an ICP license. Otherwise it cannot be visited by ports 80, 443, and
8080. You cannot initially access the FortiGate-VM web GUI via the default HTTPS port. You can access the
FortiGate-VM via SSH, then upload a BYOL license to the FortiGate-VM via FTP or TFTP. After activating the
FortiGate-VM, you can modify the default admin HTTPS port to any port, such as 8443. Then you can go to the
FortiGate-VM via https://<FortiGate-VM EIP>:8443.
3. Set up an FTP/TFTP server and ensure the FortiGate can log onto and download a BYOL license from it.
4. On the FortiGate, use one of the following CLI commands to restore the VM license.
exec restore vmlicense tftp <license file name> <IP address>
exec restore vmlicense ftp <license name (path) on the remote server> <ftp server address>
[:ftp port]
If the license installation is successful, the FortiGate-VM reboots automatically. After it restarts, log in.
5. Change the default port to any port, such as 8443. Do not use ports 443, 8080, or 80.
6. You will now see the FortiGate-VM dashboard. Depending on your license type, the information in the license
widget on the dashboard may vary.
7. Select Network > Interfaces, and edit the interfaces, if required. If the IP address or subnet mask is missing for
port 1 or port 2, configure these values.
For the recommended upgrade path, see the FortiOS Version Upgrade Path. Select AWSFortiGate VM, and the
current and target upgrade versions.
For upgrade instructions, see Upgrading the firmware.
You can deploy FortiGate virtual machines (VMs) to support Auto Scaling on AWS. Optionally, AWS Transit Gateway
can be used to connect Amazon Virtual Private Clouds (Amazon VPCs) and their on-premises networks to a single
gateway. This integration extends the FortiGate protection to all networks connected to the Transit Gateway. Both
options require a manual deployment incorporating CloudFormation Templates (CFTs). Fortinet provides FortiGate
Autoscale for AWS deployment packages to facilitate each deployment.
Multiple FortiGate-VM instances form an Auto Scaling group to provide highly efficient clustering at times of high
workloads. FortiGate-VM instances can be scaled out automatically according to predefined workload levels. When a
spike in traffic occurs, a Lambda script is invoked to scale out the Auto Scaling group by automatically adding FortiGate-
VM instances. Auto Scaling is achieved by using FortiGate-native High Availability (HA) features such as config-
sync, which synchronizes operating system (OS) configurations across multiple FortiGate-VM instances at the time of
scale-out events.
FortiGate Autoscale for AWS is available with FortiOS 6.4.3 and supports any combination of On-Demand and Bring
Your Own License (BYOL) instances.
Fees will be incurred based on the Amazon Elastic Compute Cloud (Amazon EC2) instance
type. Additionally, a license is required for each FortiGate Bring Own License (BYOL) instance
you might use.
FortiGate Autoscale for AWS uses AWS CloudFormation Templates (CFTs) to deploy components.
Deployments without Transit Gateway integration have:
l A highly available architecture that spans two Availability Zones.*
l An Amazon VPC configured with public and private subnets according to AWS best practices, to provide you with
your own virtual network on AWS.*
l An Internet gateway to allow access to the Internet.*
l In the public subnets:
l A FortiGate host in an Auto Scaling group complements AWS security groups to provide intrusion protection,
web filtering, and threat detection to protect your services from cyber-attacks. It also allows VPN access by
authorized users.
l The primary FortiGate in the Auto Scaling group(s) acts as NAT gateway, allowing outbound Internet access
web filtering, and threat detection to protect your services from cyber-attacks. It also allows VPN access by
authorized users.
l The primary FortiGate in the Auto Scaling group(s) acts as NAT gateway, allowing outbound Internet access
Planning
This deployment requires familiarity with the configuration of a FortiGate using the CLI as well as with the following
AWS services:
l Amazon Elastic Cloud Compute (Amazon EC2)
l Amazon EC2 Auto Scaling
l Amazon VPC
l AWS CloudFormation
l AWS Lambda
l Amazon DynamoDB
l Amazon API Gateway
l Amazon CloudWatch
l Amazon S3
If deploying with Transit Gateway integration, knowledge of the following is also required:
l AWS Transit Gateway
l Border Gateway Protocol (BGP)
l Equal-cost multi-path (ECMP)
If you are new to AWS, visit the Getting Started Resource Center and the AWS Training and Certification website.
It is expected that FortiGate Autoscale for AWS will be deployed by DevOps engineers or advanced system
administrators who are familiar with the above.
Technical requirements
To start the deployment, you must have an AWS account. If you do not already have one, create one by following the
on-screen instructions.
Log into your AWS account and verify the following:
l IAM permissions. Ensure that the AWS user deploying the template has sufficient permissions to perform the
required service actions on resources. At a minimum, the following are required: Service: IAM;
Actions:CreateRole; Resource: *.
l Region. Use the region selector in the navigation bar to choose the AWS region where you want to deploy
FortiGate Autoscale for AWS.
This deployment includes AWS Auto Scaling, which isn’t currently supported in all AWS
Regions. For a current list of supported Regions, refer to the AWS documentation Service
Endpoints and Quotas.
l Instance Type. This deployment offers a range of instance types, some of which are not currently supported in all
AWS Regions. Ensure that your desired instance type is available in your region by checking the Instance types
page for your region.
l FortiGate subscription(s). Confirm that you have a valid subscription to the On-Demand FortiGate and/or BYOL
FortiGate marketplace listings, as required for your deployment.
l If you are not subscribed, open the subscription page and click Continue to Subscribe.
l Review the terms and conditions for software usage, and then choose Accept Terms. A confirmation page
loads, and an email confirmation is sent to the account owner.
l Exit out of AWS Marketplace without further action. Do not provision the software from AWS Marketplace.
l Key pair. Ensure at least one Amazon EC2 key pair exists in your AWS account in the region where you plan to
deploy FortiGate Autoscale for AWS. Make note of the key pair name.
l Resources. If necessary, request service quota increases. This is necessary when you might exceed the default
quotas with this deployment. The Service Quotas console displays your usage and quotas for some aspects of
some services. For more information, see the AWSdocumentation. The default instance type is c5.large.
l FortiGate licenses. Ensure you have a license for each FortiGate BYOL instance you might use. Licenses can be
purchased from FortiCare. In the section BYOL license files on page 43, you will place the license files in an S3
bucket for use by the deployment.
The FortiGate Autoscale for AWS deployment package is located in the Fortinet GitHub project.
To obtain the deployment package, use one of the following:
l Download the package aws-cloudformation.zip directly from the GitHub project release page.
l Manually generate the deployment package in your local workspace:
a. From the GitHub project release page, download the source code (.zip or .tar.gz) for the latest version.
b. Extract the source code into the project directory in your local workspace.
c. Run npm install to initialize the project at the project root directory.
d. Run npm run build-artifacts to generate the local deployment package.
The deployment package aws-cloudformation.zip will be available in the dist/artifacts directory.
Once you have the deployment package aws-cloudformation.zip:
1. Unzip the file on your local PC. The following files and folders will be extracted:
This assets folder contains configuration files that can be modified as needed to meet
your network requirements. For details, refer to the Appendix > Major components on
page 74 >The "assets" folder in the S3 bucket.
If you will be using BYOL instances, the deployment package will look for FortiGate license files in a location that ends
with license-files > fortigate. This location can created within the assets folder of the deployment package location or
within a custom asset location.
If a custom asset location is used, you must specify the location in the parameters described in the table
Custom asset location configuration on page 53.
Examples:
l If the deployment package is located at Amazon S3 > fortigate-autoscale > deployment-package, license files
would be uploaded to Amazon S3 > fortigate-autoscale > deployment-package > assets> license-files >
fortigate.
l If you will be storing license files in a custom S3 location and you have created the S3 bucket custom-s3-bucket-
name with the directory custom-asset-directory, you would upload the license files to Amazon S3 > custom-s3-
bucket-name > custom-asset-directory > license-files > fortigate.
Deployment notes
with Transit Gateway One inbound route domain and one outbound route domain will be created for the new or
integration existing Transit Gateway. FortiGate Autoscale for AWS will be attached to the Transit
Gateway.
into an existing VPC l Incoming requests to the web servers in the private subnets present in your existing VPC
will go through a connection that flows through the Internet gateway, network load
balancer, and the FortiGate Auto Scaling group before reaching the web server. The web
server returns the response using the same connection.
l One of the FortiGates in the Autoscale deployment acts as the NAT gateway for egress
traffic from the private subnets. Autoscale automatically manages the route with this
destination in your route table for the private subnet. As such, you can safely stop using
additional NAT devices for egress traffic from the private subnets.
l To partially route egress traffic through a different NAT device, create a route with a
specific destination with the other NAT device as the target. For example, for egress
traffic to 1.2.3.4 to use a different NAT device, create a route with destination 1.2.3.4/32
and your own NAT device as the target. egress traffic to 1.2.3.4 will now flow through
your own NAT device while the rest will flow through FortiGate.
1. Navigate to the S3 folder you uploaded files to in the previous section. In the example below, we navigate to
Amazon S3 > fortigate-autoscale > deployment-package.
2. Click templates and select the appropriate entry template to start the deployment. To deploy:
l with Transit Gateway integration, click autoscale-tgw-new-vpc.template.yaml
3. Copy the Object URL of the template you picked in the previous step. In our example, the template chosen is for
deploying into a new VPC.
6. Paste the Object URL from step 3 into the Amazon S3 URL field as shown below.
7. Click Next.
CFT parameters
On the Specify stack details page, enter the stack name and CFT parameters.
The following sections provide descriptions of the available parameters. Some parameters are specific to certain
templates, and are only displayed when that template is selected.
Resource tag prefix Requires The ResourceGroup Tag Key used on all resources and as the name prefix of all
(ResourceTagPrefix) input applicable resources. Can only contain uppercase letters, lowercase letters, and
numbers, ampersat(@), hyphens (-), period (.), and hash (#).
Maximum length is 50.
Resource name fgtASG An alternative name prefix to be used on a resource that the Resource tag prefix
prefix cannot apply to. Can only contain uppercase letters, lowercase letters, and
(CustomIdentifier) numbers.
Maximum length is 10.
Availability Zones Requires input The list of Availability Zones to use for the subnets in the VPC. The
(AvailabilityZones) FortiGate Autoscale solution uses two Availability Zones from your list and
preserves the logical order you specify.
VPC CIDR 192.168.0.0/16 The Classless Inter-Domain Routing (CIDR) block for the FortiGate
(VPCCIDR) Autoscale VPC.
Autoscale subnet 1 192.168.0.0/24 The CIDR block for the subnet located in Availability Zone 1 where
CIDR FortiGate Autoscale instances will be deployed to.
(PublicSubnet1CIDR)
Autoscale subnet 2 192.168.1.0/24 The CIDR block for the subnet located in Availability Zone 2 where
CIDR FortiGate Autoscale instances will be deployed to.
(PublicSubnet2CIDR)
Protected subnet 1 192.168.2.0/24 The CIDR block for the private subnet located in Availability Zone 1 where
CIDR it is protected by the FortiGates in the public subnet of the same
(PrivateSubnet1CIDR) Availability Zone.
Protected subnet 2 192.168.3.0/24 The CIDR block for the private subnet located in Availability Zone 2 where
CIDR it is protected by the FortiGates in the public subnet of the same
(PrivateSubnet2CIDR) Availability Zone.
VPC ID (VPCID) Requires The ID of the existing VPC where FortiGate Autoscale will be deployed.
input The VPC must have the option DNS hostnames enabled and each of the
two Availability Zones in the VPC must have at least 1 public subnet and at
least 1 private subnet.
VPC CIDR (VPCCIDR) Requires The CIDR block of the selected existing VPC. This can be found in
input parentheses in the VPC ID parameter selection.
Autoscale subnet 1 ID Requires The ID of the public subnet 1 located in Availability Zone 1 of the selected
(PublicSubnet1) input existing VPC.
Autoscale subnet 2 ID Requires The ID of the public subnet 2 located in Availability Zone 2 of the selected
(PublicSubnet2) input existing VPC.
Private subnet 1 Requires The ID of the private subnet 1 located in Availability Zone 1 of the selected
(PrivateSubnet1) input existing VPC. This subnet will be protected by the FortiGates in the public
subnet of the same Availability Zone.
Private subnet 2 Requires The ID of the private subnet 2 located in Availability Zone 2 of the selected
(PrivateSubnet2) input existing VPC. This subnet will be protected by the FortiGates in the public
subnet of the same Availability Zone.
Private subnet route table Requires Route table ID associated with the two private subnets.
(PrivateSubnetRouteTable) input
Availability Zones Requires input The list of Availability Zones to use for the subnets in the VPC. The
(AvailabilityZones) FortiGate Autoscale solution uses two Availability Zones from your list and
preserves the logical order you specify.
VPC CIDR 192.168.0.0/16 The Classless Inter-Domain Routing (CIDR) block for the FortiGate
(VPCCIDR) Autoscale VPC.
Autoscale subnet 1 192.168.0.0/24 The CIDR block for the subnet located in Availability Zone 1 where
CIDR FortiGate Autoscale instances will be deployed to.
(PublicSubnet1CIDR)
Autoscale subnet 2 192.168.1.0/24 The CIDR block for the subnet located in Availability Zone 2 where
CIDR FortiGate Autoscale instances will be deployed to.
(PublicSubnet2CIDR)
FortiGate configuration
Instance type c5.large Instance type for the FortiGates in the Auto Scaling group. There are t2.small
(FortiGateInstanceType) and compute-optimized instances such as c4 and c5 available with different
vCPU sizes and bandwidths. For more information about instance types, see
Instance Types.
FortiOS version 6.2.3 FortiOS version supported by FortiGate Autoscale for AWS.
(FortiOSVersion)
FortiGate PSK secret Requires A secret key for the FortiGate instances to securely communicate with each
(FortiGatePskSecret) input other. Must contain numbers and letters and may contain special characters.
Maximum length is 128.
Admin CIDR block Requires CIDR block for external admin management access.
(FortiGateAdminCidr) input
0.0.0.0/0 accepts connections from any IP address. We
recommend that you use a constrained CIDR range to
reduce the potential of inbound attacks from unknown IP
addresses.
Key pair name Requires Amazon EC2 Key Pair for admin access.
(KeyPairName) input
BGP ASN (BgpAsn) 65000 The Border Gateway Protocol (BGP) Autonomous System Number (ASN) of
the Customer Gateway of each FortiGate instance in the Auto Scaling group.
This value ranges from 64512 to 65534.
Desired capacity (BYOL) 2 The number of FortiGate instances the BYOL Auto Scaling group
(FgtAsgDesiredCapacityByol) should have at any time.
For High Availability in BYOL-only and Hybrid use cases, ensure at
least 2 FortiGates are in the group.
For specific use cases, set to 0 for On-Demand-only, and >= 2 for
BYOL-only or hybrid licensing.
Minimum group size (BYOL) 2 Minimum number of FortiGate instances in the BYOL Auto Scaling
(FgtAsgMinSizeByol) group.
For specific use cases, set to 0 for On-Demand-only, and >= 2 for
BYOL-only or hybrid licensing.
Maximum group size (BYOL) 2 Maximum number of FortiGate instances in the BYOL Auto Scaling
(FgtAsgMaxSizeByol) group.
For specific use cases, set to 0 for On-Demand-only, and >= 2 for
BYOL-only or hybrid licensing. This number must be greater than or
equal to the Minimum group size (BYOL).
Desired capacity (On-Demand 0 The number of FortiGate instances the On-Demand-only Auto
instances) Scaling group should have at any time.
(FgtAsgDesiredCapacityPayg) For High Availability in an On-Demand-only use case, ensure at least
2 FortiGates are in the group.
For specific use cases, set to 0 for BYOL-only, >= 2 for On-Demand-
only, and >= 0 for hybrid licensing.
Minimum group size (On-Demand 0 Minimum number of FortiGate instances in the On-Demand-only
instances) (FgtAsgMinSizePayg) Auto Scaling group.
For specific use cases, set to 0 for BYOL-only, >= 2 for On-Demand-
only, and >= 0 for hybrid licensing.
Maximum group size (On- 0 Maximum number of FortiGate instances in the On-Demand-only
Demand instances) Auto Scaling group.
(FgtAsgMaxSizePayg) For specific use cases, set to 0 for BYOL-only, >= 2 for On-Demand-
only, and >= 0 for hybrid licensing. This number must be greater than
or equal to the Minimum group size (On-Demand-only instances).
Scale-out threshold 80 The threshold (in percentage) for the FortiGate Auto Scaling group to
(FgtAsgScaleOutThreshold) scale out (add) 1 instance.
Minimum is 1. Maximum is 100.
Scale-in threshold 25 The threshold (in percentage) for the FortiGate Auto Scaling group to
(FgtAsgScaleInThreshold) scale in (remove) 1 instance.
Minimum is 1. Maximum is 100.
Primary election timeout 300 The maximum time (in seconds) to wait for the election of the
(PrimaryElectionTimeout) primary instance to complete.
Minimum is 30. Maximum is 3600.
Get license grace period 600 The minimum time (in seconds) permitted before a distributed
(GetLicenseGracePeriod) license can be revoked from a non-responsive FortiGate and re-
distributed.
Minimum is 300.
Health check grace period 300 The length of time (in seconds) that Auto Scaling waits before
(FgtAsgHealthCheckGracePeriod) checking an instance's health status.
Minimum is 60.
Scaling cooldown period 300 The Auto Scaling group waits for the cooldown period (in seconds) to
(FgtAsgCooldown) complete before resuming scaling activities.
Minimum is 60. Maximum is 3600.
Instance lifecycle timeout 480 The amount of time (in seconds) that can elapse before the
(LifecycleHookTimeout) FortiGate Autoscale lifecycle hook times out.
Minimum is 60. Maximum is 3600.
Transit Gateway support create one Create a Transit Gateway for the FortiGate Autoscale VPC to
(TransitGatewaySupportOptions) attach to, or specify to use an existing one.
Transit Gateway ID Conditionally Required when Transit Gateway support is set to "use an existing
(TransitGatewayId) requires one". It is the ID of the Transit Gateway that the FortiGate
input Autoscale VPC will be attached to.
Traffic port (LoadBalancingTrafficPort) 443 The port number used to balance web service traffic if the
internal web service load balancer is enabled.
Minimum is 1. Maximum is 65535.
Health check threshold 3 The number of consecutive health check failures required
(LoadBalancingHealthCheckThreshold) before considering a FortiGate instance unhealthy.
Minimum 3.
Internal ELB options add a (Optional) Add a predefined Elastic Load Balancer (ELB) to
(InternalLoadBalancingOptions) new route traffic to web service in the private subnets. You can
internal optionally use your own one or decide to not need one.
load
balancer
Health check path / (Optional) The destination path for health checks. This path
(InternalTargetGroupHealthCheckPath) must begin with a '/' character, and can be at most 1024
characters in length.
Internal ELB DNS name Requires (Optional) Specify the DNS Name of an existing internal load
(InternalLoadBalancerDnsName) input balancer used to route traffic from a FortiGate to targets in a
specified target group. Leave it blank if you don't use an
existing load balancer.
Heart beat interval 30 The length of time (in seconds) that a FortiGate instance waits between
(HeartBeatInterval) sending heartbeat requests to the Autoscale handler.
Minimum is 30. Maximum is 90.
Heart beat loss count 3 Number of consecutively lost heartbeats. When the Heartbeat loss count
(HeartBeatLossCount) has been reached, the FortiGate is deemed unhealthy and failover
activities will commence.
Heart beat delay allowance 2 The maximum amount of time (in seconds) allowed for network latency of
(HeartBeatDelayAllowance) the FortiGate heartbeat arriving at the Autoscale handler.
Minimum is 0.
Use custom asset location no Set to yes to use a custom S3 location for custom assets such as licenses
(UseCustomAssetLocation) and customized configsets.
Custom asset S3 bucket Requires Name of the S3 bucket that contains your custom assets. Required if 'Use
(CustomAssetContainer) input custom asset location' is set to 'yes'. Can only contain numbers, lowercase
letters, uppercase letters, and hyphens (-). It cannot start or end with a
hyphen (-)."
Custom asset folder Requires The sub path within the 'custom asset container' that serves as the top level
(CustomAssetDirectory) input directory of all your custom assets. If 'Use custom asset location' is set to
'yes', and this value is left empty, the 'custom asset container' will serve as
the top level directory. Can only contain numbers, lowercase letters,
uppercase letters, hyphens (-), and forward slashes (/). If provided, it must
end with a forward slash (/).
S3 bucket name Requires Name of the S3 bucket (created in step 4 of Obtaining the deployment package
(S3BucketName) input on page 41) that contains the FortiGate Autoscale deployment package. Can
only contain numbers, lowercase letters, uppercase letters, and hyphens (-). It
cannot start or end with a hyphen (-).
S3 resource folder Requires Name of the S3 folder (created in step 5 of Obtaining the deployment package on
(S3KeyPrefix) input page 41) that stores the FortiGate Autoscale deployment resources. Can only
contain numbers, lowercase letters, uppercase letters, hyphens (-), and forward
slashes (/). If provided, it must end with a forward slash (/).
1. After entering required parameters and clicking Next, you are directed to the Configure stack options page:
4. It is recommended that you disable the Stack creation option Rollback on failure. This will allow for a better
troubleshooting experience. Other advanced options can be specified as desired.
5. When done, click Next.
6. On the Review page, review and confirm the template, the stack details, and the stack options. Under
Capabilities, select both check boxes.
7. Click Create stack to deploy the stack. Creation status is shown in the Status column. To see the latest status,
refresh the view. It takes about 10 minutes to create the stack.
8. Deployment has completed when each stack (including the main stack and all nested stacks) has a status of
CREATE_COMPLETE.
To locate a newly deployed resource, it is recommended to search for it using the ResourceTagPrefix, also referred to
as the ResourceGroup Tag Key. Alternatively, the UniqueID can be used. For items that need a shorter prefix, the
CustomIdentifier can be used. These keys are found on the Outputs tab as shown below. Note that the UniqueID is at
the end of the ResourceTagPrefix.
To look up the newly deployed VPC using the ResourceGroup Tag Key:
1. In the AWS console, select Services > Network & Content Delivery > VPC.
2. In the left navigation tree, click Your VPCs.
Your VPC will be displayed. The Name of VPC is of the format <ResourceTagPrefix>-fortigate-autoscale-vpc.
To look up the newly deployed VPC subnets using the ResourceGroup Tag Key:
1. In the AWS console, select Services > Network & Content Delivery > VPC.
2. In the left navigation tree, click VIRTUAL PRIVATE CLOUD > Subnets.
3. Click the filter box and select Tag Keys > ResourceGroup.
4. Select your ResourceTagPrefix from the list of Tag Keys.
Your VPC subnets will be displayed. The Name of each subnets will be of the format <ResourceTagPrefix>-fortigate-
autoscale-vpc-subnet#<#>.
To look up the newly deployed Lambda Functions using the CustomIdentifier or the UniqueID:
FortiGate Autoscale for AWS creates two Auto Scaling groups with instances as specified in the CFT parameters. One
of theses instances is the elected primary instance. Verify the following:
l the Auto Scaling groups
l the primary election
If deploying with Transit Gateway integration, you will also need to verify:
l the Transit Gateway
1. In the AWS console, select the Services > Compute > EC2.
2. In the left navigation tree, click AUTO SCALING > Auto Scaling Groups.
3. Click the filter box and look up the Auto Scaling groups using the Unique ID.
4. The name of each group will start with the prefix you specified in Resource tag prefix. Confirm that the number in
the Instances column is equal to or greater than the Desired capacity you specified.
5. For each Auto Scaling group, select the check box to left of the Name, and then click the Instance Management
tab in the lower pane and confirm that the Lifecycle of each instance is InService.
If the AutoscaleRole column is not displayed, click the Preferences cog and locate the Tag columnsdropdown. Select
AutoscaleRole and then click Confirm.
1. In the AWS console, select the Services > Network & Content Delivery > VPC.
2. In the left navigation tree, click TRANSIT GATEWAYS > Transit Gateways.
3. Filter by the Tag Key ResourceGroup. There should be one result.
4. In the left navigation tree, click VIRTUAL PRIVATE NETWORK (VPN) > Customer Gateways.
5. Filter by the Tag Key ResourceGroup. There should be one customer gateway per running FortiGate instance (2 at
the start).
6. In the left navigation tree, click VIRTUAL PRIVATE NETWORK (VPN) > Site-to-Site VPN Connections.
7. Filter by the Tag Key ResourceGroup. There should be two items, 1 per FortiGate instance, each with a
corresponding Transit Gateway attachment.
8. In the left navigation tree, click TRANSIT GATEWAYS > Transit Gateway Attachments.
9. Filter by the Tag Key ResourceGroup. There should be one VPC, and one VPN per running FortiGate instance in
the Auto Scaling group. (2 at the start, one primary and one secondary). The VPN name will contain the public IP
address of the VPN.
10. In the left navigation tree, click TRANSIT GATEWAYS > Transit Gateway Route Tables.
11. Filter by the Tag Key ResourceGroup. There should be two items, one for inbound and one for outbound. For
diagrams, refer to the Appendix on page 74.
To connect to the primary FortiGate instance, you will need a login URL, a username, and a password.
1. Construct a login URL in this way: https://<IPAddress>:<Port>/, where:
l Port refers to the Admin port specified in the section FortiGate configuration on page 49.
l IPAddress refers to the Public IPv4 address of the FortiGate and is listed on the Details tab for the instance.
In the EC2 Management console, locate the primary instance as described in the section To verify the primary
election: on page 62. Click the Instance ID for the primary instance.
3. Log in with the username admin and the Instance ID of the primary FortiGate instance.
As the primary FortiGate propagates the password to all secondary FortiGate instances, this is the
initial password for all FortiGate instances.
You will need this initial password if failover occurs prior to the password being changed, as the
newly elected primary FortiGate will still have the initial password of the previous primary .
4. You will be prompted to change the password at the first-time login. It is recommended that you do so at this time.
You should only change the password on the primary FortiGate. The primary FortiGate
will propagate the password to all secondary FortiGates. Any password changed on a
secondary FortiGate will be overwritten.
5. You will now see the FortiGate dashboard. The information displayed in the license widget of the dashboard
depends on your license type.
You can attach an existing VPC to the FortiGate Autoscale with Transit Gateway environment by manually creating a
Transit Gateway attachment and adding the necessary routes, propagations, and associations:
1. Create a Transit Gateway attachment.
2. Create a route to the Transit Gateway.
3. Create a propagation in the inbound route table.
4. Create an association in the outbound route table.
The CIDR block for the VPC you are attaching must differ from that of the FortiGate
Autoscale VPC.
In the instructions that follow, the VPC transit-gateway-demo-vpc01 with CIDR 10.0.0.0/16 will be attached to the
FortiGate Autoscale with Transit Gateway environment.
1. In the left navigation tree, click TRANSIT GATEWAYS > Transit Gateway Attachment.
2. Click Create Transit Gateway Attachment.
3. Specify information as follows:
a. Transit Gateway ID: Select from the dropdown menu
b. Attachment type: VPC
c. Attachment name tag: Enter a tag of your choice
d. VPC ID: Select from the dropdown menu
e. Subnet IDs: This option appears once the VPC ID has been selected. Check the Availability Zone check box
(es) and choose 1 subnet per Availability Zone.
For everything else, use the default settings.
4. Click Create attachment.
5. Wait for the State to change from pending to available.
The Name is what you specified for the Attachment name tag.
6. When the State is available, click on the Resource ID to go to the VPC.
3. Click Add route and specify the Destination, for example, 10.1.0.0/16. Under Target, select Transit Gateway.
4. Then dropdown will change to display available Transit Gateways. Select the one created by the deployment stack
and then click Save routes.
If you want to route all traffic to the Transit Gateway, you should add a new route for
destination 0.0.0.0/0. If this route already exists, simply remove the route and add a new one
for the same destination with the target set to the Transit Gateway created by the deployment
stack.
1. In the left navigation tree, click Transit Gateways > Transit Gateway Route Tables.
2. Select the <ResourceTagPrefix>-transit-gateway-route-table-inbound route table.
7. Click on the Routes tab to see that the route for your VPC has been automatically propagated.
1. In the left navigation tree, click Transit Gateways > Transit Gateway Route Tables.
2. Select the <ResourceTagPrefix>-transit-gateway-route-table-outbound route table.
4. From Choose attachment to associate, select the attachment created in the section To create a Transit Gateway
attachment: on page 67.
The VPC is now connected to the FortiGate Autoscale Transit Gateway. For a technical view of attaching VPCs to the
FortiGate Autoscale Transit Gateway, please refer to the architectural diagram .
Troubleshooting
If you encounter a CREATE_FAILED error when you launch the Quick Start, it is recommended that you relaunch the
template with Rollback on failure set to Disabled. (This setting is under Advanced options in the AWS CloudFormation
console, Configuring option settings page.) With this setting, the stack’s state is retained and the instance is left
running, so you can troubleshoot the issue.
When you set Rollback on failure to Disabled, you continue to incur AWS charges for this
stack. Please make sure to delete the stack when you finish troubleshooting.
For additional information, see Troubleshooting AWS CloudFormation on the AWS website.
The deployment will also fail if you select an instance type that is not supported in the region that was selected. Your
desired instance type is available in your region if it is listed on the Instance types page for your region.
If the election of the primary FortiGate is not successful, reset the elected primary FortiGate. If the reset does not solve
the problem, please contact support.
To reset the elected primary FortiGate, navigate to the DynamoDB table <ResourceTagPrefix>-
FortiGatePrimaryElection. Click the Items tab and delete the only item in the table.
A new primary FortiGate will be elected and a new record will be created as a result.
For details on locating the DynamoDB table <ResourceTagPrefix>-FortiGatePrimaryElection, refer to the section
Locating deployed resources on page 57.
Appendix
Major components
l The BYOL Auto Scaling group. This Auto Scaling group contains 0 to many FortiGates of the BYOL licensing
model and will dynamically scale-out or scale-in based on the scaling metrics specified by the parameters Scale-out
threshold and Scale-in threshold. For each instance you must provide a valid license purchased from FortiCare.
For BYOL-only and hybrid licensing deployments, the Minimum group size
(FgtAsgMinSizeByol) must be at least 2. These FortiGates are the main instances and are
fixed and running 7x24. If it is set to 1 and the instance fails to work, the current FortiGate
configuration will be lost.
l The On-Demand Auto Scaling group. This Auto Scaling group contains 0 to many FortiGates of the On-Demand
licensing model and will dynamically scale-out or scale-in based on the scaling metrics specified by the parameters
Scale-out threshold and Scale-in threshold.
In FortiOS 6.2.3, any VIPs created on the primary instance will not sync to the
secondary instances. Any VIP you wish to add must be added as part of the base
configuration.
If you set the Internal ELB options parameter to do not need one, then you
must include your VIP configuration in the base configuration.
l The ... >license-files > fortigate folder contains BYOL license files.
l Tables in DynamoDB. These tables are required to store information such as health check monitoring, primary
election, state transitions, etc. These records should not be modified unless required for troubleshooting purposes.
l Networking Components These are the network load balancers, the target group, and the VPC and subnets. You
are expected to create your own client and server instances that you want protected by the FortiGate.
Configset placeholders
When the FortiGate requests the configuration from the Auto Scaling Handler function, the placeholders in the table
below will be replaced with actual values about the Auto Scaling group.
{CALLBACK_URL} URL The endpoint URL to interact with the auto scaling handler script.
{HEART_BEAT_ Number The time interval (in seconds) that the FortiGate waits between sending
INTERVAL} heartbeat requests to the Autoscale handler function.
RESOURCE_TAG_ The value of the CFT parameter Resource tag prefix which is described in the section
PREFIX Resource tagging configuration on page 47.
Deployment templates
Deploying FortiGate Autoscale for AWS requires the use of deployment templates. There are two types of templates:
l Entry template. This template could run as the entry point of a deployment.
l Dependency template. This template is automatically run by the deployment process as a Nested Stack. It cannot
be run as an entry template. A dependency template is run based on user selected options.
Following are descriptions of the templates included in the FortiGate Autoscale for AWS deployment package.
autoscale-tgw-new- Entry Deploys the Auto Scaling solution with Transit Gateway Integration to a
vpc.template.yaml template new VPC.
autoscale- Dependency Does the majority of the work for deploying FortiGate Autoscale.
main.template.yaml template
copy- Dependency Creates an S3 bucket in the same region where the stack is launched
objects.template.yaml template and copies deployment related objects to this S3 bucket.
create-autoscale- Dependency Creates a FortiGate Autoscale Handler Lambda function and an API
handler.template.yaml template Gateway.
create-db- Dependency Creates all necessary DynamoDB tables for the FortiGate Autoscale
table.template.yaml template solution.
create- Dependency Deploys a single FortiAnalyzer instance for certain purposes such as
fortianalyzer.template.yaml template storing logs from FortiGates.
create- Dependency Deploys a FortiGate EC2 instance to a subnet using a given FortiGate
fortigate.template.yaml template AMI, security group, and instance profile.
create-hybrid-auto-scaling- Dependency Deploys the hybrid licensing FortiGate Auto Scaling groups.
group.template.yaml template
create-load- Dependency Deploys network traffic Load Balancers and components for FortiGate
balancer.template.yaml template Autoscale.
create-new- Dependency Creates a new VPC in which to deploy the FortiGate Autoscale solution.
vpc.template.yaml template
create-transit-gateway- Dependency Creates a Transit Gateway for FortiGate Autoscale for AWS.
components.template.yaml template
Cloud-init
In Auto Scaling, a FortiGate uses the cloud-init feature to pre-configure the instances when they first come up.
During template deployment, an internal API Gateway endpoint will be created.
A FortiGate sends requests to the endpoint to retrieve necessary configuration after initialization.
Use this FOS CLI command to display information for your devices:
# diagnose debug cloudinit show
Architectural diagrams
The following diagrams illustrate the different aspects of the architecture of FortiGate Autoscale for AWS.
Primary election
Route propagation
Route associations
Document history
Template Details
3.0 (latest) Supports any combination of BYOL and On-Demand instances as well as the option for Transit
Gateway integration. Requires FortiOS 6.2.3.
2.0 Added support for Hybrid Licensing (any combination of BYOL and/or On-Demand instances) with
no Transit Gateway integration. Transit Gateway support is only for On-Demand instances.
Documentation is no longer maintained and is only available as a PDF:
l Deploying auto scaling on AWS without Transit Gateway integration 2.0
l Requires FortiOS 6.2.3.
1.0 Supports auto scaling for On-Demand instances; does not support Transit Gateway integration.
Requires FortiOS 6.0.6 or FortiOS 6.2.1.
Documentation is no longer maintained and is only available as a PDF:
l Deploying auto scaling on AWS 1.0
You can deploy the FortiGate-VM enterprise firewall for AWS as a virtual appliance in AWS (IaaS). This section shows
you how to install and configure a single instance FortiGate-VM in AWS to provide a full NGFW/unified threat
management security solution to protect your workloads in the AWS IaaS.
Networking is a core component in using AWS services, and using VPCs, subnets, and virtual gateways help you to
secure your resources at the networking level.
This section covers the deployment of simple web servers, but you can use this type of deployment for any type of public
resource protection, with only slight modifications. With this architecture as a starting point, you can implement more
advanced solutions, including multitiered solutions.
In the example, two subnets are created: Subnet1, which is used to connect the FortiGate-VM to the AWS virtual
gateway on the public-facing side, and Subnet2, which is used to connect the FortiGate-VM and the Windows server on
the private side.
On-demand users do not need to register from the FortiGate-VM GUI console. If you are using an on-demand licensing
model, once you create the FortiGate-VM instance in AWS, contact Fortinet Customer Support with the following
information:
l Your FortiGate-VM instance serial number
l Your Fortinet account email ID. If you do not have a Fortinet account, you can create one at Customer Service &
Support.
If you are deploying a FortiGate-VM in the AWS marketplace with BYOL, you must obtain a license to activate it.
See Creating a support account on page 12.
This section shows you how to create an AWS VPC and create two subnets in it. For many steps, you have a choice to
make that can be specific to your own environment.
If you are using the default VPC, the Internet gateway should already exist.
1. In the Virtual Private Cloud menu, select Internet Gateways, then select Create Internet Gateway.
2. In the Name tag field, set the Internet gateway name, then select Yes, Create.
3. Select the Internet gateway, then select Attach to VPC.
4. Select the VPC that you created and select Yes, Attach. The Internet gateway state changes from detached to
attached.
1. Go to the AWS Marketplace’s page for Fortinet FortiGate-VM (BYOL) or FortiGate-VM (on-demand). Select
Continue.
2. Select Manual Launch.
3. Select Launch with EC2 Console beside the region you want to launch.
4. Select an instance type, then select Next: Configure Instance Details.
5. Configure instance details:
a. In the Network field, select the VPC that you created.
b. In the Subnet field, select the public subnet.
c. In the Network interfaces section, you will see the entry for eth0 that was created for the public subnet. Select
Add Device to add another network interface (in this example, eth1), and select the private subnet. It is
recommended that you assign static IP addresses.
d. When you have two network interfaces, an EIP is not assigned automatically. You must manually assign one
later. Select Review and Launch, then select Launch.
6. Select an existing key pair or create a new key pair. Select the acknowledgment checkbox. Select Launch
Instances.
7. To easily identify the instance, set a name for it in the Name field.
8. Since FortiOS 6.2.2, on-demand FortiGate-VMs require connectivity to FortiCare to obtain a valid license. Without
connectivity to FortiCare, the FortiGate-VM shuts down for self-protection. Ensure the following:
a. Outgoing connectivity to https://directregistration.fortinet.com:443 is allowed in security groups and ACLs.
b. You have assigned a public IP address (default or EIP). If you have not enabled a public address during
instance creation, follow the remaining steps to assign an EIP and bring up the FortiGate-VM again.
9. Configure an EIP:
a. In the Network & Security menu, select Elastic IPs, then select one that is available for you to use or create
one. Select Actions > Associate Address. If you do not have one available to use, create one.
Configure the routing tables. Since the FortiGate-VM has two interfaces, one for the public subnet and one for the
private subnet, you must configure two routing tables.
1. To configure the public subnet's routing table, go to Networking & Content Delivery > VPC in the
AWSmanagement console. In the VPC Dashboard, select Your VPCs, and select the VPC you created. In the
Summary tab in the lower pane, select the route table ID located in the Route table field. To easily identify the
route table, set a name for it in the Name field.
2. In the Routes tab, select Edit, then select Add another route. In the Destination field, type 0.0.0.0/0. In the Target
field, type igw and select the Internet Gateway from the auto-complete suggestions. Select Save. The default
route on the public interface in this VPC is now the Internet Gateway.
3. In the Subnet Associations tab, select Edit, and select the public subnet to associate it with this routing table.
Select Save.
4. To configure the routing table for the private subnet, select Create Route Table. To easily identify the route table,
set a name for it in the Name field. Select the VPC you created. Select Yes, Create.
5. In the Routes tab, select Edit, then select Add another route. In the Destination field, type 0.0.0.0/0. In the Target
field, enter the interface ID of the private network interface. To find the interface ID, go to the EC2 Management
Console, select Instances, and select the interface in the Network interfaces section in the lower pane of the page
(Interface ID field). Select Save. The default route on the private subnet in this VPC is now the private network
interface of the FortiGate.
6. In the Subnet Associations tab, select Edit, select the private subnet to associate it with this routing table. Select
Save. Two routing tables, one for the public segment and one for the private segment, have now been created with
default routes.
7. In the EC2 Management Console, select Instances, and select the network interface that you created for the
private subnet (in this example, eth1) in the Network interfaces section in the lower pane. Select the interface ID.
8. Select the network interface, select the Actions dropdown list, select Change Source/Dest. Check. Select
Disabled. Select Save.
If you have multiple network interfaces, Source/Dest. Check needs to be disabled in each interface.
You can confirm by looking at the interface information shown as false.
To connect to the FortiGate-VM, you need your login credentials and its public DNS address.
The default username is admin and the default password is the instance ID.
1. You can find the public DNS address in the EC2 management console. Select Instances and look at the Public
DNS (IPv4) field in the lower pane. If you do not see the DNS address, you may need to enable DNS host
assignment on your VPC. In this case, go back to the VPC management console, select Your VPCs, and select
your VPC. Select the Action dropdown list, and select Edit DNS Hostnames. Select Yes. Select Save.
2. Open an HTTPS session using the public DNS address of the FortiGate-VM in your browser (https://<public DNS>).
You will see a certificate error message from your browser, which is normal because the default FortiGate
certificate is self-signed and isn’t recognized by browsers. Proceed past this error. At a later time, you can upload a
publicly-signed certificate to avoid this error. Log in to the FortiGate-VM with your username and password (the
3. If you’re using a BYOL license, upload your license (.lic) file to activate the FortiGate-VM. The FortiGate-VM will
automatically restart. After it restarts, log in again.
4. You will now see the FortiGate-VM dashboard. Depending on your license type, the information in the license
widget on the dashboard may vary.
5. Select Network > Interfaces, and edit the interfaces, if required. If the IP address or subnet mask is missing for
port 1 or port 2, configure these values.
1. In the AWS management console, select EC2. Select Launch Instance, then select the Microsoft Windows Server
2012 R2 that applies to your environment. You will use this to test connectivity with remote desktop access.
2. In the Configure Instance Details step, in the Network field, select the FortiGate-VM's VPC. In the Subnet field,
select the private subnet.
3. In the Configure Security Group step, configure a security group for the Windows server so that it allows Internet
access. In this example, we use Remote Desktop TCP port 3389, and other ports are optional. Select Review and
Launch.
4. Select a key pair, select the acknowledgment checkbox, and select Launch Instances.
See GitHub for details on this configuration. Although GitHub only refers to 6.0, you can deploy this HA configuration for
6.4.
FortiGate-VM can achieve HA using AWS ELB. You can deploy two FortiGate-VMs and associate them with an ELB,
and traffic is balanced between the two. If one FortiGate-VM fails, the other handles traffic. This provides more security
and reliability to the existing cloud infrastructure.
External and internal ELBs are required if you want to serve incoming and outgoing traffic for protected VMs. An external
ELB is normally accessible from the Internet and distributes traffic as it enters a VPC. An internal ELB has similar
capabilities but is only accessible within a VPC.
Like other load balancers, ELB can be configured as an external ELB that is accessible from the Internet and distributes
traffic as it enters a VPC, or as an internal ELB which has similar functions and is only accessible inside a VPC. This
section helps you get started with AWS ELB and FortiGate-VM configuration in an AWS environment.
Using this configuration, an IT administrator can place an application server inside a private subnet. The application
server can provide web applications, terminal services, or general purpose Internet service. The access is fully protected
and logged by the FortiGate-VM.
The design shows that application servers are fully separated between two subnets for active-active configuration. The
load is divided evenly in this configuration.
You can protect and turn multiple AZs highly available depending on how you design the topology.
You can also combine AWS Route 53 to use DNS name together with ELB.
1. Log into AWS with your EC2 credentials and select VPC.
2. Select Start VPC Wizard to create a new VPC.
3. Select VPC with a Single Public Subnet.
4. Fill in the information as required and select Create VPC.
5. You have created a VPC with a single public subnet available. In this example, the subnet is referred to as Fortinet-
VPC. To deploy the FortiGate-VM, you must also create a private subnet. Go to Subnet and select Create Subnet.
6. Fill in the information as required and select Yes, Create. In this example, the subnet will be referred to as
"Application Subnet 1".
1. Go to Security Groups and select Create Security Group. Set it to Fortinet-VPC. Select Yes, Create. In this
example, this security group is referred to as Allow everything.
2. Edit the Allow everything group. Select the Inbound Rules tab and then select Edit.
3. Set Type to ALL TCP, Protocol to TCP (6), Port Range to ALL, and Source to 0.0.0.0/0.
4. Select Save.
8. Review the information, then select Launch Instance to deploy the FortiGate-VM.
1. Go to Network Interface and note the Network Interface ID of the private interface and the FortiGate-VM ID. In
the example, these are eni-b25771d7 and eni-bd5771d8, respectively.
2. Go to Elastic IPs and select one of the IPs. Select Associate Address, then enter the network interface ID of the
FortiGate-VM. Select Associate.
1. Go to VPC Dashboard > Route Tables and select Create Route Table. Set VPC to the private subnet and select
Yes, Create.
2. Select the new route, then select the Routes tab, then select Edit. Select Add another route and set Destination to
0.0.0.0/0 and Target to the network interface ID of the private interface.
3. Select the Subnet Associations tab, enable the private subnet, and select Save.
1. Log into the FortiGate-VM GUI using the default admin account. The default admin account has the username
admin and no password. The license activation screen appears.
2. Select Choose File, select your license file, and select OK. The system restarts. After a few minutes, the login
screen appears. Log back into the FortiGate-VM.
3. Using your terminal, enter the following commands to log into the server and enable disk logging:
ssh -i ./Fortinet-AWS-Keypair.pem admin@ FortiGate-VM64-AWS #execute update-now
FortiGate-
VM64-AWS #execute formatlogdisk
4. Go to System > Admin > Administrators and edit the default admin account. Select Change Password and enter
a new password.
5. Go to System > Network > Interfaces and edit an internal interface (in the example, port2). Set Addressing Mode
to DHCP.
6. This port's IP address has changed to the IP you entered using the terminal (in the example, 10.0.1.5).
7. Go to Firewall Objects > Virtual IPs > Virtual IPs and create a new virtual IP that will map RDP (TCP port 3389) to
a Windows server that will be deployed in the next step.
8. Go to Policy > Policy > Policy and create a new policy allowing traffic from the Internet-facing interface to the
internal interface.
9. Create a second policy allowing traffic from the internal interface to the Internet-facing interface.
1. Connect to AWS and go to Network Interfaces. Right-click the private network interface, select Change
Source/Dest Check, and select Disable. AWS now lets packets pass through instead of filtering them.
3. Select t2.micro for the instance type and select Next: Configure Instance Details.
4. Set Network to Fortinet-VPC, subnet to Application Subnet 1, and Network Interfaces to eth0. Select Next: Add
Storage.
6. Select Next: Tag Instance. Enter a Name tag, then select Next: Configure Security Group.
7. Enable Select an existing security group and select the Allow everything group.
9. After you have reviewed the configuration, select the Fortinet-AWS-Keypair that you previously created.
10. Review the information, then select Launch Instance to deploy the server.
11. Go to EC2 instance and select the new subnet. Select Get Windows Password.
Click on Key Pair Path Browse and select the key pair file created earlier.
Select Decrypt Password to receive the administrator password for RDP connection.
12. Test the connection to your RDP server using your terminal and the following command:
C:\> mstsc /v: /admin
Repeat the above instructions to create a second AWS subnet and deploy a second FortiGate-VM on the subnet.
1. Go to the EC2 Dashboard, click Load Balancers, then Create Load Balancer.
2. Create a load balancer for RDP traffic within Fortinet-VPC. Select Continue.
4. Use the + on Public Subnet and add it into the Selected Subnets list. Select Continue.
7. Leave Tags as default and select Continue. A review page will appear. After you have reviewed the configuration,
select Create.
8. Now that the ELB is created, you can use a domain name to test your connection via an RDP client.
Results
Go to the EC2 dashboard and right-click FortiGate 1. Select Instance State > Stop to stop this instance.
Connect via RDP to the Windows Server. All connections use the subnet for FortiGate 2.
You can also connect using your ELB DNS name. Connections only use the subnet for FortiGate 2.
Start FortiGate 2 and wait until the ELB status is 2/2. Connect to the server using multiple sources.
The load is balanced between the FortiGate-VM instances.
This guide provides sample configuration of active-passive FortiGate-VM high availability (HA) on AWS within one zone.
FortiGate's native HA feature (without using an AWS supplementary mechanism) can be configured with two FortiGate
instances: one acting as the primary node and the other as the secondary node, located in two different availability
zones (AZs) within a single VPC. This is called "Unicast HA" specific to the AWS environment in comparison to an
equivalent feature provided by physical FortiGate units. The FortiGates run heartbeats between dedicated ports and
synchronize OS configurations. When the primary node fails, the secondary node takes over as the primary node so
endpoints continue to communicate with external resources over the FortiGate.
These paired FortiGate instances act as a single logical instance and share interface IP addressing. The main benefits
of this solution are:
l Fast failover of FortiOS and AWS SDN without external automation/services
l Automatic AWS SDN updates to EIPs and route targets
l Native FortiOS configuration sync
l Ease of use as the cluster is treated as single logical FortiGate
The following depicts the network topology for this sample deployment:
The following lists the IP address assignments for this sample deployment for FortiGate A:
The following lists the IP address assignments for this sample deployment for FortiGate B:
port1 10.0.0.12
port2 10.0.1.12
port3 10.0.2.12
port4 10.0.3.12
l Ensure that two FortiGates exist in the same VPC and AZ. The two FortiGates must also have the same build of
FortiOS (FGT_VM64_AWS or FGT_VM64_AWSONDEMAND) installed.
l If using FGT_VM64_AWS, ensure that both FortiGates have valid licenses.
1. In the AWS management console, create a VPC. The VPC in this example has been created with 10.0.0.0/16
CIDR.
2. Create four subnets. In this example, the four subnets are as follows:
a. Public WAN: 10.0.0.0/24
b. Internal network: 10.0.1.0/24
c. Heartbeat network: 10.0.2.0/24
d. Management network: 10.0.3.0/24
3. Create a single, open security group as shown below:
4. Create an IAM role. The IAM role is necessary for HA failover. Ensure that the IAM role can read and write EC2
information to read, detach, and reattach network interfaces and edit routing tables.
5. Create five elastic IP addresses. Five elastic IP addresses are needed to set up the environment, but we will be left
with three IP addresses at the end:
a. One public WAN IP address. This will be attached to the instance NIC1's secondary IP address.
b. One FortiGate A management IP address
c. One FortiGate B management IP address
d. Two temporary IP addresses
6. Create two FortiGate instances. You can use any instance type with at least four vCPUs, since four NICs are
required:
a. Configure FortiGate A:
i. Attach the IAM role created earlier.
ii. Create the instance in the VPC created earlier and in the public WAN subnet, with no ephemeral public IP
address.
iii. Configure an internal IP address of 10.0.0.11, and a secondary IP address of 10.0.0.13.
end
config system interface
edit port1
set mode static
set ip 10.0.0.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias external
next
edit port2
set mode static
set ip 10.0.1.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias internal
next
edit port3
set mode static
set ip 10.0.2.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias hasync
next
edit port4
set mode static
set ip 10.0.3.12 255.255.255.0
set allowaccess https ping ssh fgfm
set alias hamgmt
next
end
config router static
edit 1
set device port1
set gateway 10.0.0.1
next
end
config system dns
set primary 8.8.8.8
end
config firewall policy
edit 0
set name "outgoing"
set srcintf "port2"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic disable
set nat enable
next
end
config system ha
set group-name "test"
set mode a-p
set hbdev "port3" 50
set session-pickup enable
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface "port4"
set gateway 10.0.3.1
next
end
set override disable
set priority 1
set unicast-hb enable
set unicast-hb-peerip 10.0.2.11
end
After completing configuration of FortiGate B, remove the two temporary IP addresses. You can connect to the
FortiGates via the management ports instead.
The following shows the internal network routing table. Ensure to point the 0.0.0.0/0 CIDR to FortiGate A's port2 NIC.
The following shows the Heartbeat and management networks' routing table:
1. Run get system ha status to check that the FortiGates are in sync:
master # get sys ha stat
HA Health Status: OK
Model: FortiGate-VM64-AWSONDEMAND
Mode: HA A-P
Group: 0
Debug: 0
Cluster Uptime: 0 days 0:42:46
Cluster state change time: 2019-01-15 17:23:02
Master selected using:
<2019/01/15 17:23:02> FGTAWS000F19C1A0 is selected as the master because it has the
largest value of uptime.
<2019/01/15 17:09:47> FGTAWS000F19C1A0 is selected as the master because it's the only
member in the cluster.
ses_pickup: enable, ses_pickup_delay=disable
override: disable
unicast_hb: peerip=10.0.2.12, myip=10.0.2.11, hasync_port='port3'
Configuration Status:
This guide provides sample configuration of active-passive FortiGate-VM high availability (HA) on AWS between
multiple zones.
You can configure FortiGate's native HA feature (without using an AWS supplementary mechanism) with two FortiGate
instances: one acting as the master/primary node and the other as the slave/secondary node, located in two different
availability zones (AZs) within a single VPC. This is called "Unicast HA" specific to the AWS environment in comparison
to an equivalent feature provided by physical FortiGate units. The FortiGates run heartbeats between dedicated ports
and synchronize OS configurations. When the primary node fails, the secondary node takes over as the primary node so
endpoints continue to communicate with external resources over the FortiGate.
This feature is important because it solves a critical issue of High Availability, which is the ability to recover in the event
of a catastrophic failure. In the case that both FortiGates are located in the same Availability Zone and that AZ happens
to fail, then both FortiGates would go down and HA would be useless. Thus, there is a need to support HA configuration
where both FortiGates are in separate AZs.
These paired FortiGate instances act as a single logical instance and share interface IP addressing. The main benefits
of this solution are:
l Fast failover of FortiOS and AWS SDN without external automation/services
l Automatic AWS SDN updates to EIPs and route targets
l Native FortiOS configuration sync
l Ease of use as the cluster is treated as single logical FortiGate
The following depicts the network topology for this sample deployment:
The following lists the IP address assignments for this sample deployment for FortiGate A:
The following lists the IP address assignments for this sample deployment for FortiGate B:
IPsec VPN phase 1 configuration does not synchronize between primary and secondary
FortiGates across AZs. Phase 2 configuration does synchronize.
l Ensure that two FortiGates exist in the same VPC but different AZs. The two FortiGates must also have the same
FortiOS build (FGT_VM64_AWS or FGT_VM64_AWSONDEMAND) installed.
l If using FGT_VM64_AWS, ensure that both FortiGates have valid licenses.
l The following summarizes minimum sufficient IAM roles for this deployment:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*",
"ec2:AssociateAddress",
"ec2:AssignPrivateIpAddresses",
"ec2:UnassignPrivateIpAddresses",
"ec2:ReplaceRoute"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
1. In the AWS management console, create a VPC. The VPC in this example has been created with 10.0.0.0/16
CIDR.
2. Create eight subnets. In this example, the eight subnets are as follows:
a. Four in AZ A:
i. Public WAN: 10.0.0.0/24
ii. Internal network: 10.0.1.0/24
iii. Heartbeat network: 10.0.2.0/24
iv. Management network: 10.0.3.0/24
b. Four in AZ B:
i. Public WAN: 10.0.10.0/24
ii. Internal network: 10.0.11.0/24
iii. Heartbeat network: 10.0.12.0/24
iv. Management: 10.0.13.0/24
3. Create a single, open security group as shown below:
4. Create an IAM role. The IAM role is necessary for HA failover. Ensure that the IAM role can read and write EC2
information to read, detach, and reattach network interfaces and edit routing tables.
5. Create three elastic IP addresses:
a. One public WAN IP address. This will be attached to the instance NIC1's secondary IP address.
b. One FortiGate A management IP address
c. One FortiGate B management IP address
6. Create two FortiGate instances. You can use any instance type with at least four vCPUs, since four NICs are
required:
a. Configure FortiGate A:
i. Attach the IAM role created earlier.
ii. Create the instance in the VPC created earlier and in the public WAN subnet, with no ephemeral public IP
address.
iii. Configure an internal IP address of 10.0.0.11.
next
end
config firewall policy
edit 0
set name "outgoing"
set srcintf "port2"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic disable
set nat enable
next
end
config system ha
set group-name "test"
set mode a-p
set hbdev "port3" 50
set session-pickup enable
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface "port4"
set gateway 10.0.13.1
next
end
set override disable
set priority 1
set unicast-hb enable
set unicast-hb-peerip 10.0.2.11
end
After completing configuration of FortiGate B, remove the EIP to the FortiGate B public IP address. You can connect to
the FortiGates via the management ports instead.
The following shows the internal network routing table. Ensure to point the 0.0.0.0/0 CIDR to FortiGate A's port2 NIC.
The following shows the Heartbeat and management networks' routing table:
You must configure a VDOM exception to prevent interface synchronization between the two FortiGates. FortiOS 6.4.1
and later versions support the following commands. FortiOS 6.4.0 does not support these commands.
config system vdom-exception
edit 1
set object system.interface
next
edit 2
set object router.static
next
edit 3
set object firewall.vip
next
end
1. Run get system ha status to check that the FortiGates are in sync:
master # get sys ha stat
HA Health Status: OK
Model: FortiGate-VM64-AWSONDEMAND
Mode: HA A-P
Group: 0
Debug: 0
Cluster Uptime: 3 days 1:50:18
Cluster state change time: 2019-01-31 18:20:47
Master selected using:
<2019/01/31 18:20:47> FGTAWS0006AB1961 is selected as the master because it has the
largest value of override priority.
<2019/01/31 18:20:47> FGTAWS0006AB1961 is selected as the master because it's the only
member in the cluster.
ses_pickup: enable, ses_pickup_delay=disable
override: disable
unicast_hb: peerip=10.0.12.11, myip=10.0.2.11, hasync_port='port3'
Configuration Status:
FGTAWS0006AB1961(updated 3 seconds ago): in-sync
FGTAWS000B29804F(updated 4 seconds ago): in-sync
System Usage stats:
FGTAWS0006AB1961(updated 3 seconds ago):
sessions=18, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=10%
FGTAWS000B29804F(updated 4 seconds ago):
sessions=2, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=10%
HBDEV stats:
FGTAWS0006AB1961(updated 3 seconds ago):
port3: physical/00, up, rx-bytes/packets/dropped/errors=430368/1319/0/0,
tx=560457/1280/0/0
FGTAWS000B29804F(updated 4 seconds ago):
port3: physical/00, up, rx-bytes/packets/dropped/errors=870505/2061/0/0,
tx=731630/2171/0/0
Master: master , FGTAWS0006AB1961, HA cluster index = 1
Slave : slave , FGTAWS000B29804F, HA cluster index = 0
number of vcluster: 1
vcluster 1: work 10.0.2.11
Master: FGTAWS0006AB1961, HA operating index = 0
Slave : FGTAWS000B29804F, HA operating index = 1
This guide provides sample configuration of a manual build of an AWS Transit Gateway (TGW) with two virtual private
cloud (VPC) spokes and a security VPC. The security VPC contains two FortiGate-VMs to inspect inbound and outbound
traffic.
Before deploying FortiGate high availability (HA) for AWS with TGW integration, familiarity with the following
AWS services is recommended:
l Transit Gateway
l Elastic Cloud Compute (EC2)
l VPC
If you are new to AWS, see Getting Started with AWS.
This deployment consists of the following steps:
1. Creating VPCs and subnets on page 132
2. Creating a Transit Gateway and related resources on page 134
3. Creating an Internet gateway on page 135
4. Creating VPC route tables on page 135
5. Deploying FortiGate-VM from AWS marketplace on page 136
6. Adding network interfaces and elastic IP addresses to the FortiGate-VMs on page 137
7. Configuring the FortiGate-VMs on page 139
6. Repeat the process to create another spoke VPC and a security VPC.
7. Create subnets:
a. In the AWS console, go to the VPC service.
b. Select Subnets, then click the Create Subnet button.
c. In the Name tag field, enter the desired name.
d. In the VPC field, enter the VPC ID of the desired spoke or security VPC.
e. From the Availability Zone dropdown list, select the desired AZ.
f. In the IPv4 CIDR block, enter the desired CIDR block. Using default /24-sized subnets is recommended.
g. Click Create.
h. Repeat the process until you have the ten subnets.
After completion of this process, the example has configured the following subnets:
l AZ A subnets in security VPC:
l Public: 10.0.0.0/24
l Internal: 10.0.1.0/24
l Heartbeat: 10.0.2.0/24
l Management: 10.0.3.0/24
l Internal: 10.0.11.0/24
l Heartbeat: 10.0.12.0/24
l Management: 10.0.13.0/24
4. Create TGW associations:
a. In the AWS console, open the VPC service.
b. Select Transit Gateway Route Tables, then select the spoke route table.
c. On the Associations tab, click the Create Association button.
d. From the Choose attachment to associate dropdown list, select the spoke 1 VPC.
e. Click Create association.
f. Repeat the process for spoke B, which will be the second association for the route table.
g. Wait for both associations to achieve the Associated state before proceeding.
h. Next, select the security route table.
i. Repeat the same as above, and select the security VPC attachment from the Choose attachment to
associate dropdown list. Click Create association.
i. Select the spoke subnet that you just created, then click Save.
1. On the AWS marketplace, find a FortiGate-VM listing and version available for selection. This example uses
FortiGate-VM On-Demand 6.2.1, ami-0439b030915c59e67, on c5.xlarge instances. Available versions may
change.
Deploying a high availability (HA) pair requires four network interfaces. Instances smaller
than x.large do not support four network interfaces and do not work for this deployment
type.
3. Deploy the VM with only one network interface with public IP address assignment enabled.
4. Repeat the steps for the second VM instance in a second availability zone.
5. To enable management access to the FortiGate-VMs and HA traffic flow, open the security group attached to the
FortiGate-VMs:
a. In the AWS console, select Security Groups.
b. Click the Create Security Group button.
c. Add a rule with a source of 0.0.0.0/0 for all traffic types.
d. Assign the rule to all interfaces on both FortiGate-VMs. The next step in the process, Adding network
interfaces and elastic IP addresses to the FortiGate-VMs on page 137, explains creating additional network
interfaces. You can tighten the security group later.
c. Provide a description of the interface, specify the private subnet in availability zone A and specify the security
group created in Deploying FortiGate-VM from AWS marketplace on page 136.
d. Click Yes, Create.
e. Click the newly created interface. From the Actions dropdown list, select Change Source/Dest Check.
Disable Source/Dest Check and save.
f. From the Actions dropdown list, select Attach.
g. From the dropdown list, select the first FortiGate-VM. Click Attach.
h. Repeat the process for the second FortiGate-VM.
2. Repeat step 1 for the secondary FortiGate-VM. Each FortiGate-VM will be attached with four network interfaces:
Port Purpose
Port1 (eth0) Public network IP address. Elastic IP address (EIP) only for primary FortiGate
in high availability group.
c. Port 4 of the secondary FortiGate by selecting Network Interface as the Resource Type and its eth 3ENI
network interface to associate.
The primary FortiGate port 1 EIP will fail over to the secondary FortiGate in case of failure.
Port4 elastic IPs are not accessible until you form an HA cluster.
vii. Enable Unicast Heartbeat. Specify the port3 IP address of the peer FortiGate.
3. Log in to and configure the secondary FortiGate-VM by repeating steps 1-2. When configuring device priority in
HA settings, set a lower value than that of the primary node.
4. Configure policies to forward internal traffic out from port1. You only need to configure such policies on the primary
FortiGate-VM, as the policy configuration will synchronize between the FortiGate-VMs.
5. (Optional) You an configure an AWS SDN connector to allow population of dynamic objects such as policy objects.
See Configuring the SDN connector to populate dynamic objects on page 144.
Destination Target
i. Click Save. Check that the internal port2 subnets for both A and B are associated with this routing table.
2. Both firewalls need an IAM policy attached to make API calls to AWS to move the elastic IP address on port1 and
network interface on port2 between primary and secondary FortiGate-VMs. Go to the AMI service and create a role
with the following policy: {
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*",
"ec2:AssociateAddress",
"ec2:AssignPrivateIpAddresses",
"ec2:UnassignPrivateIpAddresses",
"ec2:ReplaceRoute"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
3. Attach the AMI role to both FortiGate-VMs by selecting the FortiGate EC2 instance and selecting Attach/Replace
IAM Role in the Actions menu.
To test FortiGate-VM HA failover:
1. To ensure that the FortiGate-VMs are in sync, run get system ha status:
master # get sys ha stat
HA Health Status: OK
Model: FortiGate-VM64-AWSONDEMAND
Mode: HA A-P
Group: 0
Debug: 0
Cluster Uptime: 1 days 1:50:18
Cluster state change time: 2019-01-31 18:20:47
Support
For issues, see this GitHub project's Issues tab. For other questions related to the GitHub project, contact
github@fortinet.com.
It is recommended to configure the SDN Connector using the GUI, then check the configuration using the CLI:
4. In the AWS secret access key field, enter the secret access key accompanying the above access key.
5. In the AWS region name field, enter the region name. Refer to AWS Regions and Endpoints for the desired
region name.
6. In the AWS VPC ID field, enter the VPC ID within the specified region you desire to cover with the SDN Connector.
7. In the Update Interval field, enter the desired number of seconds. You can enter any value between 1 and 3600
seconds. The default value is 60 seconds.
To check the configuration, open the CLI console and enter the following commands:
config system sdn-connector
edit "<connector-name>"
show
If you see that the Fabric connector is not enabled in Security Fabric > Fabric Connectors in the FortiOS GUI, try
running the following commands to enable the Fabric Connector:
diagnose deb application awsd -1
diagnose debug enable
In this case, you must configure power user access for the current administrator in the AWS management console:
Creating an address
You can create an address using the GUI or CLI. Either way, the process consists of the following steps:
1. Creating an address, which is used as an address group or single address to be used for source/destination of
firewall policies. The address is based on IP addresses. The address contains IP addresses of AWS instances that
are currently running.
2. When changes occur on the instances, the SDN connector populates and updates the changes automatically based
on the specified filtering condition so administrators do not need to reconfigure the address’s content manually.
3. Appropriate firewall policies using the address are applied to the instances that are members of it.
1. In FortiOS, go to Policy & Objects > Addresses. Click Create New, then select Address.
2. Enter the address name. From the Type dropdown list, select Dynamic.
3. From the Sub Type dropdown list, select Fabric Connector Address.
4. From the SDN Connector dropdown list, select the AWS Fabric connector.
5. In the Filter fields, enter the desired filters. This means the Fabric connector automatically populates and updates
only instances belonging to the specified VPC that match this filtering condition. You can use the following keys:
AZ placement.availabilityzone us-east-1a
VPC ID VpcId
For example, to automatically populate instances that belong to a certain subnet within the VPC, you can create a
filtering condition using subnetID. First, check the subnet ID in the AWS management portal.
6. From the Interface dropdown list, select an interface where the Fabric connector covers where relevant.
7. Click OK. Once saved, FortiOS lists the address under Policy & Objects > Addresses.
AZ placement.availabilityzone us-east-1a
VPC ID VpcId
For example, to automatically populate instances that belong to a certain subnet within the VPC, you can create a
filtering condition using subnetID. First, check the subnet ID in the AWS management portal.
4. Enter set filter "subnetId=subnet-fb2506a0", as well as other commands to configure the address
as desired. In this example, the subnet is 10.0.2.0/24. At this point, show shows the following:
Three instances with IP addresses 10.0.2.111, 10.0.2.112, and 10.0.2.114 have just been populated and are
updated automatically as you set the filtering condition above and the update interval specified in the GUI has been
reached. Since these three instances have been up and running in the specified VPC, the Fabric connector found
them through APIs that FortiOS called to AWS.
You can set the filtering condition using multiple entries with & (and) and | (or) button for each entry. When you use
both & and |, FortiOS interprets & before |. For example, you can enter subnetId=subnet-fb2506a0 &
tag.Name=abc123. In this case, an IP address of the instance that matches both the subnet ID and the tag
“Name” shows up. Filters support wildcard values.
1. Assume you want to boot up another instance with an IP address of 10.0.2.113, which is currently stopped. In the
AWS management portal, start the instance.
2. Verify that the instance is running.
3. At this point, running show again shows the SDN Connector has automatically populated and added the
10.0.2.113 instance.
Therefore, administrators do not need to add this instance to the Address manually. When a firewall policy is
applied to this Address, 10.0.2.113 is automatically covered. The filtering condition can be set using multiple
entries with AND ("&") or OR ("|"). When both ANDand OR are used, ANDis interpreted before OR. Check the syntax
by entering set filter ?.
For example, you can enter subnetID=subnet-fb2506a0 & tag.Name=abc123. In this case, an IP
address of the instance that matches both the subnet ID and the tag "Name" shows up. Note wildcards are not
allowed in values.
Finally, you can use this address to configure a firewall policy as a source or destination. The following operation is not
SDN connector-specific, but shows a general method of creating a firewall policy. Go to Policy & Objects > IPv4 Policy
and create a firewall rule.
The following summarizes minimum sufficient IAM roles for this deployment:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
AWS Fabric connectors support dynamic address groups based on AWS Kubernetes (EKS) filters. The following
summarizes minimum permissions for this deployment:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
Once you have the proper permissions for EKS, you must follow the steps at Managing Users or IAM Roles for your
Cluster for EKS to properly pull data from the cluster. The following shows a successful pull of IP addresses from the
EKS cluster:
After configuring the above, follow the instructions in the FortiOS Cookbook to complete configuration.
AWS GuardDuty is a managed threat detection service that monitors malicious or unauthorized behaviors/activities
related to AWS resources. GuardDuty provides visibility of logs called "findings", and Fortinet provides a Lambda script
called "aws-lambda-guardduty", which translates feeds from AWS GuardDuty findings into a list of malicious IP
addresses in an S3 location, which a FortiGate-VM can consume as an external threat feed after being configured to
point to the list's URL. To use this feature, you must subscribe to GuardDuty, CloudWatch, S3, and DynamoDB.
Installing and configuring GuardDuty requires knowledge of:
l CLI
l AWS Lambda function, DynamoDB, S3 bucket, and IAM
l Node.js
The Lambda script is available to download on GitHub.
Security implications
It is highly recommended that you create a dedicated AWS IAM role to run this Lambda function. The role should have
limited permissions to restrict operation on a dedicated S3 bucket resource for only this project.
It is never suggested to attach a full control policy such as AmazonS3FullAccess, which has full permissions to all
resources under your Amazon AWS account, to the role which runs the Lambda function. Allowing full-access
permissions to all resources may put your resources at risk.
Following is a list of permissions required for the IAM role to run this project across the required AWS services:
AWS service Permission
Parameters
interfaces (public IP, private IP, subnet ID, VPC ID, security groups)
l Action: type/connection direction
l Actor
l Additional
For more information about Amazon GuardDuty, see the Amazon GuardDuty official website.
There are five configurable environment variables in the Lambda function:
Installation
You can follow the installation steps below to setup this Lambda function:
Prerequisites
See below for a list of tools required to deploy this project before installation. Some prerequisites are platform-specific.
Choose the right one for your OS (such as Windows, Linux, or macOS).
l Node.js (6.5.0 or later)
l npm. Although npm comes with Node.js, check here for how to install npm and manage the npm version.
l AWS account
l Git (latest version)
l *Git Bash (latest version). Git Bash is a solution for Windows platform users to run the following installation steps.
The article Use git, ssh and npm on windows with Git Bash gives more information about setting up Git Bash on
Windows.
When you have all prerequisites ready, you can continue the installation as below. The commands in each steps are
intended to run in Terminal or Git Bash only.
You must create a deployment package from the local Git project repository, which will be uploaded for the Lambda
function creation in a later step.
1. Clone this project into the "guardduty" folder in your current local directory, and enter the project directory:
$ git clone https://github.com/fortinet/aws-lambda-guardduty.git guardduty
$ cd guardduty
2. Install project dependencies:
$ npm install
3. Build this project locally to create a deployment package .zip file. The file will be located in ./dist/aws_lambda_
guardduty.zip:
$ npm run build
This project needs one S3 bucket. The example in the following steps creates an S3 bucket named "my-aws-lambda-
guardduty". The example uses the bucket name in some configuration steps. Due to bucket naming limitations in S3,
each bucket should have a globally unique name. Therefore, your bucket should have a different name than the
example's. Write down your bucket name, since it is used in other configuration steps.
Create the S3 bucket to store the IP block list. In this example, the bucket is named my-aws-lambda-guardduty. This
bucket is required to run this project. Although bucket creation is region-specific, once created, the bucket can be
accessed from any region. Do not grant the bucket public access permissions. The Lambda function points to this
bucket through its S3_BUCKET environment variable.
One DynamoDB table with the stream feature enabled is required to store records of malicious IP addresses from
GuardDuty findings. DynamoDB tables and Lambda functions are region-specific so you must create the table and the
Lambda function in the same AWS region. A DynamoDB trigger on this table is created to cause the Lambda function to
execute. Since the Lambda function has not been created yet, instructions to create the trigger are provided later in
Setting up the DynamoDB stream trigger.
1. Create the DynamoDB table. In this example, the table is named my-aws-lambda-guardduty-db.
a. For the primary key, do the following:
i. Input the value finding_id. This value is case-sensitive.
ii. From the data type dropdown list, select String.
b. Add a sort key:
i. Input the value ip. This value is case-sensitive.
ii. From the data type dropdown list, select String.
c. Check used default settings for Table settings.
d. Click Create.
2. Enable the Stream feature on the table.
a. On the Overview tab, click Manage Stream, select Keys only, then click Enable to save.
b. Write down the Latest stream ARN. This ARN is used in the IAM policy creation step.
An IAM role is created to run the Lambda function. Three policies attach to the IAM role. The first one is a user-
managed policy which grants permissions to operation on the S3 bucket my-aws-lambda-guardduty. The second one is
a user-managed policy which grants permission to operation on the DynamoDB table my-aws-lambda-guardduty-db.
The third one is an AWS-managed policy which allows the Lambda function to write logs to CloudWatch.
1. Create a policy to operate on the S3 bucket.
a. Choose S3 as its service.
b. In Access level, add ListBucket on List, HeadBucket and GetObject on Read, PutObject on Write, and
PutObjectAcl on Permissions management.
c. In Resources, choose Specific.
i. For the bucket resource type, add the my-aws-lambda-guardduty S3 bucket ARN (for example,
arn:aws:s3:::my-aws-lambda-guardduty) to restrict access to any file in the specific bucket only.
ii. For the object resource type, add the my-aws-lambda-guardduty S3 bucket ARN and a /* wildcard (for
example, *arn:aws:s3:::my-aws-lambda-guardduty/**) to restrict access to any file in the specific bucket
only.
d. Click Review Policy, then Save Changes. The policy in JSON form looks like the code snippet below:
{
"Version": "2012-10-17",
"Statement": [
"{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:PutObjectAcl"
"],
"Resource": [
"arn:aws:s3:::my-aws-lambda-guardduty",
"arn:aws:s3:::my-aws-lambda-guardduty/*"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:HeadBucket",
"Resource": "*"
}
]
}
2. Create a policy to operate on the DynamoDB table.
a. Choose DynamoDB as its service.
b. In Access level, add ListStreams on List, DescribeStream, GetRecords, GetShardIterator, Scan on Read,
and UpdateItem on Write.
c. In Resources, choose Specific.
i. For the stream resource type, add the my-aws-lambda-guardduty-db latest stream ARN (for
example,arn:aws:dynamodb:us-east-1:888888888888:table/my-aws-lambda-guardduty-db/2018-07-
20T10:30:10.888). Replace the Stream label content with the * wildcard to allow for access to any stream
resource of the my-aws-lambda-guardduty-db table.
ii. Forthe table resource type, add the my-aws-lambda-guardduty-db DynamoDB table ARN (for example,
arn:aws:dynamodb:us-east-1:888888888888:table/my-aws-lambda-guardduty-db) to restrict access to
the specific table only.
d. Click Review Policy, then Save Changes. The policy in JSON form looks like the code snippet below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"dynamodb:GetShardIterator",
"dynamodb:Scan",
"dynamodb:UpdateItem",
"dynamodb:DescribeStream",
"dynamodb:GetRecords"
],
"Resource": [
"arn:aws:dynamodb:us-east-1:888888888888:table/my-aws-lambda-guardduty-
db/stream/*",
"arn:aws:dynamodb:us-east-1:888888888888:table/my-aws-lambda-guardduty-db"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "dynamodb:ListStreams",
"Resource": "*"
}
]
}
3. Create an IAM role to run the Lambda function.
a. Choose the Lamba service that will use this role.
b. Attach the two user-managed policies created in the previous steps to this role.
c. Attach the AWS-managed policy AWSLambdaBasicExecutionRole to this role.
The Lambda function is created with the deployment package generated in Preparing the deployment package on page
155. This package is uploaded directly to this Lambda function. The Lambda function has five configurable environment
variables for severity, AWS region, DynamoDB table name, and IP block list file entry point.
1. Create a function that authors from scratch.
a. Give the function a unique name.
b. For its Runtime, select Node.js 6.10.
c. For Role, select Choose an existing role. Select the role created in Setting up the IAM role and policies on
page 156.
2. Set up the function code.
a. For code entry type, select Upload a .ZIP file. The Function package field appears.
b. For Function package, click Upload to upload the deployment package .zip file generated in Preparing the
deployment package.
c. For Handler, enter index.handler.
3. Set up the environment variables. Note values for key fields are case-sensitive and should all be in upper case.
a. Add a key MIN_SEVERITY and input a value of 3.
b. Add a key S3_BUCKET and paste the name of the S3 bucket created in Setting up the S3 bucket on page
155. In this example, the S3 bucket name is my-aws-lambda-guardduty.
c. Add a key S3_BLOCKLIST_KEY and input a value of ip_blocklist or a different name as desired.
d. Add a key REGION and input the AWS region where your Lambda function and DynamoDB table are situated.
For example, the region of US East (N. Virginia) is us-east-1. For information about AWS Regions, please see
AWS Regions and Endpoints.
e. Add a key DDB_TABLE_NAME and input the name of the DynamoDB table created in Setting up the
DynamoDB table on page 155. In this example, the DynamoDB table name is my-aws-lambda-guardduty-db.
4. Save the Lambda function.
You must add a trigger to the DynamoDB table created in Setting up the DynamoDB table on page 155. This trigger is
the key that causes the Lambda function to generate a full IP block list to a static file in the S3 bucket.
The following describes how to create a trigger on a DynamoDB table
1. In DynamoDB, click the table to toggle on its detail window.
2. On the Triggers tab, click Create Trigger, then Existing Lambda function from the dropdown list.
3. From the Function dropdown list, select the Lambda function created in Creating the Lambda function on page
158.
4. Leave the Batch size value at its default, which is normally 100.
5. Select the Enable trigger checkbox.
6. Click Create.
At this point, installation is complete, although the AWS CloudWatch and GuardDuty services need additional
configuration to work with the Lambda function.
Setting up CloudWatch
In this section, a CloudWatch event rule is created to invoke the Lambda function based on events happening in
GuardDuty findings. If you have not subscribed to GuardDuty yet, you must subscribe to it before moving on. For
information about GuardDuty, see Amazon GuardDuty.
The following describes creating a new event rule.
1. For Event Source, choose Event Pattern, and select Events by Service from the dropdown list.
2. For Service Name, select GuardDuty from the dropdown list.
3. For Event Type, select GuardDuty Finding from the dropdown list.
4. Check that the Event Pattern Preview looks like the code snippet below.
{
"source": [
"aws.guardduty"
],
"detail-type": [
"GuardDuty Finding"
]
}
5. For the targets, click Add Target* and select Lambda function from the dropdown list.
6. For the Function, select the Lambda function you created from the dropdown list.
7. Click Configure rule details.
8. Name the rule as desired.
9. For State, select the Enabled checkbox.
10. Click Create Rule.
When all services have been created and configured properly, execute this simple test to verify your work.
1. Create and run the test event from the Lambda function:
a. From the Test Event dropdown list, select Configure test events.
b. Select Create new test event to add a test event with the content as the code snippet below.
{
"id": "fa9fa4a5-0232-188d-da1c-af410bcfc344",
"detail": {
"service": {
"serviceName": "guardduty",
"action": {
"networkConnectionAction": {
"connectionDirection": "INBOUND",
"remoteIpDetails": {
"ipAddressV4": "192.168.123.123"
}
}
},
"additionalInfo": {
"threatListName": "GeneratedFindingThreatListName">
},
"eventLastSeen": "2018-07-18T22:12:01.720Z"
},
"severity": 3
}
}
c. From the Test Event dropdown list again, select the event you have just created, then click Test to execute
this Lambda function with the given event.
2. Verify the test result.
a. If everything was set up correctly, you will see Execution result: succeeded on the top of the page of this
Lambda function.
b. Check and see a record with finding_id - fa9fa4a5-0232-188d-da1c-af410bcfc344 and ip - 192.168.123.123 is
in the DynamoDB table - my-aws-lambda-guardduty-db.
c. Check and see the file ip_blocklist resides in the S3 bucket my-aws-lambda-guardduty.
d. Check that the ip_blocklist file has a Read object permission for Everyone under the Public access section.
e. Check that the ip_blocklist is accessible through its link in browser (e.g. https://s3-us-east-
1.amazonaws.com/***my-aws-lambda-guardduty***/ip_blocklist)
f. Check that the ip_blocklist file contains 192.168.123.123 in a single line in its content.
Amazon GuardDuty monitors your AWS infrastructures on a continuous basis to detect malicious or unauthorized
behavior and creates records based on such findings. If you have just subscribed to GuardDuty for the first time, you will
see no findings in the list. You can click Generate sample findings under Settings and get some samples. Then several
dummy findings marked as “[SAMPLE]” are created. As long as you have set up the Lambda function and CloudWatch
correctly, some of those sample findings trigger the CloudWatch event rule to run the Lambda function. A few new IP
addresses eventually appear in the ip_blocklist.
As a FortiGate-VM feature, GuardDuty integration introduces the ability to dynamically import external block lists from
an HTTP server. You can use the block lists to enforce your organization's specialized security requirements. This can
include long term policies, such as always blocking access to certain websites, or short term requirements to block
access to known compromised locations. Since these lists are dynamically imported, the FortiGate-VM instantly imports
any changes made to the list.
In this example, the FortiGate-VM integrates with AWS GuardDuty to populate a list, which is treated as a "threat feed".
You can use a threat feed to deny access to a source or destination IP address in web filter and DNS filter profiles, SSL
inspection exemptions, and as a source/destination in proxy policies. The block list is stored as an external resource,
which is dynamically imported to the FortiGate-VM at a configured interval/refresh rate to maintain an updated list. The
administrator can configure multiple threat feeds in each profile.
1. To configure a threat feed, go to Security Fabric > Fabric Connectors, then click Create New, then IP Address
under Threat Feeds.
2. The following example creates an IP address connector. The resource name appears as an external IP block list in
DNS filter profiles and as a source/destination in proxy policies. Configure the following:
a. URI of external resource: link to an external resource file. The file should be a plain text file with one IP
address on each line. In this example, the IP address is https://s3-us-east-1.amazonaws.com/***my-aws-
lambda-guardduty***/ip_blocklist. The file size is up to 10 MB or 128000 lines of text, whichever is more
restrictive.
b. Refresh Rate: time interval to refresh the external resource. The rate can be between 1 to 43200 minutes.
3. Go to Policy & Objects > IPv4 Policy and create/edit a policy. In the Source and Destination fields, you should be
able to add the new feed.
Cleanup
Since test events and sample findings can update the ip_blocklist with sample IP addresses, it is highly recommended
to clean up the ip_blocklist for production use. This cleanup step removes the ip_blocklist from the S3 bucket and clears
the DynamoDB table.
1. Delete all records from the DynamoDB table. In this example, the DynamoDB table is my-aws-lambda-guardduty-
db.
2. Delete the ip_blocklist file in the my-aws-lambda-guardduty bucket.
With automation stitches, you can decrease response times to security events by automating activities between
different device components in the Security Fabric. You can monitor events from any source in the Security Fabric and
set up action responses to any destination.
FortiGate (both physical and virtual instances) supports AWS Lambda as an automated workflow.
l Creating an automation stitch on page 162
l Configuring an example automation stitch on page 163
You must specify an AWS role that is sufficiently privileged to run the Lambda code and
access CloudWatch/CloudWatch logs.
Let's try creating an example automation stitch with a simple pipeline. The example pipeline is as follows:
1. When an event log is created due to a successful login to the FortiGate,
2. Pick up one of the key-value pairs that the FortiGate sends to the API gateway
3. Invoke its AWS Lambda script, and, as an action, output the value on CloudWatch
Other actions you may want to configure include quarantining an EC2 instance by applying a different security group,
renaming an EC2 tag, and so on. You can configure a variety of actions as fits your deployment scenario.
For this example, do the following:
1. Create an automation stitch by completing all steps in Creating an automation stitch.
2. Under Trigger, select Event Log.
3. In the Event dropdown list, select Admin Login Successful.
4. You will need to know what elements FortiGate sends with the event log and what to pick on the Lambda script.
Now let's make the example event happen by logging into the FortiGate successfully as an admin user. Log out of
the FortiGate, then log in again. You will see the corresponding event log.
5. Go to Log & Report > System Events. Find the desired event log.
6. Download the log as a file. You can filter logs as shown below.
action: 'login',
status: 'success',
reason: 'none',
profile: 'super_admin',
msg: 'Administrator admin logged in successfully from https(FortiGate IP address)'
}
}
}
8. You can pick available key-value pairs in your AWS Lambda code. In this particular event log, useful keys include
stitch / date /time / vd / logdesc / user / ui / method / srcip / dstip / action / status / profile / msg.
9. You can see all JSON logs sent by FortiGate on CloudWatch Log by entering the following line in the Lambda code:
console.log(JSON.parse(event.body));
10. Now, as an example, let's pick user: 'admin' and srcip: '208.xx.yy.1'. Here is the Lambda script:
'use strict';
var AWS = require('aws-sdk');
exports.handler = function(event, context, callback) {
let body = JSON.parse(event.body);
var usr = body.data.rawlog.user;
var sourceip = body.data.rawlog.srcip;
// Write your automation scripts below
// .... Actions ....
console.log('Hello My Friend, ', usr, '@', sourceip, '!');
callback();
};
This is what the Lambda script will look like:
FortiOS supports using dynamic firewall addresses in real servers under a virtual server load balancing configuration.
Combined with support for the autoscaling group filter (see Creating an address on page 146), this enables you to use
the FortiGate as a load balancer in AWS for an autoscaling deployment. You do not need to manually change each
server's IP address whenever a scale in/out action occurs, as FortiOS dynamically updates the IP addresses following
each scale in/out action.
Consider a scenario where the FortiGate-VM is deployed on AWS and load balancing for three servers. The Fabric
connector configured in FortiOS dynamically loads the server IP addresses. If a scale in action occurs, the load balancer
dynamically updates to load balance to the two remaining servers.
The following instructions assume the following:
1. An AWS Fabric connector is configured and up.
2. An AWS dynamic firewall address with a filter is configured.
To configure a dynamic address object in a real server under virtual server load balance:
This guide provides a sample configuration that allows a local client PC to access an FTP server deployed inside the
AWS cloud by using an AWS Fabric connector via SSL VPN.
In this topology, a FortiGate-VM for AWS is deployed inside the AWS cloud. The FortiGate-VM can dynamically resolve
the FTP server's private IP address in the AWS cloud through an AWS Fabric connector. A local client PC with
FortiClient installed can establish an SSL VPN tunnel to the FortiGate-VM inside the AWS cloud, then access the FTP
server through the SSL VPN tunnel.
2. Create a Fabric connector firewall address to associate the configured Fabric connector:
a. Go to Policy & Objects > Addresses.
b. Click Create New, then select Address.
c. From the Type dropdown list, select Fabric Connector Address.
d. From the SDN Connector dropdown list, select the connector created in step 1.
e. For SDN address type, select Private.
f. In the Filter field, enter Tag.Name=publicftp. This is the name of the FTP server in the AWS cloud.
g. From the Interface dropdown list, select any.
h. Click OK. The following shows the FTP server as seen in the AWS management console.
3. After the update interval (60 seconds by default), check the resolved firewall address:
a. Go to Policy & Objects > Addresses.
b. Hover over the address created in step 2. In this example, it shows the firewall address (172.31.31.101) that
the configured Fabric connector resolves to.
iv. From the Server Certificate dropdown list, select the desired certificate.
v. Under Authentication/Port Mapping, set the default full-access portal for All Other Users/Groups.
vi. Create a new authentication/portal mapping for the group created in step a, mapping to the full-access
portal.
c. Configure the SSL VPN firewall policy:
i. Go to Policy & Objects > IPv4 Policy.
ii. From the Incoming Interface dropdown list, select the SSL VPN tunnel interface (ssl.root).
iii. From the Outgoing Interface dropdown list, select port1.
iv. In the Source field, select all and the group configured in step a.
v. In the Destination field, select the address created in step 2.
vi. From the Schedule dropdown list, select always.
vii. In the Service field, select ALL.
viii. For Action, select Accept.
ix. Click OK.
This example assumes that you are not using EMS to manage endpoints. If you are using EMS, use a licensed
FortiClient endpoint for the following configuration, skipping the installation step.
1. Download VPN-only FortiClient from FortiClient.com. Install onto the local client PC.
2. In FortiClient, on the Remote Access tab, add a new connection.
3. For VPN, select SSL-VPN.
4. In the Remote Gateway field, enter the IP address of the listening FortiGate interface. In this example, it is
100.26.32.219, the FortiGate-VM port1 public IP address.
5. Select Customize port, then enter 10443.
6. Save the configuration.
7. Use the credentials configured in step 4a above to connect to the SSL VPN tunnel. After connection, traffic to the
Fabric connector resolved IP address (172.31.31.101) goes through the tunnel. Other traffic goes through the local
gateway. The client PC side shows the routing entry for the SSL VPN tunnel:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.200.1 0.0.0.0 UG 0 0 0 eth1
172.31.31.101 10.212.134.200 255.255.255.255 UGH 0 0 0 ppp0
The FortiGate-VM shows the logged in user and the assigned SSL VPN tunnel virtual IP address.
1. To show Fabric connector status, run the diagnose sys sdn status command. The output should be as
follows:
SDN Connector Type Status
-------------------------------------------------------------
aws1 aws connected
2. To debug the AWS Fabric connector to resolve the firewall address, run the diagnose debug application
awsd -1 command. The output should be as follows:
...
awsd checking firewall address object dynamic-aws, vd 0
address change, new ip list:
172.31.31.101
awsd sdn connector aws1 finish updating IP addresses
...
3. To restart the AWS Fabric connector daemon, run the diagnose test application awsd 99 command.
This recipe provides sample configuration of a site-to-site VPN connection from a local FortiGate to an AWS VPC VPN
via IPsec with static routing.
Instances that you launch into an Amazon VPC can communicate with your own remote network via a site-to-site VPN
between your on-premise FortiGate and AWS VPC VPN. You can enable access to your remote network from your
VPC by configuring a virtual private gateway (VPG) and customer gateway to the VPC, then configuring the site-to-site
VPC VPN.
The following prerequisites must be met for this configuration:
l An AWS VPC with some configured subnets, routing tables, security group rules, and so on
l An on-premise FortiGate with an external IP address
This recipe consists of the following steps:
1. Create a VPG.
2. Create a customer gateway.
3. Create a site-to-site VPN connection on AWS.
4. Configure the on-premise FortiGate.
To create a VPG:
A VPG is the VPN concentrator on the Amazon side of the site-to-site VPN connection. You can create a VPG and attach
it to the VPC from which you want to create the site-to-site VPN connection.
1. In the AWS management console, go to Virtual Private Gateways, then click Create Virtual Private Gateway.
2. In the Name tag field, enter the desired gateway name.
3. For static route configuration, the ASN is not important, as the ASN is for BGP routing. By default, the VPG is
created with the default ASN, 64512. You cannot change the ASN once the VPG has been created.
4. After creating the VPG, select it from the list of VPGs, and click Actions > Attach to VPC.
5. On the Attach to VPC page, select the ID for the desired VPC from the VPC dropdown list.
In this example, the customer gateway refers to the on-premise FortiGate for the VPC VPN to connect to.
1. Go to Customer Gateways, then click Create Customer Gateway.
2. In the Name field, enter the desired gateway name.
3. For Routing, select Static.
4. In the IP Address field, enter the on-premise FortiGate's external address.
1. After creating the VPN, select it in the VPN list, then click Download Configuration. This document contains
information needed to configure the FortiGate correctly.
2. You can configure the FortiGate using this downloaded configuration file. The example FortiGate has port1 with an
external IP address of 35.188.119.246 and an internal IP address of 10.6.30.2/24. Port2 has an internal IP address
of 10.1.100.3/24. The downloaded configuration file resembles the following. The most important information here
is the remote-gw value, which in this case is 3.95.86.157, and the psksecret value.
Run the following commands in the FortiOS CLI to configure the FortiGate, using the remote-gw and
psksecret values from the downloaded configuration file as shown below. When setting the destination for the
static route, use the VPC's IPv4 CIDR:
config vpn ipsec phase1-interface
edit "examplephase1"
set interface "port1"
set keylife 28800
set peertype any
6. After the tunnel is up, you must edit a custom route table and security group rules to achieve connectivity between
a resource behind the FortiGate to a resource on the AWS cloud.
7. On AWS, there are two tunnels for each created VPN. This example only shows connecting to one tunnel, but you
can create the second tunnel in FortiOS as well. The second tunnel is for redundancy. If one tunnel goes down, the
FortiGate can reach AWS resources using the other tunnel.
This guide provides sample configuration of a site-to-site VPN connection from a local FortiGate to an AWS FortiGate
via site-to-site IPsec VPN with static routing. You can access resources that are protected behind a FortiGate on
AWS from your local environment by using a site-to-site VPN.
The following depicts the network topology for this sample deployment:
1. The tunnels are down until you initiate a connection from the local FortiGate to the AWS FortiGate. In FortiOS on
the local FortiGate, go to Monitor > IPsec Monitor.
2. Right-click the phase-2 interface, and select Bring Up.
3. In FortiOS on the AWS FortiGate, go to Monitor > IPsec Monitor and verify that the connection is up.
The elastic IP address can be considered as one to one to the FortiGate's IP address, even
though the port IP address may be an internal IP address.
2020-04-03 Updated Creating an address using the GUI and Creating an address using the CLI on page 149.
2020-04-06 Added Configuring FortiGate-VM load balancer using dynamic address objects on page 166.
2020-05-13 Added Migrating a FortiGate-VM instance between license types on page 14.
Updated Order types on page 11 and Creating a support account on page 12.
2020-05-21 Updated Launching the instance with shared FortiGate-VM AMI on page 32.
2020-09-21 Updated Deploying auto scaling on AWS on page 39. Added Hybrid licensing support for
deployments with Transit Gateway integration.
2020-12-04 Added support for FortiOS 6.4.3 in Deploying auto scaling on AWS on page 39.