Fortinet SD-WAN Hub Placement Part 1: The Traditional Model — Hubs in the DC

6 June 2026 Fortinet SDWAN BGP Networking FortiManager

Every Fortinet SD-WAN design eventually asks the same question: where do the hubs go? For most of this blog’s history the answer has been implicit — “in the DC, obviously” — because the topologies discussed here (the SD-WAN Resilience series, the Arista deep dive) were all single-customer enterprise builds where the DC was the centre of gravity.

This series asks the question properly, starting from that traditional answer and working outward to the cases where it stops holding. Part 1 is the traditional model: why hubs sit in the DC, what job they actually do there, how they relate to FortiManager (FMG) and FortiAnalyzer (FAZ), and how BGP on loopback glues the whole thing together. Parts 2 and 3 then break the assumption — first by introducing an MSSP managing many customers from one FMG/FAZ pair, then by following hub placement out into the cloud and into SASE.

What a hub actually does

Strip away the marketing language and a Fortinet SD-WAN hub does three jobs:

Tunnel termination. It’s the FortiGate that spoke devices build IPsec overlays to — usually two or more per spoke for redundancy. Every spoke-to-spoke and spoke-to-DC flow that isn’t handled by a direct path (ADVPN shortcuts aside) traverses a hub.
Routing anchor. It’s where the overlay (spoke loopbacks, BGP-advertised prefixes) meets the underlay routing of wherever it sits — the DC core, a DCE, a cloud VPC, or in MSSP land, a customer’s own infrastructure. Part 2 of the Resilience series covers the BGP mechanics of this in detail; we’ll come back to the highlights below.
Policy enforcement point. Firewall policy, security profiles, SSL inspection, and (in many designs) the egress point for centrally-steered internet and SaaS traffic all happen at the hub, not the spoke. Spokes are deliberately kept thin.

None of those three jobs requires the hub to be in a particular building. But in the traditional model, all three pull in the same direction: toward the DC.

Why the DC was the obvious answer

For a single-customer enterprise SD-WAN built any time in the last decade, putting the hub in the DC was close to a forced move, for reasons that compound:

That’s where the applications were. Before “the cloud” ate the application estate, the DC hosted the ERP, the file servers, the internal web apps, the print servers — everything branches needed to reach. A hub anywhere else would mean backhauling DC-bound traffic an extra hop for no benefit.
That’s where the security stack was. Centralised internet breakout through a DC-based perimeter — proxies, DLP, the works — was (and in plenty of shops still is) the compliance-mandated design. If the hub has to be the egress point for that stack, it has to be where the stack lives.
That’s where the network team’s hands already were. Racking another FortiGate next to the core switches, in the same cabinet as the existing perimeter kit, on the same management VLAN, is operationally trivial compared to standing up infrastructure somewhere new.
That’s where good connectivity already existed. MPLS tails, internet circuits, cross-connects to carriers — the DC had them, because that’s what DCs are for. A hub anywhere else needs its own equivalent, at extra cost.

Put those four together and “the hub goes in the DC” stops looking like a decision and starts looking like an inevitability. Which is exactly why it’s worth pulling apart now — because every one of those four reasons is a property of a particular era’s application landscape, not a law of SD-WAN design. Parts 2 and 3 are about what happens once that landscape changes.

The reference shape: dual hubs, dual DCs

The shape that recurs across this blog’s enterprise material — and that Fortinet’s own SD-WAN Architecture for Enterprise guide treats as the baseline — is a pair of hubs in a pair of DCs:

                +----------------------+
                |   DCE / App Stack    |
                +----+------------+----+
                     |            |
            +--------+---+  +-----+------+
            |  HUB-1     |  |   HUB-2    |
            |  (DC1)     |  |   (DC2)    |
            |  FMG-A *   |  |   * FMG-B  |
            +-----^------+  +-----^------+
                  | IPsec        | IPsec
                  |              |
            +-----+--------------+------+
            |        SPOKE-N            |
            +---------------------------+

Two hubs, two DCs, each spoke dual-homed. Whether the pair runs active/active or active/standby is a separate design decision (the Resilience series argues at length for active/standby in topologies without a DC interconnect) — but either way, both hubs sit in DC-class facilities, because that’s where the things they need to reach also sit.

Notice something else in that diagram: FMG-A and FMG-B sit next to the hubs, one per DC. That’s not an accident, and it’s the next thing worth pulling apart.

Hubs and the FMG/FAZ relationship

FortiManager and FortiAnalyzer are the management and logging backbone of any non-trivial Fortinet estate — they push configuration to every managed FortiGate and ingest logs from every one of them. In a single-customer design, that means every spoke has to reach FMG and FAZ, for:

Initial provisioning and ongoing template pushes (FMG talks to the FortiGate’s management daemon over a TCP session, typically port 541).
Log forwarding (FAZ ingests over OFTP/syslog-equivalent, typically TCP 514 or the encrypted FortiGate-to-FortiAnalyzer protocol depending on version and config).
Registration and licensing handshakes, which in many designs are also brokered through FortiManager acting as a local FDS.

That’s a lot of branch-to-management-plane traffic, multiplied by however many spokes you have, all day, every day. Two placement questions follow immediately:

Where do FMG/FAZ sit, and how does the hub protect them?

The traditional answer: FMG and FAZ live in the DC, behind the hub — meaning the hub’s firewall policy is the thing standing between every spoke and the management plane. That gives you:

A single enforcement point for management-plane access. Spoke-to-FMG and spoke-to-FAZ traffic is firewall policy on the hub like any other flow — source the spoke subnet, destination the FMG/FAZ subnet, service set to the specific ports needed, logged, and (in security-conscious designs) wrapped in IPS and application control even for “trusted” management traffic. Compromise of a branch device doesn’t get a free pass to the management plane just because the traffic is “internal”.
A natural place to rate-limit and shape. Log floods from a misbehaving FortiGate (a classic failure mode — a spoke stuck in a reboot loop generating thousands of session-start/session-end log entries a second) hit the hub’s policy and queueing before they hit FAZ’s ingest pipeline. That protects FAZ’s disk and indexing from a single noisy neighbour.
Topological symmetry with everything else. FMG and FAZ become “just another DC subnet” from the spoke’s perspective — reachable the same way, through the same overlay, governed by the same routing and the same policy model as the application stack. No special-cased paths to remember or document.

The dual-DC version of this — FMG-A/FAZ-A in DC1, FMG-B/FAZ-B in DC2, in HA — also means the management plane survives the same DC failure that the hub-pair design is built to survive. A spoke that fails over from HUB-1 to HUB-2 doesn’t just keep its data path; it keeps its management and logging path too, because both follow the same active/standby logic.

What does the hub need to permit, specifically?

At minimum, firewall policy on the hub needs to allow, from every spoke subnet (and from the spoke’s own loopback/management interface, usually a separate source object) to the FMG/FAZ subnet:

TCP/541 (FGFM — FortiGate-to-FortiManager management protocol)
TCP/514, UDP/514, and/or TCP/6514 depending on your FAZ logging configuration (plaintext syslog vs. encrypted OFTP-over-TLS — encrypted is the only sane choice for anything leaving a branch)
TCP/443 if FortiManager is acting as a local update/registration broker (FDS proxy mode)

None of that is exotic. The point worth dwelling on is that it’s firewall policy on the hub, which means it lives in exactly the same change-control, review, and template-push pipeline as every other policy on the box — which is precisely the appeal of putting the hub (and therefore FMG/FAZ protection) in one predictable place.

BGP on loopback: the glue that makes “in the DC” work cleanly

None of the above works without a routing design that gets spoke traffic to the hub, and hub-local traffic (including FMG/FAZ) advertised back out to spokes, in a way that survives tunnel re-establishment and hub failover without manual intervention. That’s what BGP on loopback solves, and it’s covered in full in SD-WAN Resilience Part 2 — this is the short version, framed around why it matters for hub placement specifically.

The headline reasons loopback peering matters here:

Tunnel-interface IPs move; loopbacks don’t. Mode-config hands a spoke a different tunnel IP every time the tunnel re-establishes. If BGP peers on that address, every flap is a reconfiguration event. Peer on a static loopback instead and the BGP relationship survives the flap untouched.
The hub’s own services — including FMG/FAZ’s subnet — get advertised the same way as everything else. Once the hub is doing next-hop-self and redistributing the DC-side prefixes (static, OSPF, or eBGP to the DCE — Part 3 of the Resilience series walks through the trade-offs), FMG/FAZ reachability is just another route in the table. No special tunnel, no separate VPN, no manual static routes to remember per spoke.
It makes hub placement portable, in principle. Here’s the detail that sets up the rest of this series: BGP on loopback doesn’t actually care where the hub physically is. The loopback is a /32 on a virtual interface; the peering runs over an IPsec overlay; the only thing that has to be true is that the hub can reach, and be reached by, the things on either side of it. Put the hub in a different building, a different cloud region, a different country — the BGP design doesn’t change. What changes is everything around it: latency to the things it serves, the underlay it sits on, who operates the facility it’s in.

That portability is the seed of everything that follows. The traditional model bundles “where the hub does its routing and policy job” with “where the hub physically sits, in a DC, next to the apps and the management plane.” BGP on loopback is part of why that bundle could be pulled apart — the routing design genuinely doesn’t mind where the hub lives. Whether anything else minds is the subject of Parts 2 and 3.

Where the traditional model starts to creak

Even within a pure single-customer enterprise context — before any MSSP or cloud complications — the traditional “hub in the DC” model has known pressure points worth naming, because they’re the cracks that widen into the rest of this series:

The DC stops being where the apps are. The moment a meaningful share of the application estate moves to SaaS or to a cloud landing zone, “backhaul to the DC, then break out” turns from “the compliant design” into “the design that adds two hops and a chunk of latency to traffic that was never going to touch the DC anyway.”
The DC becomes a single well-known target. Concentrating tunnel termination, policy enforcement, and the management plane in one or two buildings is operationally tidy and a tempting blast-radius for anyone targeting the estate. (This is an argument for good DC security, not against the model — but it’s a cost that’s easy to under-count when “put it in the DC” feels free.)
“The DC” stops being singular. Mergers, acquisitions, and plain old growth produce estates with two, three, or more DCs that didn’t start out as a single coherent design. The dual-hub/dual-DC shape in this post assumes the two DCs were planned as a pair. Reality is often messier.

Each of those pressure points has a clean answer inside the traditional model — better DC security, more DCs, careful steering policy. None of them, on their own, force you to rethink where the hub belongs.

What does force that rethink is a change in who the hub serves, and where the things it serves actually live. That’s Part 2: the MSSP case, where one FMG/FAZ pair manages dozens of customers through ADOMs, and the question “where does the hub go?” stops having a single, shared answer at all.

What’s next

Part	Topic
1 (this post)	The traditional model — hubs in the DC, the FMG/FAZ relationship, BGP on loopback as the connective tissue
2	The MSSP shift — multi-tenant FMG/FAZ via ADOMs, and why hubs become customer-centric
3	Placement in practice — cloud (Azure/AWS/GCP) and the migration from DC-centric to SASE-centric designs

Part 2 starts from a simple observation: an MSSP’s FMG/FAZ pair doesn’t serve one estate, it serves many — and the moment that’s true, “put the hub where the apps and the management plane are” stops being a single answer and starts being a per-customer design exercise.