In this lab you'll learn how to leverage terraform module published in Fortinet's GitHub repository to deploy an HA cluster of FortiGates in Google Cloud.

Overview

Terraform modules are convenient for grouping resources deployed together. They allow to keep your code clean by providing an abstraction layer to a block of code/resources. Fortinet terraform module for FortiGate HA cluster includes all necessary elements like addresses, load balancers and Cloud NAT and bootstraps FortiGate configuration for easy deployment. This lab will guide you through most common deployment using the module hosted on GitHub.

Architecture

The recommended architecture for deploying FortiGate appliances in Google Cloud is an active-passive HA cluster of two appliances with an external and internal pass-through network load balancer directing the traffic to the currently active instance. Both instances will be deployed with four network interfaces: one external, one internal, one reserved for HA cluster synchronization and one dedicated for management. For more details on the recommended architecture and the use-cases please refer to FortiGate architecture in Google Cloud.

Before you start

Before you start completing the lab tasks it is worth spending a moment learning your lab environment and consoles. You can skip this part if you are already familiar with Fortinet Qwiklabs.

Qwiklabs environment will create a dedicated temporary access to the Google Cloud for you. You do not need your own accout to complete the labs. The environment will be available for a limited time - there is no possibility to pause the lab so make sure you have time to complete it. If you don't make it - don't worry, you can start the lab again later.

The webpage you are reading right now is your Lab Console. You will find the instructions how to complete each step here. On the right you can find navigation frame with links to individual sections of the lab. After you start the lab, on the left side under the Start Lab / End Lab button you will find the time left for the lab, a button opening your GCP Console and a series of information you will need to complete the lab. Start your lab now if you haven't done so yet.

GCP console

Clicking the Open Console button on top left will open a new browser tab with Google login form. Use the and to log in. Please accept the terms and conditions, but do NOT subscribe to e-mail updates.

On the left you will find a list of all services available in GCP which can be toggled on and off using the "burger menu" icon in the top-left corner. Commonly used in Fortinet labs are Compute Engine, VPC network, and Network services. The latter is not visible in the default view and can be found after expanding the list using MORE PRODUCTS link at the bottom. Feel free to use pin / unpin button visible after hovering over list elements to build your own list of most used services.

Products, individual resources and documentation can be also easily found using the search bar located at the top of the screen.

FortiGate console

FortiGate virtual appliances can be managed using web GUI available over HTTPS protocol on the default port or using command line interface in GUI or via SSH. Configuration of FortiGate HA cluster is managed only using the primary instance and automatically replicated to secondary instance. Secondary instance management console can be optionally accessed using its public IP address to verify the clustering and replication status.

How To Use This Tutorial

While there are several ways to run terraform, the simplest one is to use the command-line. If you are new to deploying cloud infrastructure using code we recommend using Cloud Shell, which comes preinstalled with the gcloud CLI, Git, Terraform, and text editors. If you use Cloud Shell, you don't need to install anything on your workstation. Cloud Shell can be accessed within the Cloud Console or in a separate browser tab or window. In order to use the To use Cloud Shell Cloud Shell editor and terminal at the same time open https://shell.cloud.google.com in a new browser tab.:

Prerequisites

1. Four separate VPCs with at least one subnet in each (external, internal, HA synchronization and management). All subnets need to be in the same region and cannot have overlapping address spaces. While the module supports deployments with less and more network interfaces (NICs), the reference architecture uses 4 NICs. In this lab the VPCs were already automatically created for you.
2. For deployment of BYOL (Bring Your Own License) instances upload the license files lic1.lic and lic2.lic template folder before you run Terraform plan. These licenses cna be referenced in the terraform code for bootstrapping the licensing. In this lab you will use PAYG licensing.
3. Although not obligatory, it’s highly recommended you create a dedicated custom role and a service account for FortiGate. If no service account is indicated in input variables the template FortiGate instances will be assignedThe template will attempt to detect it and will fall back to the Compute Engine Default. In this lab a proper role and a service account (fortigatesdn-ro) were already created for you. See the "FortiGate: Fabric Connector for Google Cloud" lab for additional instructions.

Cloud Shell

While there are several ways to run terraform, the simplest one is to use the command-line. If you are new to deploying cloud infrastructure using code we recommend using Cloud Shell, which comes preinstalled with the gcloud CLI, Git, Terraform, and text editors. If you use Cloud Shell, you don't need to install anything on your workstation. Cloud Shell can be accessed within the Cloud Console or in a separate browser tab or window. In order to use the Cloud Shell editor and terminal at the same time open https://shell.cloud.google.com in a new browser tab.

Building your template

Create deployment template files

Terraform merges and deploys all *.tf files in the current working directory (folder), but it’s convenient to split the code into multiple files for better readability. You will create a new directory and use multiple files following the best practices which recommend putting resources, output, and variables into separate files (see Best practices for general style and structure for more details on terraform guidelines). You will leverage gcloud authentication to configure Google Terraform provider. This way you do not need the explicit provider block in your code (you may still create it though for the code clarity). For alternative ways of authenticating terraform to Google Cloud consult the terraform provider documentation.

1. In the Cloud Shell terminal create a new directory (eg. tf-fortigate) and a standard set of terraform files: mkdir tf-fortigate && cd tf-fortigate touch main.tf variables.tf outputs.tf terraform.tfvars
2. Configure gcloud to use your Google Cloud project (replace “[PROJECT_ID]” with ): gcloud config set project [PROJECT_ID]
3. In the Cloud Shell editor open the folder you just created (click the burger menu at top-left, select File > Open Folder, select tf-fortigate ).

Variables

It is recommended to use input variables to store any values that might change between deployments or which are used in multiple places. This way you will be able to re-use the same terraform code in different environments by only changing variable values. Variables are typically declared in variables.tf file and their values can be passed using command-line, environment variables, file or deployment tool like Terraform Cloud. You will use terraform.tfvars file to assign values to variables.

Open variables.tf file in editor and declare set of basic inputs for the FortiGate module:

variable "prefix" { type = string } variable "zones" { type = list(string) } variable "project_id" { type = string }

Next, open terraform.tfvars file and assign values to your variables replacing the sample values below:

prefix = "example-prefix" project_id = "example-project-id"

For project_id use , for prefix use a string of your choice.

This lab subnets are deployed in region. Find its availability zones and deploy FortiGates to those zones. While the terraform module can find the zones automatically if provided with the region argument, for production deployments it is recommended to indicate zones explicitly using the zones argument instead and avoid excessive inter-zonal traffic. To find the available zones you can use the following gcloud command (replace "MY_REGION" with region of your lab):

gcloud compute zones list --filter="region:MY_REGION"

Create a list of 2 different zones in the same region and save it as a value of an input variable in terraform.tfvars, eg. for “europe-west2” region you could choose:

zones = [ "europe-west2-b", "europe-west2-c" ]

Create FortiGate Template

Open the main.tf file and start by adding an optional provider block and configuring terraform to use your Google Cloud project. You can use project_id variable you set earlier:

provider "google" { project = var.project_id } Note: Adding a provider block is not necessary if using Cloud Shell, as all the google provider configuration can be pulled from the environment variables. In practice however many Google Cloud terraform modules require project id as input variable and it's easier to have it available as variable.

In main.tf file create a module block for FortiGate cluster and indicate source of the module published in Fortinet GitHub account:

module "fgt_ha" { source = "git::github.com/fortinet/terraform-google-fgt-ha-ap-lb" }

Required module arguments

Indicate zones where to deploy using input variable and list the subnet names you want to connect your cluster to.

zones = var.zones subnets = [ "external", "internal", "hasync", "mgmt" ]

The subnets "external", "internal", "hasync", and "mgmt" were already created for this lab. You can find them in cloud console or using command below (optional filter will hide subnets from the default VPC):

gcloud compute networks subnets list --filter="name!=default" Note: Deciding whether to use a variable or explicit value depends on the rest of the code and general DRY (Don’t Repeat Yourself) principle and is out of scope of this article. Note that if you created the subnets in the same terraform configuration you would rather use terraform references, not explicit names as in this example. You would also need to add a `depends_on` meta-argument to the module block due to the way this module uses the `subnets` argument.

If you need to deploy less or more network interfaces you can easily do so by providing a shorter or longer list of subnets in subnets argument. See 3-nic-basic and 8-nic-basic examples in GitHub repository for a sample code.

Additional module arguments

The following arguments are not obligatory for the module to work, but allow fine control over the configuration of your cluster. For the full list of the module input variables consult the documentation of the module and variables.tf file available in GitHub repository.

To configure the virtual machine type and the firmware version use the machine_type and image arguments:

machine_type = "n2-standard-4" image = { version = "7.6.1" license = "payg" }

Keep in mind the requirements regarding vCPUs related to the number of network interfaces (4 NICs require a machine type with at least 4 vCPUs).

This module accepts flexible inputs regarding base images - you can use versions (also in shorter branch notation) with licencing type, family names and explicit image names. You can find more details in the module documentation.

In this lab you are using a PAYG (Pay As You Go) licensing. To use BYOL (Bring Your Own License) image, which requires license files or FortiFlex activation tokens, change the image.license argument from "payg" to "byol". You can license the cluster during bootstrapping by providing license file names:

license_files = ["license1.lic", "license2.lic"]

or using FortiFlex tokens:

flex_tokens = ["B1C38EDAEA0D4E568D2F", "9E8FF67B64924C3B82E1"]

External IP Addresses

As the module creates external load balancer forwarding rules for the public traffic you can define your addresses using frontends argument. Eg.

frontends = ["app1", "app2"]

will reserve 2 external addresses, connect them to external network pass-through load balancer (ELB) and redirect all ports (L3_DEFAULT) to FortiGates. FortiGates will be preconfigured with VIP pools matching the addresses.

Instead of providing names for new addresses you can provide an existing IP address to be used. The IP needs to exist in the same region and cannot be currently assigned. These addresses currently cannot be created outside the module in the same terraform run as the FortiGates.

SDN Connector Service Account

FortiGate uses its linked service account to synchronize metadata information about Compute resources. By default the module will use the Default Compute Engine Service Account, but you should use a dedicated one (see the "FortiGate: Fabric Connector for Google Cloud" lab for more details). In this lab the service account was already created, indicate it in service_account argument (replacing "PROJECT_ID" with your real project id: ):

service_account = "SDN_CONNECTOR_SERVICE_ACCOUNT"

Naming and labels

Lastly, make sure the resources are named and labeled according to your organizational standard using prefix and labels arguments:

prefix = "fgt-demo" labels = { project = "demo" }

Your code should now look similar to below:

provider "google" { project = var.project_id } module "fgt_ha" { source = "git::github.com/fortinet/terraform-google-fgt-ha-ap-lb" zones = [ "europe-west2-b", "europe-west2-c" ] subnets = [ "external", "internal", "hasync", "mgmt" ] machine_type = "n2-standard-4" image = { version = "7.6.1" license = "byol" } license_files = ["license1.lic", "license2.lic"] frontends = ["app1", "app2"] service_account = "fortigatesdn-ro@PROJECT_ID.iam.gserviceaccount.com" prefix = "fgt-demo" labels = { project = "demo" } }

Outputs

Terraform can show values related to created resources to streamline the workflow. In this case it would be useful to know the management address of the deployed firewalls and the initial admin password. As you are using a module to deploy resources you have to use the outputs made available by the module itself.

Open outputs.tf file which is usually used to declare outputs and add the following code:

output "primary_fgt_address" { value = module.fgt_ha.fgt_mgmt_eips[0] } output "default_admin_password" { value = module.fgt_ha.fgt_password }

Initialize and deploy the Terraform template

In the terminal window make sure you are in the directory with your template code and run the following command to download all necessary terraform modules and providers:

terraform init

At this point you are ready to deploy the infrastructure. Run the following command

terraform apply

you will be presented with the full list of all resources terraform will create, confirm the operation by typing “yes”. Terraform will now create all resources included in the FortiGate module.

Plan: 34 to add, 0 to change, 0 to destroy. Changes to Outputs: + default_admin_password = (known after apply) + primary_fgt_address = (known after apply) Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes

Verify deployment

Use the management IP address of primary FortiGate and initial admin password from terraform outputs to connect using SSH:

[...] Outputs: default_admin_password = "4711281455519643176" primary_fgt_address = "35.246.28.103" student_xx@cloudshell:~/tf-fortigate (qwiklabs-gcp-xx)$ ssh admin@35.246.28.103

Note that you might need to wait a few minutes before FortiGates fully provision. You can check the VMs serial console output in Google Cloud web console to monitor the progress.

After connecting for the first time you will be asked to change your password:

Please login with username=admin and password=<instance-id> admin@35.246.28.103's password: You are forced to change your password. Please input a new password. According to the password policy enforced on this device, please change your password! New password must conform to the following policy: minimum-length=8; not be reused New Password: Confirm Password: Verifying password... fgt-demo-vm-fgt1-euw2b #

Verify the status of the provisioning by checking the output of the following command:

get system ha status

The output should resemble the following:

fgt-demo-vm-fgt1-euw2b # get system ha status HA Health Status: OK Model: FortiGate-VM64-GCP Mode: HA A-P Group Name: gcp-group Group ID: 0 Debug: 0 Cluster Uptime: 0 days 0h:1m:43s Cluster state change time: 2025-01-21 03:50:22 Primary selected using: <2025/01/21 03:50:22> vcluster-1: FGTGCP-W-3X3TJ62 is selected as the primary because its override priority is larger than peer member FGTGCP-V_MVFAW7A. <2025/01/21 03:50:00> vcluster-1: FGTGCP-W-3X3TJ62 is selected as the primary because it's the only member in the cluster. ses_pickup: enable, ses_pickup_delay=disable override: enable unicast_hb: peerip=10.0.2.3, myip=10.0.2.2, hasync_port='port3' Configuration Status: FGTGCP-W-3X3TJ62(updated 3 seconds ago): in-sync FGTGCP-W-3X3TJ62 chksum dump: 63 6f db 01 3d 4e 20 1c 05 ca a4 e1 0c fd 01 e7 FGTGCP-V_MVFAW7A(updated 1 seconds ago): out-of-sync FGTGCP-V_MVFAW7A chksum dump: ec fe 87 84 9c cd f9 34 84 c2 4b f8 4c b2 c3 cf System Usage stats: FGTGCP-W-3X3TJ62(updated 3 seconds ago): sessions=25, average-cpu-user/nice/system/idle=0%/0%/0%/99%, memory=7% FGTGCP-V_MVFAW7A(updated 1 seconds ago): sessions=1, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=7% HBDEV stats: FGTGCP-W-3X3TJ62(updated 3 seconds ago): port3: physical/10000full, up, rx-bytes/packets/dropped/errors=189171/611/0/0, tx=323252/768/0/0 FGTGCP-V_MVFAW7A(updated 1 seconds ago): port3: physical/10000full, up, rx-bytes/packets/dropped/errors=326956/771/0/0, tx=194124/629/0/0 number of member: 2 fgt-demo-vm-fgt1-euw2b, FGTGCP-W-3X3TJ62, HA cluster index = 0 fgt-demo-vm-fgt2-euw2c, FGTGCP-V_MVFAW7A, HA cluster index = 1 number of vcluster: 1 vcluster 1: work 10.0.2.2 Primary: FGTGCP-W-3X3TJ62, HA operating index = 0 Secondary: FGTGCP-V_MVFAW7A, HA operating index = 1

At the end of the output, you should see two instances: Primary and Secondary. This output confirms that both instances were licensed properly and successfully formed an HA cluster.

Note: The secondary instance might initially show up as out-of-sync, further deployment and configuration steps can continue regardless.

Clean-up

The last step is cleaning up and deleting all resources that were created in the tutorial.

Delete the FortiGate and the remaining resources:

Go to the deployment directory in Cloud Shell terminal and run the following command:

terraform destroy

Confirm you want to delete the resources by typing "yes".

Plan: 0 to add, 0 to change, 34 to destroy. Changes to Outputs: - default_admin_password = "4711281455519643176" -> null - primary_fgt_address = "35.246.28.103" -> null Do you really want to destroy all resources? Terraform will destroy all your managed infrastructure, as shown above. There is no undo. Only 'yes' will be accepted to confirm. Enter a value: