FortiGate SDN Connector for Azure

Facebooktwittergoogle_pluslinkedinFacebooktwittergoogle_pluslinkedin

In this recipe, you configure FortiGate SDN (or Fabric) Connector for use with Microsoft Azure. 

In the FortiGate interface, these connectors are called Fabric Connectors and are software-defined network (SDN) connectors that provide integration and orchestration of Fortinet products with key SDN solutions. The Fortinet Security Fabric provides visibility into your security posture across multiple cloud networks, spanning private, public, and Software as a Service (SaaS) clouds. By using the Fabric Connector for use with the Microsoft Azure Infrastructure as a Service (IaaS), changes to attributes in the Azure environment can be automatically updated in the Fortinet Security Fabric.

Before installing and configuring the Fabric Connector for Azure, the following Microsoft Azure Infrastructure and Fortinet FortiGate components should be in place :

  • A valid Microsoft Azure account and subscription. This could be one established by your organization or simply one of the free trial options available from Microsoft Azure (https://azure.microsoft.com/en-us/free/)
  • A FortiGate-VM ‘virtual appliance’ should be deployed in Azure
  • An IPv4 outbound policy from the FortiGate-VM ‘virtual appliance’ on Port 2 (Internal) to Port 1 (External)
  • A VM instance of a resource in the Azure environment. In this instance, a Linux server has been used for testing the assigning of a tag

There can only be one fabric connector for each type of environment (AWS/Azure/VMware NSX, etc.) on a FortiGate. In this recipe, it is a fabric connector for Azure. If the FortiGate is a virtual device in one of those environments, it is likely be the only connector configured.

1. Required information

Before you create a Fabric Connector for Microsoft Azure, you need to collect the following information:

  • Azure tenant ID

  • Azure client ID

  • Azure client secret

  • Azure subscription ID

  • Azure resource group

 

All of this information is found through Azure rather than Fortinet sources. This recipe tells you where to find the information and where to apply it. Most of this recipe relates to a third party’s website, so some of this information, especially the Azure screenshots, could change. 

The following three items are already present in your Azure configuration and can be looked up easily.

2. Getting the Azure tenant ID

The Directory ID in Azure is the same as the Azure tenant ID required by the FortiGate.

Go to the Properties of the FortiGate in the Azure interface and find the Directory ID.

The location of the Directory ID in Azure

To do it through the CLI:

Step #A – Log into the Azure environment’s command line

$ azure login -v -u  -p   
info:    Executing command login verbose: Authenticating... 
info:    Added subscription PAYG Dev/Test Subscription 
info:    Added subscription Fortinet Engineering 
info:    Added subscription Pay-As-You-Go 
info:    Added subscription SE-Subscription 
info:    login command OK $

 Step #B – Show the account information. Find the Tenant ID.

$ azure account show 
info:    Executing command account show 
data:    Name                        : Fortinet Engineering 
data:    ID                          : 2f96c44c-cfb2-4621-bd36-65ba45185e0c 
data:    State                       : Enabled 
data:    Tenant ID                   : 942b80cd-????-42a1-????-4b21dece61ba 
data:    Is Default                  : true 
data:    Environment                 : AzureCloud 
data:    Has Certificate             : No 
data:    Has Access Token            : Yes 
data:    User name                   :  
data: 
info:    account show command OK

3. Getting the Azure subscription ID

The Azure subscription is referred to in the Azure interface as the Subscription ID.

Go to the Overview for the FortiGate VM resource.

In the Azure interface menu, under Favorites, select Dashboard, then from the All resources column, select the name of the FortiGate on which you are configuring the connector.

The Subscription ID is a hexadecimal number.

The location of the Subscription ID in Azure

There are two variations of finding the Subscription ID information through the CLI:

  1. Using an output table
  2. Displaying a list.

First, use the same login procedure from of Obtaining the Azure Tenant ID through the CLI

Method A

i – Create an output table for the information

az account list --output table

ii – Display the table

$ az account show --subscription "" | jq -r '.tenantId' 
942b80cd-????-42a1-????-4b21dece61ba <-- Directory ID $

or

Method B

$ az account list | jq -r '.[].tenantId' 

A few accounts are skipped as they don't have 'Enabled' state. Use '--all' to display them. 
942b80cd-????-42a1-????-4b21dece61ba 
942b80cd-????-42a1-????-4b21dece61ba 
942b80cd-????-42a1-????-4b21dece61ba 
$

4. Getting the Azure resource group

The Azure resource group is called the Resource group in the Azure interface.

The information is found on the same screen as the Subscription ID.

This value is a string value assigned by whoever configured the Resource group.

The location of the Resource group in Azure

5. Azure client ID and Azure client secret

An Azure Active Directory application must be created to generate the Azure client ID and the corresponding Azure client secret, or Key as it is referred to in Azure. The complete instruction can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal.

Keep the following in mind when you get to the part about making a New application registration:

  • The Application type has two options. Choose Web app/API
  • The Sign-on URL has the asterisk commonly associated with a required field, but this is not applicable in this case. Put in any valid URL in the field to complete the form and enable the Create button.

The instructions show you how to find/create the two needed values, but different names are used.

  • The field in the FortiGate interface called Azure client ID refers to the Application ID in Azure
  • The field in the FortiGate interface called Azure secret refers to the Key for the application.

  6. Configuring the FortiGate

Once you have collected all of the values, enter them into the Fabric Connector form. It should look like this:

Security Fabric connector form with fields filled in

To do it through the CLI, create an sdn-connector and set the collected variables.

config system sdn-connector 
  edit "SF-connector1" 
    set status enable 
    set type azure 
    set tenant-id "942b8dece61ba" 
    set subscription-id "4f27e2f9a" 
    set client-id "f66db0755" 
    set client-secret ENC cqAmO4/dcZJ4wyAZOQ== 
    set resource-group "grp001" 
    set azure-region global 
    set update-interval 60 
  end 

Verification of permissions on the application

At the end of Azure’s documentation for registering the app, there is a section on  Assign application to role. Be sure to do this as well.

  7. Tagging resources

In preparation for showing how to create a dynamic address, an instance of a Linux system was created and tagged with the Name “Owner” and the value “test”. To do this for your own resources:

  • Select the resource
  • Go to the Overview
  • In the Overview section, edit the Tags.

You can create customized tag names and you can have more than 1 tag associated with a resource.

 Configuring the tags of a resource

  8. Creating an address

In order to confirm that the connector has been successfully configured, you need to have a Fabric Connector Address.

  • The address or address group is used for source/destination of firewall policies. The Address is based on IP addresses. The address contains address(es) within the Azure instance.
  • When changes occur to addresses in the Azure environment, the Fabric 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.
  • As instances that match the filter appear in the environment, changes are propagated to the firewall policies that use the address object.

Configuring one of these addresses is similar to configuring any other address object, but with a few different options.

  • Go to Policy & Objects > Addresses
  • Give the address a name
  • For the Type field, select Fabric Connector Address from the drop-down menu
  • For the Fabric Connector Type select Microsoft Azure from the drop-down menu
  • Input a filter into the Filter field
  • Set the Interface to a specific port or leave it at the default “any”
  • Add any Comments or Tags that are applicable
GUI configuration of a Fabric Connector Address

The CLI version of the same address would be:

config firewall address 
  edit "azure-client" 
    set type dynamic   
    set comment ''   
    set visibility enable   
    set associated-interface ''   
    set color 0   
    set sdn azure   
    set filter "tag.Owner=test" 
  next 
end

Filters

Tags are not the only option to filter the address. The Azure Fabric Connector supports the following filters:

  • vm=
  • securitygroup=<nsg id>
  • vnet=<virtual network id>
  • subnet=<subnet id>
  • vmss=
  • tag.<key>=<value>

Just like the tag value, these properties are found in the Azure interface

9. Dynamic address in a Policy

A dynamic address can be used in a policy just like any other address object, though they do have a different icon to show that they are a Fabric Connector Address. Fabric Connector Address used in an IPv4 Policy

That same policy looks like this in the CLI:

config firewall policy 
  edit 0 
    set name "outgoing1"   
    set srcintf "port2"   
    set dstintf "port1"   
    set srcaddr "azure-client"   
    set dstaddr "all"   
    set action accept   
    set schedule "always"   
    set service "ALL"   
    set logtraffic all   
    set logtraffic-start enable   
    set capture-packet enable   
    set nat enable 
  next 
end

Result

By using the FortiGate Fabric Connector for Azure, the configuration of the FortiGate’s policies is not dependant on the IP addresses of the resources connecting to it. The entire environment could be moved to a new Azure location on a different continent with different public IP addresses, even for internal resources. After the move, no reconfiguration needs to take place. Everything works just as it did before the move.

Bruce Davis

Bruce Davis

Technical Writer at Fortinet
Bruce has been working with computers, and related technology, since before the World Wide Web was a thing. He has worked in system and network administration. He has even dabbled in technical support. He has made the switch to technical writing as part of his deep, dark and dastardly plan to make the arcane machinations of IT technology more easily understood by the poor folks who use it.
Bruce Davis

Latest posts by Bruce Davis (see all)

Facebooktwittergoogle_pluslinkedinFacebooktwittergoogle_pluslinkedin
  • Was this helpful?
  • Yes   No