FortiNet SDWAN connection in azure Hub and spoke

Hello @sidhrane

Yes, you can deploy FortiGate SD-WAN in a traditional Azure hub-and-spoke architecture without Azure Virtual WAN. Microsoft explicitly supports third-party NVAs/SD-WAN appliances in hub-and-spoke designs, including replacing Azure Firewall with an NVA.

For your questions:

1. Can FortiGate SD-WAN run in a normal hub-and-spoke architecture?

Yes. A typical design would be:

The FortiGate can be deployed as the central NVA/firewall in the hub, with spoke subnet UDRs steering traffic through it. Azure doesn't require Virtual WAN for this architecture.

For production, I would deploy the FortiGate tier in an HA design rather than as a single appliance.

2. Is Azure Route Server mandatory between ExpressRoute Gateway and FortiGate?

Not strictly for every design, but there's an important distinction.

If you're willing to maintain static UDRs, you can build a FortiGate-based hub-and-spoke topology without Azure Route Server.

However, if the requirement is for the FortiGate and ExpressRoute Gateway to exchange BGP routes dynamically, Azure Route Server is the Microsoft-native solution.

The design becomes:

Azure Route Server establishes BGP peering with the FortiGate NVA and can exchange routes with the ExpressRoute gateway. To exchange routes between the NVA and the ExpressRoute Gateway, enable branch-to-branch/route exchange on Route Server.

Without that feature enabled, Route Server doesn't propagate routes between the NVA and ExpressRoute Gateway.

For an SD-WAN environment where routes can change dynamically, I would favor FortiGate + BGP + Azure Route Server rather than maintaining large numbers of static UDRs.

Another routing detail worth planning carefully: when Azure learns equal-length prefixes through both ExpressRoute and the NVA, ExpressRoute routes take precedence. That can affect the intended SD-WAN path and traffic symmetry.

3. Does FortiGate need a separate interface for ExpressRoute?

Not necessarily. The ExpressRoute Gateway isn't normally connected directly to a dedicated FortiGate interface like two physical routers connected by an Ethernet segment.

With Azure Route Server, the routing relationship is established through BGP:

Azure Route Server handles the control-plane route exchange; it doesn't carry the actual data traffic. Data traffic continues directly between the NVA and its destination.

So you shouldn't design this as though the FortiGate needs an "ExpressRoute interface" connected directly to the ExpressRoute Gateway.

Instead, design the FortiGate interfaces around its security and traffic-flow requirements, typically external/untrusted and internal/trusted interfaces, plus HA/management interfaces depending on the Fortinet deployment model.

For your intended design, I would start with:

Then use BGP/Route Server and/or appropriate UDRs to make sure spoke-to-on-premises traffic traverses the FortiGate when inspection is required.

One caution: don't simply replace Azure Firewall with FortiGate and reuse all existing UDRs without reviewing the forward and return paths. NVAs are particularly sensitive to asymmetric routing, and combining ExpressRoute-learned routes, Route Server routes, gateway propagation, and spoke UDRs can unintentionally bypass the firewall.

Microsoft has a very relevant document covering this exact class of design, including SD-WAN coexistence with ExpressRoute:

Azure Route Server – Route injection in spoke VNets and SD-WAN coexistence

Azure Route Server support for ExpressRoute and VPN Gateway

Azure hub-and-spoke network topology

So, in short: yes to a standard hub-and-spoke; no, Route Server isn't universally mandatory; but for dynamic BGP exchange between FortiGate SD-WAN and ExpressRoute, I recommend Route Server.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.