SD-WAN picks the path, SASE moves the inspection to the cloud

For a long time, a branch network diagram had a familiar shape. Every branch connected to headquarters over a private link, and headquarters had the big firewall that faced the internet. If someone at a branch opened a website, the traffic went to headquarters first, got inspected there, and only then went out.

Then most of the applications people use every day moved to the internet as SaaS, and that shape started to feel odd. Why send traffic for a cloud app all the way to headquarters, just to send it back out again?

SD-WAN and SASE are the two answers most networks have landed on. They get mentioned together so often that they blur into one acronym. This post takes them apart one question at a time, using NIST SP 800-215 as the neutral reference and the vendors' own documentation for the product details.

Q: What was wrong with the old way?

Nothing, when the applications lived in the data center. The trouble starts when they don't.

NIST SP 800-215, Guide to a Secure Enterprise Network Landscape (November 2022), names the problem directly in its section on the limits of MPLS. An MPLS network is a separate network, so it reaches the internet only through a few designated access points. NIST compares this to hairpinning and notes that it adds latency for time-sensitive applications (SP 800-215, section 2.3). It also points out that running a different technology with different appliances makes the network harder to manage.

The US government ran into the same problem at a much larger scale. CISA's Trusted Internet Connections (TIC) programme has existed since 2007 to consolidate federal network connections. Under OMB memo M-19-26, agencies no longer have to route their traffic through TIC access points if they have a TIC alternative. In its TIC 3.0 Branch Office Use Case (version 2.0, April 2023), CISA states the goals plainly: better application performance (latency, throughput, jitter), lower costs from fewer private links, and a better experience for users at branch offices.

BEFORE: backhaul through HQ                                     
                          ┌──────────┐                          
                          │   SaaS   │─────────────────┐        
                          └──────────┘                 │        
┌─────────┐                                       ┌────┴──────●┐
│ branch  │■──────────────────────────────────────│ HQ firewall│
└─────────┘                                       └────────────┘
                                                                
                                                                
AFTER: direct via a nearby SASE PoP                             
             ┌──────●┐    ┌──────────┐                          
             │ PoP   │────│   SaaS   │                          
             └───┬───┘    └──────────┘                          
                 │                                              
┌─────────┐      │                                ┌────────────┐
│ branch  │■─────┘                                │ HQ: private│
└─────────┘                                       └────────────┘
                                                                

Q: So what does SD-WAN actually do?

At its core, SD-WAN lets a branch use several links at once and decide, for each application, which link to use right now.

NIST describes SD-WAN as separating the network's control plane from its data plane, so that policies for access control, routing and application priority can be set centrally (SP 800-215, section 6). Among the design goals it lists, two matter most for this post:

• Any transport. Connect users and applications over MPLS, broadband internet, 4G/LTE or 5G.
• Application awareness. Watch the traffic and choose the best available path based on the type of traffic, how loaded the network is, and how important the application is to the business. This depends on measuring things like latency, jitter and packet loss, and on recognising which application a flow belongs to.

That is the "brain" part. The tunnels between sites (the overlay) run on top of whatever links you have (the underlay), and the brain moves applications between them.

Q: What does "picks the healthier path" look like in a real product?

Vendor documentation makes this concrete. Palo Alto Networks describes Prisma SD-WAN as a cloud-delivered, app-defined SD-WAN that virtualizes the separate transports into a unified hybrid WAN. Its performance policy documentation shows how the choice is made:

The documentation also gives default thresholds. For media apps they are latency 150 ms, packet loss 2% and jitter 40 ms. For all other apps they are latency 500 ms, packet loss 5% and jitter 100 ms. When a path breaks the SLA, the main action is to move flows to a path that still meets it. The details are worth reading closely. When an application metric is violated, only new flows move. When a link quality metric is violated, new flows and existing flows over Prisma SD-WAN's own VPN fabric (Fabric VPN) can move, as long as they stay within the same NAT boundary. The same page describes line-conditioning options, forward error correction and packet duplication, for links that lose packets.

 BRANCH                                     SASE PoP    SaaS app
                                                                
                                                                
                                                                
             A broadband ▮▮▮▮▮ loss 0%                          
┌─────────┐   ──────■────────■─────\         ·······            
│ branch  │  /                      \\     ··       ··  ┌──────┐
│         │ /                         \\  ··SWG FWaaS · │      │
│[SD-WAN]●│■                            ──·────◆──────·─│ app  │
│         │ \                         ■/  · CASB ZTNA · │      │
│         │  \                      //     ··       ··  └──────┘
└─────────┘   ─────────────────────/         ·······            
             B LTE       ▮▮▮▮▯ loss 0%                          
                                                                
 SLA for this app: loss < 5%                                    
 new flows use: link A                                          
                                                                
 SD-WAN picks the path; the PoP inspects every flow             

The detail that new flows and existing flows can behave differently is easy to miss. If a long-lived session stays on a bad link while new sessions move, users see one tab freeze while another reloads fine. Knowing which rule applies saves a confusing troubleshooting session.

Q: Then where does SASE come in?

SD-WAN fixes the path. It says nothing about inspection. If every branch now has its own internet link, something still has to do the job the headquarters firewall used to do.

NIST explains that the term "secure access service edge" (SASE) was coined by Gartner in 2019 for an architecture that combines networking and security functions and delivers them as a cloud service at global scale. Enterprises reach that service through points of presence (PoPs). NIST makes one point that is easy to forget: the services inside SASE are not new. They are delivered together as one package instead of as separate products (SP 800-215, section 6). The minimum set NIST finds in most commercial offerings is firewall, secure web gateway, anti-malware, IPS, CASB and DLP.

Palo Alto's own explainer defines SASE as a cloud-native architecture that combines SD-WAN with security functions, and lists the pieces:

• SWG (secure web gateway): URL filtering, SSL decryption, application control and threat detection for web traffic.
• FWaaS (firewall as a service): a next-generation firewall delivered from the cloud. NIST also lists "a cloud service (FWaaS)" as one of the ways to deploy an NGFW (SP 800-215, section 3).
• CASB (cloud access security broker): visibility and control over sanctioned and unsanctioned SaaS. NIST traces the history: early CASBs mostly discovered shadow IT, and current ones enforce policy and DLP for cloud apps.
• ZTNA (zero trust network access): identity-based and application-based policy enforcement with continuous verification, so access is granted to specific applications rather than to the whole network.

Put simply, SD-WAN decides which road to take, and SASE moves the checkpoint off your premises and into a nearby cloud PoP.

Q: How do Prisma Access and Zscaler describe their models?

Both describe a cloud service that your sites and users send traffic to. Their documentation uses different words for similar ideas.

Prisma Access (Palo Alto Networks) describes itself as a service that brings consistent security to remote networks and mobile users. Its docs split the model into three kinds of connection:

• Remote networks: branches connect over an IPsec tunnel, from a Palo Alto NGFW or from a third-party IPsec-capable device, including SD-WAN. Palo Alto deploys firewalls in the cloud to protect those sites, so you don't have to manage a firewall at each one.
• Mobile users: the GlobalProtect app builds an IPsec or SSL tunnel, or the endpoint uses an explicit proxy through a PAC file.
• Service connections: connections back to the headquarters or data center for private resources, such as on-premises authentication. Palo Alto recommends always creating one.

Zscaler splits the job across two services. Zscaler Internet Access (ZIA) is for internet and SaaS traffic. Its Public Service Edges are inline security gateways that inspect traffic in both directions, and Zscaler says they are deployed in its data centers around the world. A Central Authority holds the policy and configuration settings. Zscaler Private Access (ZPA) is for internal apps. Lightweight App Connectors sit next to the applications and only make outbound connections, so the apps don't need to accept connections from the internet. Zscaler's wording is that "application access does not require network access."

ZIA's documentation lists several ways to forward traffic to the service: Zscaler Client Connector, GRE tunnels, IPsec tunnels, PAC files, proxy chaining, Cloud Connector and Branch Connector. Zscaler recommends a combination rather than a single method.

One design detail is worth knowing. If a ZIA Public Service Edge loses contact with the Central Authority, it switches to Safe mode. It keeps enforcing the policies it has cached, and if it can't get a user's policy, it applies a default URL policy. Reading how a service behaves when part of it is unhealthy tells you more than the feature list does.

 USER                 CLOUD BROKER             PRIVATE NETWORK  
                                             ┌┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
                    ┌──────────────┐         ┆                  
┌────────┐          │    broker  ● │         ┆ ┌─────────┐      
│  user  │          │              │ outbound┆ │connector│      
│        │◆─────────┼──────────────┼═════◂═══╪◂│         │      
│ +agent │          │              │         ┆ │         │      
└────────┘          │ [ ] user     │         ┆ └───┬─────┘      
                    │ [ ] device   │         ┆     │            
                    │ [ ] policy   │         ┆     └─ app A     
                    └──────────────┘         ┆                  
                                             ┆      ✗ app B     
 decision: pending                           ┆                  
 inbound ports open: none                    ┆      ✗ app C     
                                             ┆                  
                                             └┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
 the connector dials out; the broker stitches one session       
 access to one app, not to the network                          

Q: Does this mean the branch firewall disappears?

Not always, and the standards don't claim it does. CISA's Branch Office Use Case lists, under resilience, that an agency "should determine which services can be centralized and which can be deployed at the branch location", weighing availability, compliance, cost, administration and risk tolerance (TIC 3.0 Branch Office Use Case).

In my view, these are the places where something on site still earns its keep:

• Traffic that never leaves the building. A cloud PoP only sees what is sent to it. Segmentation between local devices, such as user laptops, printers, cameras or building systems, has to be enforced locally. NIST covers this kind of internal separation under microsegmentation (SP 800-215, section 5.1).
• Links that fail. If every tunnel to the PoP is down, you need to decide in advance whether the branch fails closed (no internet) or fails open (direct internet without inspection).
• Rules that require local control. Some regulated environments need inspection points or log retention that a shared cloud service may not fit.

Often the on-site box shrinks to an SD-WAN edge with basic firewalling, and the heavy inspection happens in the PoP. Whether that is right depends on the site.

Q: What should I ask before migrating?

A checklist I would want answered before moving a branch:

1. Which apps go where? List SaaS, internet and private apps separately. Private apps decide whether you need service connections, App Connectors or something similar.
2. Is policy the same on every path? CISA calls this policy enforcement parity. If you use redundant links or SD-WAN, path priorities and the order of security functions should give the same protection on every path, so an attacker can't pick a path with weaker checks (TIC 3.0 Branch Office Use Case).
3. Which SLA moves which flows? Learn the defaults (see the Prisma SD-WAN thresholds above) and decide which apps deserve tighter ones.
4. How do you forward traffic: tunnel, agent or proxy? Each one sees different traffic. A PAC file only covers proxy-aware apps.
5. What happens when it breaks? Tunnel down, PoP unreachable, policy service unreachable: write down the expected behaviour and test it during a change window.
6. Where do logs go? Make sure PoP logs reach your SIEM. CISA asks agencies to bring branch and cloud telemetry into their situational awareness tools.
7. What stays local? Write down the east-west segmentation the branch still needs.

The short version

SD-WAN answers "which road?". It measures each link and moves applications to the one that meets their SLA. SASE answers "where is the checkpoint?". It moves the secure web gateway, firewall, CASB and ZTNA into a cloud service with PoPs close to users. The firewall didn't vanish. Most of it moved into the cloud, and a smaller part stayed at the edge of each site.

Sources

• NIST SP 800-215, Guide to a Secure Enterprise Network Landscape (publication page)
• NIST SP 800-215, full text (PDF)
• CISA, Trusted Internet Connections (TIC)
• CISA, TIC 3.0 Branch Office Use Case, version 2.0 (PDF, April 2023)
• Palo Alto Networks, What is SASE?
• Palo Alto Networks, Prisma SD-WAN documentation
• Palo Alto Networks, Prisma SD-WAN performance policy
• Palo Alto Networks, Prisma Access documentation
• Palo Alto Networks, Prisma Access remote networks
• Palo Alto Networks, Prisma Access mobile users
• Palo Alto Networks, Prisma Access service connections
• Zscaler, Understanding the Zscaler Cloud Architecture for Internet & SaaS
• Zscaler, Understanding Public Service Edges for Internet & SaaS
• Zscaler, Choosing Traffic Forwarding Methods
• Zscaler, What Is Private Access?