Secure SD-WAN vs traditional WAN
Traditional WAN designs often route branch traffic through a central firewall before it reaches applications. Secure SD-WAN lets routing and security enforcement operate at each branch, with policy managed centrally across the network.
The difference matters once a business relies on Microsoft 365, Teams, SaaS, cloud applications and several sites. We look at where traffic travels, where security controls apply and how the network behaves when a connection degrades or fails.
What changes when security moves to the branch?
A Secure SD-WAN design brings routing, path monitoring and firewall enforcement together at the branch edge. That can improve cloud connectivity and simplify security policy management, provided the network is engineered and operated well. The differences show up in these areas.
- Cloud application paths. Direct internet breakout can avoid unnecessary routing through a central location.
- Branch security. Firewalls and inspection controls can run at individual sites, with policy managed centrally.
- Network resilience. Application-aware routing can respond to measured path degradation as well as a complete connection failure.
- Policy consistency. Central configuration and security policy management can reduce differences between branch devices.
- New site deployment. Standardised configurations and remote provisioning can reduce repetitive deployment work once connectivity and site requirements are in place.
- Secure access. Branch security can work with identity-based access and cloud-delivered services, including SASE where required.
Where security enforcement happens
The centralised-firewall design made sense when most applications sat at headquarters or in a data centre. Branches connected to that environment through private or routed WAN services, and traffic was inspected at the central firewall before it reached internal applications or the internet.
As applications moved to Microsoft 365, Azure and other cloud services, many organisations kept the same routing pattern. Internet-bound traffic still travels through head office or a data centre before it reaches its destination.
That extra leg can add latency, load central infrastructure and make branch internet access depend on the central inspection point being available.
Secure SD-WAN takes a different approach. Branch devices apply firewall and routing policy locally, send cloud traffic over a suitable internet connection and stay under central management.
The aim is to put security controls where the applications and users need them, with one consistent policy across the environment.
Centralised inspection and distributed enforcement
Branches connect to a central location through MPLS, private WAN or internet connections. Traffic that needs inspection is routed through a shared firewall or security stack before it reaches its destination.
This works well where applications are centralised and the network already has the resilience, visibility and security controls it needs.
A central inspection point can become a dependency for branch internet access. Its capacity, connectivity, routing and availability affect the wider environment.
Secure SD-WAN can combine application-aware routing, path monitoring and next-generation firewall enforcement at each branch.
Internet and cloud traffic can break out locally, while private applications keep using the routes the business needs.
Policies are managed centrally and deployed to the relevant branch devices. Traffic is inspected according to the configured controls, including when the path changes.
This comparison is with the centralised-inspection model. Many traditional networks also run branch firewalls, automatic failover and central management.
What hairpin routing means for cloud applications
Hairpin routing happens when traffic travels through an intermediate location before it reaches its destination, even though a more direct path is available. A Melbourne branch, for instance, may send Microsoft 365 traffic through a Sydney head office firewall before it reaches Microsoft's network.
Pick a branch and a design to see where Microsoft 365 traffic travels before it reaches Microsoft's network.
Newcastle is close to Sydney, so the hairpin adds little distance. The bigger effects here are the load on the central firewall and the dependence on head office links staying up. Traffic from Brisbane travels about 733 km to the Sydney head office firewall before it heads to Microsoft, and the reply comes back the same way. That leg alone adds at least 7 ms to each round trip, and branch internet access depends on the central firewall and its links. Traffic from Melbourne travels about 713 km to the Sydney head office firewall before it heads to Microsoft, and the reply comes back the same way. That leg alone adds at least 7 ms to each round trip, and branch internet access depends on the central firewall and its links. Traffic from Adelaide travels about 1,162 km to the Sydney head office firewall before it heads to Microsoft, and the reply comes back the same way. That leg alone adds at least 11 ms to each round trip, and branch internet access depends on the central firewall and its links. Traffic from Perth travels about 3,291 km to the Sydney head office firewall before it heads to Microsoft, and the reply comes back the same way. That leg alone adds at least 32 ms to each round trip, and branch internet access depends on the central firewall and its links. Traffic from Townsville travels about 1,682 km to the Sydney head office firewall before it heads to Microsoft, and the reply comes back the same way. That leg alone adds at least 16 ms to each round trip, and branch internet access depends on the central firewall and its links. The Newcastle FortiGate inspects the traffic and sends it out over the branch’s own internet connection, so it reaches Microsoft’s network without the trip to Sydney. Where that entry point sits depends on the ISP’s routing, which is why we measure it. The Brisbane FortiGate inspects the traffic and sends it out over the branch’s own internet connection, so it reaches Microsoft’s network without the trip to Sydney. Where that entry point sits depends on the ISP’s routing, which is why we measure it. The Melbourne FortiGate inspects the traffic and sends it out over the branch’s own internet connection, so it reaches Microsoft’s network without the trip to Sydney. Where that entry point sits depends on the ISP’s routing, which is why we measure it. The Adelaide FortiGate inspects the traffic and sends it out over the branch’s own internet connection, so it reaches Microsoft’s network without the trip to Sydney. Where that entry point sits depends on the ISP’s routing, which is why we measure it. The Perth FortiGate inspects the traffic and sends it out over the branch’s own internet connection, so it reaches Microsoft’s network without the trip to Sydney. Where that entry point sits depends on the ISP’s routing, which is why we measure it. The Townsville FortiGate inspects the traffic and sends it out over the branch’s own internet connection, so it reaches Microsoft’s network without the trip to Sydney. Where that entry point sits depends on the ISP’s routing, which is why we measure it.
Straight-line distances, with light in fibre covering about 200 km per millisecond. Real fibre routes are longer, and queuing and central inspection add more. We measure the actual paths before recommending a change.
If Teams calls regularly suffer at branch offices while head office is fine, check how the branches reach Microsoft's network. Traffic routed through head office may be adding delay it doesn't need. We would also check packet loss, jitter, ISP routing and the local connections before naming the cause.
What we test. We measure latency, jitter, packet loss, application response and the actual routing behaviour before and after a design change. Direct internet breakout can improve performance where central backhaul adds unnecessary delay. The result depends on the ISP, the application destination, security inspection, Microsoft connectivity and the paths available.
The network path should reflect where the application runs and how it needs to be secured.
How the architectures differ
- Cloud application routing: Traffic may be routed through a central inspection point
- Security enforcement: Shared firewall or security stack at a central location
- Policy management: Can be centrally managed, depending on the existing platform
- Resilience: Depends on circuit diversity, routing, firewall availability and carrier design
- Central dependencies: Shared inspection and connectivity infrastructure may affect several sites
- Application visibility: Depends on monitoring and inspection capabilities
- New site deployment: Depends on carrier availability, equipment configuration and operational processes
- Security operations: Central inspection, monitoring, policy changes and network management
- Cloud security extension: Can integrate with cloud-delivered security services
- Cloud application routing: Supports local internet breakout and application-aware path selection
- Security enforcement: Firewall and inspection controls can operate at individual branches
- Policy management: Central templates and policy packages can govern distributed devices
- Resilience: Can use measured path quality and application policy to select eligible connections
- Central dependencies: Branch traffic can continue locally where the design permits, though shared services may still be dependencies
- Application visibility: Can combine branch traffic telemetry, application awareness and security logging
- New site deployment: Standard configuration and remote provisioning can simplify deployment
- Security operations: Distributed enforcement, central policy, monitoring and ongoing device management
- Cloud security extension: Can integrate branch enforcement with SASE and identity-aware access
Performance and resilience still come down to the quality of the connectivity, the security design, the configuration and how the network is operated.
What changes during everyday network operations?
The difference is easiest to see when a connection fails, an incident occurs, a new site opens or a security policy changes.
Centralised WAN: The result depends on the backup links, routing configuration and carrier services in place. Some traditional networks fail over automatically; others depend on carrier restoration or a network engineer stepping in.
Secure SD-WAN: The branch device measures WAN path quality against configured thresholds. When an eligible path degrades or fails, traffic can move to another available connection, such as business fibre, nbn, 4G or 5G.
What matters: Backup capacity, application behaviour, path diversity and testing decide whether users notice an interruption.
Centralised WAN: Traffic may be inspected at the central firewall, with monitoring and investigation supported by the organisation's existing security systems.
Secure SD-WAN: A branch next-generation firewall can apply intrusion prevention, application control and other configured security services locally. Events can be logged and analysed centrally, including through FortiAnalyzer in a Fortinet deployment.
What matters: Detection and response depend on policy, subscriptions, inspection coverage, logging and the security operating model. Local enforcement does not on its own stop an incident from spreading.
Centralised WAN: The team confirms suitable WAN connectivity, routing, security policy and configuration before the site goes into production.
Secure SD-WAN: We can prepare the branch device centrally, assign its configuration, arrange connectivity and validate the site before moving it into production. Fortinet deployments can use FortiManager and supported provisioning workflows.
What matters: Carrier lead times, site preparation, application dependencies and the agreed acceptance checks. Remote provisioning does not remove the need for these steps.
Centralised WAN: Where inspection happens centrally, a change to shared firewall policy can affect traffic from several locations. Distributed devices may need their own configuration changes.
Secure SD-WAN: FortiManager can manage FortiGate configurations, security policy packages and controlled changes across the estate. Changes can be reviewed, deployed and verified centrally.
What matters: Policy scope, change approval, deployment status and evidence that the intended configuration is active on the relevant devices.
Routing and firewall enforcement on the same platform
In Fortinet Secure SD-WAN, FortiGate combines SD-WAN routing and next-generation firewall capabilities under FortiOS. Depending on the device, subscriptions and configuration, these can include intrusion prevention, application control, web filtering, antivirus, DNS security and inspection of encrypted traffic.
The Internet Service Database helps identify services such as Microsoft 365 and Azure for routing and policy decisions. Inspection itself is handled by the FortiGate security services.
FortiManager handles central configuration and policy management. FortiAnalyzer provides security logging, event analysis and reporting. We also use FortiAIOps as part of our Fortinet operations toolkit.
- Policy during failover. When traffic moves to another eligible WAN path, the configured firewall and inspection policies continue to apply. We validate this during testing, including NAT, routing, existing sessions and any dependencies on the original connection.
- Central management. FortiManager is standard in our multi-site Fortinet SD-WAN deployments, and we host our FortiManager environment in Australian data centres.
See how we deliver it on Fortinet Secure SD-WAN.
When centralised inspection remains appropriate
Secure SD-WAN suits many distributed environments. Replacing an architecture that works still needs a good reason.
Where critical workloads run in a central data centre and branch traffic is already designed around that location, central routing and inspection may be appropriate.
A well-managed firewall with resilient connectivity may give the business what it needs. SD-WAN can still help at a single site when several connections or application requirements justify it.
An established centralised-security design may already provide consistent policy, monitoring, redundancy and acceptable application performance.
Specific applications, operational systems or customer requirements may favour keeping MPLS or private WAN connections.
Legacy applications, addressing, routing, authentication and firewall dependencies should be mapped before traffic paths change.
We assess the current architecture before recommending changes. A network that performs well and meets its security requirements may only need targeted improvements.
Questions to answer before changing the WAN
Identify cloud applications, SaaS, Microsoft 365, private workloads, data-centre services and the dependencies between them.
Review routing, internet breakout, private WAN connections, VPNs and current traffic paths.
Document central and branch firewalls, inspection controls, segmentation, logging and remote-access policy.
Test failover, application continuity, backup capacity and dependencies on shared infrastructure.
Review configuration differences, change controls, management access and evidence that policies are applied as intended.
Assess nbn, fibre, 4G/5G, Starlink, physical diversity, carrier availability and contract terms.
Agree who is responsible for monitoring, firewall policy, firmware, changes, incidents and carrier escalation.
Moving to Secure SD-WAN
Moving from centralised inspection to branch enforcement affects routing, security policy, monitoring and the way incidents are investigated. We plan the migration around those dependencies.
Document site topology, carriers, applications, traffic paths, security policies, firewall dependencies and management arrangements.
Set branch hardware requirements, local breakout, central policy, segmentation, routing, failover and security inspection.
Prepare configurations and test representative sites. Validate applications, DNS, Microsoft 365, Teams, security controls, logging and path behaviour.
Schedule production changes around agreed windows and site requirements. Keep existing connectivity in place during validation where the architecture supports parallel operation.
Confirm acceptance criteria, documentation, management access, monitoring, operational responsibilities and rollback arrangements.
How we design and operate secure branch networks
We review current routing, internet breakout, central inspection, security dependencies and branch connectivity before recommending a design.
We assess Microsoft 365, Teams, SaaS, cloud and private application paths, including latency, jitter, packet loss and security inspection.
We design FortiGate routing, firewall policy, segmentation, application-aware steering, failover, central management and logging.
We assess the services available and work with carriers on provisioning, faults, restoration and migration dependencies.
We stage devices, test the design, coordinate production cutovers and validate the environment before handover.
We provide monitoring, configuration changes, firmware management, reporting and technical escalation. Clients can contact our engineering team directly when a network issue needs investigating.
We also work alongside internal IT teams, with management access and change responsibilities agreed for each environment.
See what we’ve delivered for our clients
Common questions about Secure SD-WAN and traditional WAN
What is the difference between Secure SD-WAN and traditional WAN?
What is hairpin routing?
Does Secure SD-WAN replace branch firewalls?
What happens to security when a WAN link fails?
How does Secure SD-WAN improve Microsoft Teams performance?
Is Secure SD-WAN suitable for a single-site business?
How long does migration to Secure SD-WAN take?
Can Secure SD-WAN use existing MPLS or NBN connections?
Does a traditional WAN have to use a central firewall?
Do we need SASE when deploying Secure SD-WAN?
Can you manage the network alongside our IT team?
Talk to us before your next WAN architecture change
Tell us how your branches connect today, where your applications run and what security or performance issues you want to fix. We'll review the existing network and work through the options for routing, branch security, resilience and deployment.