Deploying an Aviatrix FireNet on Azure with Fortinet FortiGate

Aviatrix Transit FireNet allows the deployment of 3rd party firewalls onto the Aviatrix transit architecture.

Transit FireNet works the same way as the Firewall Network where traffic in and out of the specified Spoke is forwarded to the firewall instances for inspection or policy application.

FireNet Design

The diagram below shows the Aviatrix Firenet design for Azure. When a transit gateway is deployed with the firenet option checked, the Aviatrix controller will:

  • create subnets
  • create UDRs
  • create an internal NLB
  • configure the internal NLB (front end, back-end, healtch check)

Aviatrix deploys and configures the Internal Load Balancers for a Firenet.

Number of Interfaces

Fortigate Next Generation Firewall instance has 2 interfaces as described below:

Screen Shot 2022-06-02 at 5.07.58 PM

Consumption Models

Fortinet offers its FortiGate NGFW in two consumption models:

  • BYOL (Bring Your Own License): let you run software on Compute Engine while using licenses purchased directly from the provider. Google only charges you for the infrastructure costs, giving you the flexibility to purchase and manage your own licenses.

You must obtain a license to activate the FortiGate. If you have not activated the license, you see the license upload screen when you log into the FortiGate and cannot proceed to configure the FortiGate.

You can obtain licenses for the BYOL licensing model through any Fortinet partner. After you purchase a license or obtain an evaluation license (60-day term), you receive a PDF with an activation code.

  • PAYG (Pay as you Go): PAYG license is a usage-based or pay-per-use license. You can purchase a PAYG license from the Azure Marketplace.

FortiGate is priced based on the number of CPU cores (vCPU) of the instance.

System Models

System Performance

Screen Shot 2022-06-02 at 5.12.08 PM

Deployment

There are several plans available for deployment on Azure Marketplace:

Screen Shot 2022-06-02 at 4.54.01 PM

I’m going to leverage the mc-firenet and mc-spoke developed by my colleague Dennis Hagens to deploy a Firenet. Here is my provider:

terraform {
required_providers {
aviatrix = {
source = "AviatrixSystems/aviatrix"
version = "2.22.2"
}
azurerm = {
source = "hashicorp/azurerm"
version = "3.8.0"
}
}
provider "aviatrix" {
controller_ip = var.controller_ip
username = var.username
password = var.password
skip_version_validation = true
verify_ssl_certificate = false
}
provider "azurerm" {
subscription_id = var.subscription_id
client_id = var.client_id
client_secret = var.client_secret
tenant_id = var.tenant_id
}
view raw gistfile1.txt hosted with ❤ by GitHub

The module deploys a single VPC (Transit Firenet), transit gateways (HA), and firewall instances. The terraform file that I used in my environment can be downloaded from here:

module "mc_transit" {
source = "terraform-aviatrix-modules/mc-transit/aviatrix"
version = "v2.1.1"
cloud = var.cloud
cidr = var.vpcs["firenet"]
region = var.region
account = var.account
enable_transit_firenet = true
lan_cidr = var.vpcs["lan"]
enable_bgp_over_lan = true
}
module "firenet_1" {
source = "terraform-aviatrix-modules/mc-firenet/aviatrix"
version = "1.0.2"
transit_module = module.mc_transit
firewall_image = var.firewall_image
firewall_image_version = var.firewall_image_version
egress_cidr = var.vpcs["egress"]
egress_enabled = true
inspection_enabled = true
instance_size = var.instance_size
mgmt_cidr = var.vpcs["mgmt"]
password = var.password
}
module "mc-spoke" {
for_each = {
"spoke30" = "spoke30"
"spoke40" = "spoke40"
"ingress" = "ingress"
}
source = "terraform-aviatrix-modules/mc-spoke/aviatrix"
version = "1.2.1"
account = var.account
cloud = var.cloud
name = "azure-${each.value}-${var.region}"
region = var.region
cidr = var.vpcs["${each.value}"]
inspection = true
transit_gw = module.mc_transit.transit_gateway.gw_name
ha_gw = true
instance_size = var.instance_size
single_az_ha = false
}
view raw gistfile1.txt hosted with ❤ by GitHub

Supported firewall images are listed here:

https://registry.terraform.io/providers/AviatrixSystems/aviatrix/latest/docs/resources/aviatrix_firewall_instance

For testing purposes I’m going to create the following spokes:

  • spoke30 vpc
  • spoke40 vpc
  • ingress vpc (ingress will not be used for testing in this document)

Once the terraform is applied, before testing, I’m going to check/review the configuration applied.

Checking VPCs and Subnets

From the azure portal virtual network:

Screen Shot 2022-06-02 at 5.33.42 PM

Checking Aviatrix Gateways

From the Multi-Cloud transit menu, we check if the transit gateway was created correctly:

  • Connect Transit is enabled

Screen Shot 2022-06-03 at 3.39.40 AM

We have to install the Transit Firenet Function at the deployment.

Checking Transit Firenet on Transit Gateway

Transit gws were deployed with the firenet functionality and it is enabled :

Screen Shot 2022-06-03 at 3.41.39 AM

By default Firenet is configured to inspect inbound and east-west traffic but not outbound. To enable outbound (egress), we have to enable it.

FortiGate Configuration

After the launch is complete, the console displays the FortiGate-VM instance with its public IP address of management interface and allows us to download the .pem file for SSH access to the instance. Select the instance and click on actions. A drop-down menu will appear to download the key:

Change the pem file permission restricting access only to the owner.

If you provided username and password you dont need to download the key file or changed the password is instructed below.

Change Password

SSH to the instance and change the password for the admin user:

config system admin
edit admin
set password <new-password_str>
exit

Once the password is set, using a web browser we can connect to the Fortinet GUI. The first time we log in after the deployment, it loads the Setup wizard:

Hostname or Serial Number:

Dashboard:

New features video review:

Dashboard:

License

  • To activate a PAYG license copy the VM’s serial number from the dashboard:
  • In the Registration page, enter the serial number, and select Next to continue registering the product. Enter your details in the other fields.

To obtain the VM-ID run the command below on the CLI console:

Screen Shot 2022-06-03 at 3.57.54 AM

Once the VM-ID is provided and the license agreement is accepted you should see:

Screen Shot 2022-06-03 at 3.59.32 AM

Interfaces Configuration

  • Port 1 is the mgmt and external/unstrusted/WAN interface
  • Port 2 is the internal/trusted/LAN interface
Screen Shot 2022-06-03 at 4.05.57 AM

Disable source check using the CLI console:

config system interface
edit “port2”
set src-check disable
end

Vendor Firewall Integration

This step automatically configures the RFC 1918 and non-RFC 1918 routes between Aviatrix Gateway and Vendor’s firewall instance in this case Fortinet FortiGate-VM. This can also be done manually through Cloud Portal and/or Vendor’s Management tool.

Create an Administrator profile

The REST API admin should have the minimum permissions required to complete the request. Click on System -> Administrator -> Create New -> REST AP Admin:

We need to provide username and profile. Because Aviatrix will push configs to the FortiGate-VM, we will need to create an admin profile:

Once the admin profile is created, we create the user:

An API-Key is generated for the user:

The system will automatically generate a new API key, this key will only be displayed once.

Vendor Integration

Back to the controller, we will configure the vendor integration:

If you dont see the output as below, click on the sync button:

Screen Shot 2022-06-03 at 4.30.37 AM

FortiGate is accepting connections via a load balancer (ILB). We have to additionally configure routes to the health probes’ IP ranges on each interface receiving traffic. This prevents the reverse path forwarding check from blocking the health probes.

Screen Shot 2022-06-03 at 4.29.23 AM

Health Check

FortiGate requires an administrative access to reply to health probes from a NLB:

  • select and edit port2

Screen Shot 2022-06-03 at 4.27.25 AM

Security Policy for Heath Check

Create a security policy granting Azure health check ranges access both VIPs created before:

Screen Shot 2022-06-03 at 4.45.30 AM

Once the policy is saved the health probe status of the NLB changes from 0 to 100%:

Screen Shot 2022-06-03 at 4.46.08 AM

Firenet Policy

To inspect traffic from spokes 30 and 40, we have to add them to the Inspection Policy using the submenu Policy under the Firewall Network menu:

Screen Shot 2022-06-03 at 4.48.54 AM

Testing

Checking GWs at Spokes

Using the Gateway menu, we check if the GWs for spokes 30 and 40 were deployed correctly:

  • spokes are attached to the transit gateway
Screen Shot 2022-06-03 at 4.50.02 AM

East-West Traffic Flow

FortiGate implicit denies all communication. We need to create a security policy for inter vpc flows:

Screen Shot 2022-06-03 at 5.04.50 AM

Two test VMs were deployed into spokes 30 and 40 respectlivery. spoke30 instance (10.255.230.36) pings spoke40 instance (10.255.240.36):

Screen Shot 2022-06-03 at 5.17.18 AM

We can use AppIQ and FlighPath to check and troubleshoot if required:

Screen Shot 2022-06-03 at 5.07.54 AM

FlighPath will check azure network nsg, nsg rules rules, spoke and transit gateway route tables:

Screen Shot 2022-06-03 at 5.09.40 AM

References

https://docs.aviatrix.com/HowTos/config_FortiGateAzure.html

4 thoughts on “Deploying an Aviatrix FireNet on Azure with Fortinet FortiGate

Leave a Reply