Introduction
There have been some blog articles already created describing the deployment of Fortigate Firewalls in Aviatrix Transit Firenet, incl. the best one that I have seen so far: Ricardo Trentin’s one. Nevertheless, I wanted to share additional pieces of information that might be informative.
The purpose of this post is to show:
- how to create Firenet from normal Aviatrix Transit VNET in Azure
- how to deploy Fortigate using specific image ID
- how to perform initial setup of Frotigate Firewalls
Fortigate in Azure Firenet - overview
The Aviatrix mc-firenet module will be used for deploying Firewalls in Azure Transit. The mc-firenet module must be used in conjunction with mc-transit module. Hence, It is required to deploy Transit VNET using mc-transit module first.
The mc-transit module creates VNET in Azure with few subnets (those subnets can be seen in the diagram above). From Fortigate FW1’s perspective the most important ones are:
• “-Public-FW-ingress-egress-1” where Network Interface of FW1 port1 (Internet/WAN) is placed
• “-dmz-firewall-lan” where Network Interface of FW1 port 2 (LAN) is placed
In case of FW2 those subnets are called “-Public-FW-ingress-egress-2” and “-hagw-dmz-firewall-lan” respectively.
1 - Deploying the Fortigate Firewalls using Terraform
I have created Transit VNET using the following TF code:
Now, it is time to create Fortigate Firewalls (two of them) using mc-firenet module. As you may notice below, we will use data source to gather the CIDR used by “-Public-FW-ingress-egress-1” subnet. The same CIDR is used for both “egress_cidr” and “mgmt_cidr” as there is no separate mgmt interface in Fortigate.
Please notice that if you want to use the FortiOS version that is not listed in Controller GUI, you must use the “firewall_image_id” argument instead of “firewall_Image_version” (as shown above).
Creating REST_API User
The REST_API user will be created using Fortigate GUI. The user will have Admin Profile assigned.
Let’s create Admin Profile “api_admin” first:
The set of permissions depends on the pieces of configuration you want to modify later with Terraform, e.g.
- interface/port – requires Read/Write for Network/Configuration
- (optionally) static route – requires Read/Write for Network/Router
- (optionally) policy – requires Read/Write for Firewall/Policy
Once Admin Profile is there, the REST-API user can be created:
Please copy the Token for the API-admin user and store it in a safe place. It will be required in the configuration later.
Fortigate Provider in Terraform
The “fortios” is the name of the provider to be used in Terraform.
There are two Firewalls deployed => which means two Tokens => and two provider sections must be configured. The Terraform “alias” will be used to distinguish between FW-1 and FW-2.
The “azurerm” provider is required by data sources used later.
Fortigate Interface Configuration using Terraform
The WAN interface (port1) is configured properly by default. Though port2 (LAN interface) configuration must be adjusted (and its default config varies between FortiOS versions).
Use the following TF code to configure port2 (Read/Write permission for Network/Configuration is required):
Aviatrix Vendor Integration using Terraform
The “Vendor Integration” feature configures static routes (for RFC1918 and Azure LB HealthCheck) on Fortigate.
Please notice that a Fortigate token for REST_API is required.
And REST_API user must have the following permission: Read/Write for both Network/Router Network/Configuration.
The following routes are configured after successful Vendor Integration:
Optional: Static Routes configuration using TF instead of Aviatrix Vendor Integration
Please notice that if you do not want to use Aviatrix Vendor Integration (though I cannot see any reason for not using it) you can create all the static routes using thefortios resource called “fortios_router_static”. Example below:
Optional: Policy Rules creation using Terraform
The following code presents how to create Policy rule using Terraform.
2 - Verification
Azure LB Health Check probes
Once the Static Route for Azure LB HealthCheck is created (either using Aviatrix Vendor Integration or Terraform resource) you can check the Health Check status in Azure Portal.
Go to Load Balancer -> select the proper LB -> Metrics
Change the Metric to Health Probe Status
Health Checks must be successful for Azure Load Balancer to send traffic to Fortigate FWs.
Logs for Local Traffic
To check that Health Probes are getting to the Firewall itself, we must enable proper logging for Local Traffic.
Go to Log & Report -> Log Settings
Change Local Traffic Log to “All”
Now you can go to Log & Report -> Local Traffic
Click on “Add Filter”, select Destination, and put Azure LB HealthCheck IP 168.63.129.16
