FortiGate Meets Azure: Securing the Hub-and-Spoke Edge

Plenty of organisations have standardised on Fortinet across their estate — and when they move into Azure, they (reasonably) want the same firewall, the same policy model, the same single pane of glass. The trick is making a FortiGate feel native in a cloud built around hub-and-spoke.

The shape of it

The FortiGate sits in the hub, inspecting traffic between spokes and out to the internet. Two patterns do most of the work:

• User-defined routes (UDRs) point spoke traffic at the firewall’s internal load balancer.
• An active-passive or active-active pair behind Azure load balancers keeps it from being a single point of failure.

spoke-a ─┐
spoke-b ─┼──▶ UDR ──▶ [ FortiGate HA pair ] ──▶ internet / on-prem
spoke-c ─┘                   (hub vnet)

What bites you

The failover behaviour is the whole game. Test it before go-live, not during an incident.

The two things I always validate: that the SDN connector is updating route tables on failover, and that asymmetric routing isn’t quietly black-holing return traffic. Get those right and you’ve got Fortinet’s policy engine doing the heavy lifting, sitting comfortably inside an Azure design that scales.