The centre manages. The edge enforces.
Traditional firewall WAN was built for a world where applications lived in the data centre and branch traffic naturally returned to headquarters for inspection. That world has changed. Microsoft 365, Teams, Azure, SaaS platforms, remote work and multi-site operations have moved the destination away from the central firewall — but in many environments, the traffic path has not changed with it. The result is a hairpin architecture that adds latency, creates bottlenecks, centralises failure and makes each branch dependent on one central inspection point. Secure SD-WAN changes the model: each site has local firewall and SD-WAN enforcement, traffic is inspected at the edge and breaks out directly to cloud applications, and policy remains centralised while enforcement is distributed. That is the architectural shift.
See what hairpin routing costsHairpin routing and Microsoft 365 and Teams performance; distributed branch security and central policy consistency; failover behaviour and resilience under link failure; cloud application latency and direct breakout design; new site deployment speed and underlay timing; the SASE upgrade path from a Secure SD-WAN foundation; operational scenarios across incidents, changes and deployments; and when traditional WAN still fits. Written for Australian multi-site organisations weighing a WAN architecture change.
The difference shows up in performance, security and operations.
The decision areas where the two architectures separate:
- Cloud application latency — hairpin traffic adds avoidable delay for Microsoft 365, Teams, Azure and SaaS.
- Branch security posture — traditional WAN relies on central inspection. Secure SD-WAN enforces policy at each site.
- Failover and resilience — traditional WAN failover is often carrier-dependent. Secure SD-WAN can shift traffic within seconds.
- New site deployment speed — MPLS provisioning can take 60 to 120 days per site. SD-WAN can bring sites online faster once underlay is available.
- Policy consistency — central policy pushed to distributed FortiGate devices reduces drift across sites.
- SASE upgrade path — Secure SD-WAN creates a stronger branch foundation for future SASE architecture.
Where the firewall lives is the whole question.
The traditional model was built for a different world. Applications lived in data centres. Traffic went from branch to headquarters, through the firewall, and on to the application. The destination was close to the firewall, so latency was acceptable.
When applications moved to the cloud, the destination changed but the architecture often did not. Branch traffic still travels to headquarters for inspection before reaching Microsoft 365, Azure or SaaS services, then returns the same way. That extra path adds avoidable latency to every transaction.
Secure SD-WAN removes the hairpin by inspecting traffic locally at each site and breaking out directly to cloud services. Security does not move to the edge at the expense of control. Policy is still managed centrally. It is just enforced at the edge rather than at one central choke point.
This is not simply a firewall replacement. It is a change in where firewall enforcement lives.
Traditional WAN centralises inspection. Secure SD-WAN distributes enforcement.
Traditional firewall WAN uses a centralised inspection model. A firewall sits at headquarters or in the data centre. MPLS or broadband circuits connect all branch sites back to that central point. All traffic from all sites passes through the central firewall before reaching its destination.
Security is enforced at the centre. Branch sites have no local security capability. One firewall failure can affect all sites.
This model can still be appropriate where the organisation is single-site, data-centre-first or running applications that genuinely live behind the central firewall.
Secure SD-WAN uses a distributed enforcement model. A combined SD-WAN and firewall device sits at every site. Each site inspects its own traffic locally and breaks out directly to cloud applications. Security policy is managed centrally through FortiManager and pushed to all devices simultaneously.
Site failure affects only that site.
There is no hairpin path and no central firewall bottleneck.
The hairpin is not a configuration problem. It is an architectural one.
Traffic routing through a central point for inspection was correct when applications lived at that central point. When applications moved to Microsoft 365, Azure, Salesforce and other cloud services, the routing path became a performance liability. Microsoft requires under 150ms one-way latency for acceptable Teams call quality, along with under 30ms jitter and under 1 percent packet loss. A Sydney headquarters firewall handling traffic for a Melbourne branch to Microsoft cloud services can consume much of that budget before congestion, jitter or packet loss are even considered.
- Melbourne branch sends traffic to the Sydney headquarters firewall
- The Sydney headquarters firewall inspects the traffic
- Traffic is forwarded to Microsoft Azure or the nearest Microsoft cloud edge
- The response returns through the Sydney headquarters firewall
- Traffic travels back to the Melbourne branch
- Melbourne FortiGate inspects traffic locally
- Traffic breaks out directly to Microsoft cloud from the closest viable path
- SD-WAN continuously monitors link quality
- Teams traffic is steered to the best current path
Where the architectures produce meaningfully different outcomes.
- Cloud latency — high; traffic hairpins through a central firewall before reaching cloud applications
- Branch security — no local inspection; branches rely on the central firewall
- Policy consistency — risk of drift; rules may differ by firewall, site or legacy change history
- Single point of failure — the central firewall can become a shared failure point for all sites
- Link failover — manual, carrier-dependent or slow; response can take minutes to hours
- New site deployment speed — MPLS circuit provisioning can take 60 to 120 days per site
- SASE path — usually requires WAN and firewall redesign
- Cloud latency — low; traffic breaks out directly from each site to cloud applications
- Branch security — full NGFW at every site, with local inspection and enforcement
- Policy consistency — central policy pushed to all sites simultaneously
- Single point of failure — distributed enforcement; a site failure affects only that site
- Link failover — automatic; backup links can take over within seconds
- New site deployment speed — zero-touch provisioning can bring new sites online in days once underlay is available
- SASE path — Fortinet SD-WAN can extend toward FortiSASE on an existing FortiGate architecture
The architectural difference becomes visible when something changes or fails.
Traditional WAN: link fails. Staff lose connectivity immediately. IT is notified through helpdesk tickets. The network team contacts the carrier and the SLA clock starts. Resolution depends on carrier response.
Typical operational result: 2 to 4 hours average carrier response and visible user impact.
Secure SD-WAN: link degrades. FortiGate detects the issue within seconds. Traffic automatically moves to the backup link, such as 4G, 5G or a secondary NBN service. Staff continue working. The event is logged and the operations team is alerted.
Typical operational result: no helpdesk ticket and no service interruption for users where failover is designed correctly.
Traditional WAN: malicious traffic from a branch reaches the central firewall. The firewall may block it at headquarters. The branch may already be compromised before central inspection detects the pattern. There is limited visibility at the edge.
Typical operational result: detection and response depend on central inspection, with less branch-level context.
Secure SD-WAN: FortiGate at the branch detects anomalous traffic at the edge. Traffic is blocked locally. FortiAnalyzer correlates the event with network logs. The alert is generated within minutes.
Typical operational result: the event is blocked at the branch before it becomes a wider network issue.
Traditional WAN: MPLS circuit is ordered. Provisioning can take 60 to 120 days. Operations may be delayed until the circuit is active. Interim connectivity may be less controlled.
Typical operational result: site deployment depends on circuit delivery, with security and performance compromises during the interim period.
Secure SD-WAN: FortiGate hardware is shipped to site. Staff connect the device. It authenticates with FortiManager and downloads its configuration. The site joins the SD-WAN fabric.
Typical operational result: the site can be operational in hours or days depending on underlay readiness, with consistent security policy from day one.
Traditional WAN: the change is logged. A central firewall rule is updated. Branch devices may inherit the change indirectly or require separate manual update. Confirmation of policy state across all sites can be unclear.
Typical operational result: update propagation may be inconsistent and audit evidence may be fragmented.
Secure SD-WAN: policy change is made in FortiManager. The update is pushed to all FortiGate devices across all sites. Deployment is confirmed centrally. Audit logs record who changed what, when and to which devices.
Typical operational result: all sites are updated consistently with a clear audit trail.
Secure SD-WAN is strong for cloud-first multi-site environments. It is not universal.
Secure SD-WAN is the better architecture for most Australian multi-site organisations running cloud applications. Traditional WAN remains appropriate in three scenarios.
The hairpin argument does not apply. If the application destination is the headquarters data centre, routing through headquarters is not a detour. It is the route.
When cloud adoption begins, the calculation changes immediately.
SD-WAN adds complexity without adding enough value in a single-site environment. The distributed enforcement benefit requires distribution. A single site running a centralised firewall is not a hairpin problem. It is an appropriate architecture for the environment.
Migrating the WAN architecture before mapping the application estate adds risk without clear benefit. The right sequence is to map the application dependencies, migrate or modernise the application where needed, then migrate the WAN architecture.
Doing both simultaneously obscures which change caused any problems that emerge.
The right architecture follows the application footprint, site count and operating model.
If most applications are cloud-based — Microsoft 365, Azure and SaaS — Secure SD-WAN wins on latency and operational fit. If most applications are still on-premises in a central data centre, traditional WAN may remain adequate. If the estate is mixed, Secure SD-WAN handles both better because routing and security can be policy-based per application class.
One site rarely justifies Secure SD-WAN. Two to three sites may justify it where resilience or cloud performance is a problem. The architectural benefits materialise at three or more sites and become commercially compelling at ten or more.
If yes, and there is evidence to prove it, traditional WAN may be working adequately. If no, or if the team is unsure, Secure SD-WAN centralises policy management and reduces drift structurally.
Many Australian cyber insurance renewals now require documented evidence of security controls at every location, not just headquarters. If the current architecture cannot demonstrate per-site security inspection, the insurance posture has a gap that Secure SD-WAN can address structurally.
If new sites are rare, traditional MPLS provisioning may be manageable. If new sites need to open monthly or faster, zero-touch SD-WAN provisioning is the architecture that keeps pace with MPLS lead times of 60 to 120 days per circuit in Australia.
Operating a national branch network as one managed environment.
A national distribution business operating 110+ branches and commercial sites across every Australian state required always-on connectivity. The network had grown site by site through expansion and acquisition. Managing 110+ fragmented connections had become operationally difficult. Security policy was inconsistent across locations. Troubleshooting was slow. Adding new sites meant adding more complexity to an already fragile topology.
A single SD-WAN fabric replaced the fragmented model across all 110+ locations. Consistent security policy and segmentation were enforced nationally from day one. Real-time visibility was established per site.
Figures from the engagement described above. This is the difference between adding another link and operating a national branch network as one managed environment.
The hairpin is not something to tune around. It is the architecture showing its age.
For Australian multi-site organisations running cloud applications, Secure SD-WAN is usually the right architecture and the comparison is not particularly close. The traditional firewall WAN model made sense when applications and firewalls lived in the same place. That is no longer how most organisations operate. Microsoft 365, Teams, SaaS platforms, remote users and hybrid work have changed the traffic pattern.
- Do not evaluate SD-WAN only as a bandwidth or carrier replacement project — the more important question is where security is enforced.
- Do not assume a traditional WAN is failing just because it is old — it may still fit single-site or data-centre-first environments.
- Do not deploy direct internet breakout without integrated branch security — cloud performance without local inspection creates a different risk.
- Do not separate SD-WAN and firewall ownership if incidents will cross both domains — split-vendor accountability slows resolution.
- Start with application footprint, site count, current firewall model and operational ownership — before selecting a platform, including the choice between Fortinet and Cisco Meraki.
The right answer is not to make the centre bigger. It is to move enforcement to the edge while keeping policy centralised.
If Teams quality drops at the branches while head office stays fine, the hairpin is already taxing every cloud transaction — the architecture, not the bandwidth, is the constraint.
Check where the architecture stands →The architectural shift is not about replacing a firewall. It is about deciding where the firewall lives.
WAN architecture decisions should follow the application footprint.
The right engagement starts by understanding where applications live, how traffic flows today, where inspection happens, what the current carrier position looks like and which operating model the organisation can support after go-live. The recommendation follows the current estate, application footprint, site count, security posture and managed operating model — not a carrier quote or hardware preference.
Branch topology, central firewall dependencies, MPLS or NBN estate, traffic routing, hairpin latency and direct cloud breakout readiness.
Microsoft 365, Teams, Azure, SaaS, legacy data-centre applications and latency-sensitive workloads.
FortiGate sizing, FortiManager architecture, security policy, application-aware routing, failover design, policy consistency and underlay strategy across NBN, business fibre, 4G/5G and Starlink — delivered through managed Fortinet SD-WAN where the platform fits.
Where centralised inspection still fits and where the architecture is limiting performance, security or resilience.
Site sequencing, parallel operation, rollback path, validation, MPLS decommission timing and the managed operating model before rollout.
Questions that come up before replacing a traditional WAN model.
What is the difference between Secure SD-WAN and traditional firewall WAN?
What is a hairpin architecture and why does it cause problems?
Does Secure SD-WAN replace a firewall?
What happens to security when a WAN link fails in a Secure SD-WAN deployment?
How does Secure SD-WAN handle Microsoft Teams performance?
Is Secure SD-WAN suitable for single-site organisations?
How long does a traditional WAN to Secure SD-WAN migration take?
Does Secure SD-WAN work with existing MPLS or NBN circuits?
When should an organisation keep a traditional firewall WAN?
Decide where security is enforced before you choose what enforces it.
A practical conversation about WAN topology, cloud application paths, branch security, underlay options, migration sequence and managed operation.
Discuss Managed SD-WAN