If you own an environment in Azure Cloud and you are using a FortiGate to secure that traffic, it might be a good idea to configure an Azure SDN Connector and use dynamic objects instead of manually created ones. There is an official Fortinet documentation, which is great, but it doesn't cover all tricky aspects.

Azure configuration

How to deploy FGT HA in Azure Cloud I described in the previous entry. Now it's time to bring SDN into play!

To connect FortiGate with an Azure environment, we need an intermediate app which will be acting as a connector, giving access to specified resources (or whole subscription). To create that application, go to the App Registrations service and create a New Registration and configure as follows:

  • name: <ANY NAME>
  • account type: leave default, which is My organization directory only
  • Redirect URL: leave Web type and put any valid HTTPS address. It can be a localhost, or as you can see in below example, - it's not important and won't affect any further steps.

Once applicaton is created, we need to note down 2 values:

  • Applicatin (client) ID
  • Directory (tenant) ID

The last missing element is the secret key. You can generate one in tab Certificates and Secrets (1). Just generate it as below (2), save the value, and new entry should appear (3).

NOTE: remember to put a reminder in the calendar if the key has an expiration date.

The last step is to give your connector app access to the resources it requires. In my example, access to all subscriptions was required, so I created a new Access control (IAM) entries for both subscriptions. All permissions will be inherited downstream to the Resource Groups, Virtual Networks, Network Security Groups, VMs, etc. To do it, just go to the Access control (IAM) tab of your subscription and add a new Role Assignment selecting:

  • contributor: your app name. In my case it's FortiGate_Connector
  • Role: select two: Network Contributor and Virtual Machine Contributor

Below you can see a picture for the Network Contributor. Make sure, hat Virtual Machine Contributor role is granted as well.

FortiGate configuration

On the FortiGate side, you have to create an Azure SDN Connector. Go to the Security Fabric --> Fabric Connectors --> Create New and choose Microsoft Azure. Now you have to provide details from Azure Cloud, which we noted down earlier:

  • Azure tenant ID: it is an Azure value called Directory (tenant) ID
  • Azure client ID: it is an Azure value called Application (client) ID
  • Azure client secret: it is a security key, we generated earlier under the Certificates and Secrets tab

Proper configuration below:

However, you might be tempted to provide Azure Subscription ID and Azure Resource Group. You can, it's not a crime. Just be aware, that providing those information works like a filter. It will limit your application to just one subscription or even one resource group. I have those field empty and if you are not planning to limit yourself to resource group or subscription, just disable below settings:

Upon a successful configuration, the connector should create and change its status to UP:

NOTE: You can have only 1 Azure Connector. Multiple entries for AWS, Azure, GCP, NSX, OCI, and OpenStack types are disallowed with FortiOS 6.0.4.

Firewall Policies

Once you have SDN Connector configured and it can communicate with Azure, now it's time to create firewall objects. Create a new firewall object, but this time during its creation, choose:

  • Type: Fabric Connector Address
  • Fabric Connector Type: Microsoft Azure

Next, you have to populate a filter field. Possible firewall object filters are:

vm=<virtual machine>
securitygroup=<nsg id>
vnet=<virtual network id>
subnet=<subnet id>
vmss=<virtual machine scale set>

Each value/ID is just a name of that object. So if you have a subnet called, myTestSubnet, then a proper filter will be subnet=myTestSubnet. Simple as that.

Once you add an object, wait a few seconds for Connector to obtain information from Azure Cloud and refresh a view. Hover your newly created object and all associated IP addresses will appear. Use this object in your firewall policy and don't worry that IP address of a VM might change on its way. The object will be updated automatically.

NOTE: Have you noticed on the above screenshot that VNet object has a list of IP addresses with mask /32 instead of a whole VNET range? This is the expected behavior. When you define an object which is filtered by Subnet or VNet, all IP addresses in that Subnet or Vnet are forming a firewall address object. That's why it's dynamic. If you add a new network to the VNet and new VMs, it will be reflected in FortiGate's configuration within 1 minute (default settings).

Now you are ready to use your dynamic objects in firewall policies. Have fun :-)


Scenario 1

The connector is down - you provided incorrect details while configuring FortiGate connector. It has nothing in common with Access control (IAM). Double check:

  • Tenant ID
  • Client ID
  • Client Secret

Scenario 2

The connector is up, but ALL your firewall objects are not resolving - you receive an error: Unresolved Fabric Connector address. The problem is with Azure Roles. Double check that your connector app has both roles: Network Contributor and Virtual Machine Contributor.

Scenario 3

The connector is up, but SOME your firewall objects are not resolving - you receive an error: Unresolved Fabric Connector address. As you have access to some resources, most probably you limited your connector application on FortiGate. Verify that your connector is not limited only to a specified Subscription or a single Resource Group.

Troubleshooting commands

Connector status:

FGT # diagnose sys sdn status Azure_Connector
SDN Connector                       Type      Status
Azure_Connector                     azure     connected


FGT # diagnose test application azd ?
1. show HA stats
2. SDN api test
3. HA api test
4. filter list test
5. show endpoint meta-data
99. restart