README.md

Deployment templates for FortiGate Next-Generation Firewall in Microsoft Azure

Use cases

The FortiGate can be used in different scenario's to protect assets deployed in Microsoft Azure Virtual Networks.

• Secure hybrid cloud
• Cloud security services hub
• Logical (intent-based) segmentation
• Secure remote access

Click here for a general overview of the different public cloud use cases.

Deployment options and architectures

When designing a reliable architecture in Microsoft Azure it is important to take resiliency and High Availability into account. Microsoft has the Microsoft Azure Well-Architected Framework available.

Running the FortiGate Next-Generation Firewall inside of Microsoft Azure can offer different levels of reliability based on the different building blocks and architectures. Over the years, new functionality has been released in Microsoft Azure for specific deployments.

For each architecture/building block, there is information in the table whether it is supported (yes) by each architecture or not (no). Take into account that each architecture has requirements and limitations that are listed on their respective page.

Use cases/ Architectures	Single FGT	Active Passive SDN	Active Passive ELB/ILB	Active Active ELB/ILB	Virtual WAN	Active Passive Azure Route Server	Auto-Scale Cluster	Gateway Load Balancer
North-South (ingress) filtering	YES	YES	YES	YES	YES	YES	YES	YES
East-West filtering	YES	YES	YES	YES	YES	YES	YES	NO
South-North (egress) filtering	YES	YES	YES	YES	YES	YES	YES	YES
SDWAN	YES	YES	YES	YES	YES	YES	YES	NO
Site to Site VPN	YES	YES	YES	YES	YES	YES	NO	NO
Client to Site VPN	YES	YES	YES	YES	YES	YES	NO	NO
Express Route Filtering	YES	YES	YES	YES	YES	YES	YES	NO
Scalability - vertical	YES	YES	YES	YES	YES	YES	YES	YES
Scalability - horizontal	NO	NO	NO	YES	YES	NO	YES	YES
Protect resources in multiple regions	YES	YES	YES	YES	YES	YES	YES	YES

SLA

Microsoft offers different SLAs on Microsoft Azure based on the deployment used.

• Availability Zone (different datacenter in the same region): 99,99%
• Availability Set (different rack and power): 99,95%
• Single VM with Premium SSD: 99.9%

Building blocks

• A Single VM: This single FortiGate VM will process all the traffic and as such become a single point of failure during operations as well as upgrades. This block can also be used in an architecture with multiple regions where a FortiGate is deployed in each region. This setup provides an SLA of 99.9% when using a Premium SSD disk.

More information can be found here

Active/Passive with external and internal Azure Load Balancer: This design will deploy 2 FortiGate VMs in Active/Passive connected using the unicast FGCP HA protocol. The failover of the traffic in this setup is handled by the Microsoft Azure Load Balancer using a health probe towards the FortiGate VMs. THe failover times are based on the health probe of the Microsoft Azure Load Balancer (2 failed attempts per 5 seconds with a max of 15 seconds). The public IPs are configured on the Microsoft Azure Load Balancer and provide ingress and egress flows with inspection from the FortiGate. Microsoft provides some guidance on this architecture here.

More information can be found here

Active/Passive with Fabric Connector Failover: This design will deploy 2 FortiGate VMs in Active/Passive connected using unicast FGCP HA protocol. This protocol will synchronize the configuration. On failover the passive FortiGate takes control and will issue api calls to Microsoft Azure to shift the Public IP and update the internal User Defined Routing (UDR) to itself. Shifting the public IP and gateway IPs of the routes will take some time to complete on the Microsoft Azure platform. Microsoft provides a general architecture here, in the FortiGate case the API calls logic is built in instead of requiring additional outside logic like Azure Functions or ZooKeeper nodes. Due to the faster failover times and easier management the Active/Passive with the Azure Load Balancer is the preferred building block compared to this one.

More information can be found here

Active/Active with external and internal Azure Load Balancer: This design will deploy 2 FortiGate VMs in Active/Active as 2 independent systems. The failover of the traffic in this setup is handled by the Microsoft Azure Load Balancer using a health probe towards the FortiGate VMs. The public IPs are configured on the Microsoft Azure Load Balancer and provide ingress and egress flows with inspection from the FortiGate. To sync the configuration of this setup a FortiManager or local replication can be used. Microsoft provides some guidance on this architecture here.

More information can be found here

By default these building blocks are using Availability Sets. The Availability Zone templates are also available here for a higher SLA.

Selecting your architecture in Microsoft Azure

The FortiGate Next-Generation Firewall can be deployed in Microsoft Azure in different architectures each with their specific properties that can be an advantage or disadvantage in your environment.

• Single VNET: All the building block above are ready to deploy in a new or existing VNET. Select your block above to get started.
• Cloud Security Services Hub (VNET peering): With VNET peering it is possible to have different islands deploying different services managed by diferent internal and/or external teams but to maintain a single point of control going to on-premise, other clouds or public internet. By connecting the different VNETs in a Hub-Spoke setup the Hub can control all traffic. Get started here
• Autoscaling: For application that are fluid in the amount of resources the FortiGate can also be deployed with a autoscaling architecture. This architecture is documented here or a quickstart script is available here.

Support

Fortinet-provided scripts in this and other GitHub projects do not fall under the regular Fortinet technical support scope and are not supported by FortiCare Support Services. For direct issues, please refer to the Issues tab of this GitHub project.

License

License © Fortinet Technologies. All rights reserved.

In memory of Jeroen Bismans, contributor to these fine templates. From diver to astronaut.