Here is a recap of some of the reflections I have with deploying Fortinet's FortiGate appliance on Azure. This is more of a reflection of the steps I took rather than a guide, but you can use the information below as you see fit.  At a high level, you will need to deploy the device on Azure and then configure the internal “guts” of the device to allow it to route traffic properly on your Virtual Network (VNet) in Azure. While Fortinet does have some documentation on deploying their appliance, I found it very confusing, so I hope this helps walk through deployment. At the time of writing this, v6.2 was the latest version; however I recommend using at least version 6.0 or greater as it provides support for auto-scaling, which is what we will be looking at for this guide.

First, just want to provide a quick overview of the different options you can take and a rough overview of each architecture:

• Single FortiGate (One VM, easiest to deploy, but is not highly available)
  • https://azuremarketplace.microsoft.com/en-us/marketplace/apps/fortinet.fortinet-fortigate-singlevm?tab=Overview
  • Docs: https://docs.fortinet.com/vm/azure/fortigate/6.2/azure-cookbook/6.2.0/632940/single-fortigate-vm-deployment
• HA FortiGate in Active/Passive mode (Two VMs with a public IP that gets manually attached to a given instance and updates to route tables)
  • Notes: Fortinet in active/passive deployment requires the modification of UDRs and Public IPs. Please note, any manipulation of UDRs or public IPs for Active/Passive solutions can take about 30 seconds to be applied after the failover is initiated. This deployment typically contains 4 IPs on each appliance, one used for external traffic, another for internal traffic, a third for heartbeat traffic, and a fourth for management traffic.
  • Docs: https://docs.fortinet.com/vm/azure/fortigate/6.2/azure-cookbook/6.2.0/227656/deploying-and-configuring-active-passive-ha-between-multiple-zones
• HA FortiGate in Active/Active mode (Two VMs load balanced by Azure Load Balancer for high availability; a little more complex to manage; sometimes called the "load balancer sandwhich")
  • https://azuremarketplace.microsoft.com/en-us/marketplace/apps/fortinet.fortigatengfw-high-availability?tab=Overview
  • Docs: https://docs.fortinet.com/vm/azure/fortigate/6.2/azure-cookbook/6.2.0/983245/ha-for-fortigate-vm-on-azure
• Auto-scaling FortiGate (most complex architecture, cannot be deployed from Azure Marketplace, but most scalable)
  • Docs: https://docs.fortinet.com/vm/azure/fortigate/6.2/azure-cookbook/6.2.0/161167/deploying-auto-scaling-on-azure
  • Note: As of 8/20/2019 - the only downside to this deployment method is BYOL isn't officially supported yet (you must use Pay as you go (PAYG) licensing) and this mode will not let you easily establish VPN connections to the appliance vs Azure VPN Gateway. If using this deployment strategy, I would recommend pairing it with Azure's VPN Gateway to handle VPN connectivity.
  • Note: As of 8/20/2019 - I don't believe this deployment works for Azure's sovereign clouds. The image for the FortiGate appliance is only up to v6.1.0 in Azure Government Cloud and I don't see a way to specify within the FortiGate that it needs to use the Government Cloud APIs. You would need to manually modify the templates and work with Fortinet to ensure the images work for Azure's sovereign clouds. In this case, I would recommend deploying the HA FortiGate in Active/Active mode listed above.

Deploy the Appliance in Azure

As part of this tutorial, we will look at FortiGate's Autoscaling deployment as this will allow us to dynamically scale up or down depending on load. In addition, this deployment will provide us high availability, so in the event we lose a VM, network traffic will automatically failover to another appliance.

Architecture

Deployment

1. Login to the Azure Portal
   1. https://portal.azure.com
2. Create two new Resource Groups
   1. Navigate to All services -> Resource Groups
   2. Click Add 
   3. Create two new resource groups with the following names (they can be different if you wish, but you will need at least 2)
      1. Fortigate-Handler-RG
      2. Fortigate-VMSS-RG
3. Create a Service Principal
   1. Navigate to All services -> Azure Active Directory
   2. Select App registrations
   3. Click New Registration
      1. Name: Fortigate-NVA
      2. Supported account types: Accounts in this organizational directory only
      3. Redirect URI: leave blank
   4. Click Register
   5. Write down the Application (client) ID, Directory (tenant) ID, and Object ID.
   6. Click on Certificates & secrets
   7. Click on the New client secret button and set the description to Fortigate-NVA, set the password expiry to your preference and click Add
   8. Write down the value of your client secret
      1. Note: once you navigate away from the blade you won't be able to retrieve it again
4. Delegate the Service Principal
   1. Navigate to All services -> Subscriptions -> select your subscription -> and select Access control (IAM)
   2. Click Add, Add role assignment, and use the following configuration
      1. Role: Owner
      2. Assign access to: Azure AD user, group, or service principal
      3. Select: Search for Fortigate-NVA and select it
   3. Click Save
      
      
      1. Note: I didn't have a chance to test, but I think these permissions could likely be delegated down at the resource group level vs subscription.  If someone could confirm, please leave a comment below.
5. Deploy the Fortigate Handler (CosmosDB and Function App)
   1. 
   2. Once you click the button above to deploy the template, use the following configuration
      1. Function App Name
         1. This is the name of the Azure Function resource that gets created.  This must be globally unique across all customers within Azure.
      2. Cosmos DB Name
         1. Name of the Cosmos DB that will be created. This field must be between 3 and 31 characters and can contain only lowercase letters, numbers and -.  This value should be globally unique across all customers within Azure.
      3. Storage Account Type: Standard_LRS
      4. Tenant ID
         1. Use the Directory (tenant) ID from the Service Principal we created earlier.
      5. Subscription ID
         1. Enter the subscription ID to the Azure Subscription you wish to deploy to.  You can find your subscription ID by navigating to All services -> Subscriptions and selecting your subscription.
      6. Rest App ID
         1. Use the Application (client) ID from the Service Principal we created earlier.
      7. Rest App Secret: iW8gS...........................pMX
         1. Use the value you wrote down when generating the Client Secret when creating the Service Principal.
      8. Heart Beat Loss Count: 3
         1. Number of consecutively lost heartbeats. When the heartbeat loss count has been reached, the VM is deemed unhealthy and failover activities commence.
      9. Scaling Group Resource Group Name: Fortigate-VMSS-RG
         1. This is the value of the secret Resource Group you created at the beginning of this guide.  This Resource Group will contain the VM Scale Set and it's corresponding resources.
      10. Script Timeout: 230
          1. This is the timeout for the Function App script to run.  By default this is 230 seconds.
      11. Election Wait Time: 90
          1. This is the maximum time (in seconds) to wait for a master election for the FortiGate's to complete.
      12. PSK Secret: mysupersecretpassphrase
          1. This is a random string of characters used by the FortiGates in the scale set to synchronize configuration items.
      13. Package Res URL: https://github.com/fortinet/fortigate-autoscale/releases/download/1.0.3/fortigate-autoscale-azure-funcapp.zip
          1. Grab the latest version of the package for the Azure Function App from GitHub.  You can find the latest compiled versions here: https://github.com/fortinet/fortigate-autoscale/releases
6. Deploy the VM Scale Set
   1. 
   2. Once you click the button above to deploy the template, use the following configuration
      1. Instance Type: Standard_F2
      2. FOS Version: 6.2.1
      3. VNet New Or Existing: new
         1. Select whether you wish to use an existing or new Virtual Network
      4. VNet Name: AzureHubVNet
         1. The name of the VNet to be used or created.
      5. Subnet Address Prefix: 10.0.0.0/16
         1. The address space of the VNet to be used or created.
      6. Subnet1Name: Untrust
         1. The name of the subnet that will be public facing to the internet.
      7. Subnet1Prefix: 10.0.1.0/24
         1. The address space of the subnet to be created for the public facing zone.
      8. Subnet2Name: Trust
         1. The name of the subnet that will contain the private NICs of the FortiGate's.
      9. Subnet2Prefix: 10.0.2.0/24
         1. The address space of the subnet to be created for the private facing zone.
      10. Subnet2Load Balancer IP: 10.0.2.10
          1. The IP address of the load balancer in the private zone.
      11. Subnet3Name: Private
          1. The name of the subnet that will contain the private machines that are behind the FortiGate appliance.
      12. Subnet3Prefix: 10.0.3.0/24
          1. The address space of the subnet that will contain the private machines that are behind the FortiGate.  Note: this is more of a place holder in FortiGate's template, you can create additional subnets later on/use a different subnet for your private resources.
      13. Public IP New or Existing: new
          1. The Public IP address to be associated as the VIP of the Azure Load Balancer for incoming traffic.
      14. Scaling Group Name Prefix: fgtasg
          1. The prefix each VMSS Name is given when deploying the FortiGate autoscale template. The value of this parameter should be the same as for deploy_funcapp.json. The prefix cannot contain special characters \/""[]:|<>+=;,?*@& or begin with '_' or end with '.' or '-'.
      15. Initial Capacity: 2
          1. How many FortiGate's should be deployed.  Default value is 1, however I recommend at least 2 for high availability.
      16. Min Capacity: 2
          1. The smallest amount of FortiGate's that should be running.  Default value is 1, however I recommend at least 2 for high availability.
      17. Max Capacity: 3
          1. The max amount of FortiGate's that should be deployed.
      18. Scale Out Threshold: 80
          1. Percentage of CPU utilization at which scale-out should occur.
      19. Scale In Threshold: 20
          1. Percentage of CPU utilization at which scale-in should occur.
      20. Admin Username: azureadmin
          1. FortiGate administrator username on all VMs.
      21. Admin Password: azurepassword
          1. FortiGate administrator password on all VMs. This field must be between 11 and 26 characters and must include at least one uppercase letter, one lowercase letter, one digit, and one special character such as (! @ # $ %).
      22. Endpoint URL: https://yourfunctionappurl.azurewebsites.net
          1. This can be found by navigating to All services -> Function App -> YourFunctionApp -> URL on the overview blade.

At this point, your FortiGate deployment should be completed. When a FortiGate appliance comes up, it will reach out to the Azure Function to pull down its base configuration. Any changes to the primary FortiGate will be synchronized to any additional FortiGates deployed as well.

For those using a hub/spoke network, you will want to associate a UDR to each of your subnets to force traffic back to the internal load balancer's VIP. You can do this by creating a new Route Table, add a Route, set the next hop type to Virtual Appliance, and set the IP address to the IP address you specified for the "Subnet2Load Balancer IP".

You can connect to the primary FortiGate for management via web console on Port 8443 (https://IP.AD.DR.ESS:8443) or via SSH on Port 22.

References

https://docs.fortinet.com/vm/azure/fortigate/6.2/azure-cookbook/6.2.0/128029/about-fortigate-vm-for-azure