SASE Branch Deployment: Site Connectivity from Zero to Production

Stage SD-WAN appliances with ZTP profiles, establish IPsec/GRE tunnels to SSE PoPs, validate failover with controlled link kills, then expand policy enforcement in waves. Plan 2-4 hours per site for physical install, 1-2 days for policy tuning. The biggest mistake is deploying TLS inspection at all sites simultaneously — start with 3 pilot branches and expand weekly.

Branch deployment is where SASE theory meets physical reality. You have an SD-WAN appliance that needs power, cabling, and an ISP handoff. You have SSE policies that need tunnel onramps from that appliance to the nearest PoP. And you have users who will call the helpdesk the moment their SaaS apps feel slower than before. This guide covers the end-to-end process of taking a branch from legacy MPLS or direct internet access to full SASE — SD-WAN plus SSE — with the phased approach that minimizes user disruption and gives you rollback options at every stage.

Pre-deployment planning

Before you ship a single appliance, you need three things documented: a site survey for every branch, a network design template, and a rollback procedure. The site survey captures ISP circuit details (provider, bandwidth, IP assignments, SLA), existing equipment (router model, switch count, AP count, rack space), and any site-specific constraints (no remote hands, restricted maintenance windows, union labor requirements). I have seen deployments stall for weeks because nobody verified that the branch in rural France had a compatible power outlet for the SD-WAN appliance.

The network design template should be standardized across all sites with minimal per-site variation. Define your WAN transport strategy (dual ISP, ISP plus LTE failover, or single ISP with cellular backup), your LAN segmentation (corporate VLAN, guest VLAN, IoT VLAN at minimum), and your tunnel architecture (IPsec to primary SSE PoP, GRE to secondary). Every deviation from the template adds operational complexity that compounds across 50 or 100 sites. Fight hard to keep the design consistent — when a branch manager insists on a special configuration, push back unless there is a genuine technical requirement.

SD-WAN appliance staging

Stage appliances centrally before shipping to sites. This means pre-loading the firmware version you have tested (not the latest release — use N-1 for stability), configuring the zero-touch provisioning (ZTP) profile with the site-specific WAN interface settings, and verifying that the appliance can reach the orchestrator over a test internet connection. ZTP should handle everything after the on-site technician plugs in power and WAN cables: the appliance contacts the cloud orchestrator, downloads its full configuration, establishes SD-WAN tunnels, and reports healthy status. Target: under 15 minutes from power-on to green status in the dashboard.

Label every appliance with its destination site name and a QR code linking to the site installation guide. Ship with pre-made cables (console, WAN, LAN), a printed one-page quick-start card for the on-site technician, and a prepaid return shipping label in case the hardware is DOA. These details sound trivial but they eliminate 80% of the remote-hands issues that delay branch deployments. The on-site technician is often not a network engineer — they are a facilities manager or office administrator who agreed to plug in a box. Make it impossible to get wrong.

SSE tunnel onramps

Once the SD-WAN appliance is online, you need to establish tunnels from the branch to the SSE inspection PoPs. There are two common approaches: IPsec tunnels (supported by every SSE vendor — Zscaler, Netskope, Cisco, Palo Alto) and GRE tunnels (supported by most but with vendor-specific nuances). IPsec is preferred because it encrypts traffic end-to-end between the branch and the PoP, while GRE requires an additional encryption layer if the underlay is untrusted internet.

Configure primary and secondary tunnels to different SSE PoPs for redundancy. The primary tunnel should target the geographically nearest PoP for minimum latency. The secondary should target the next-nearest PoP in a different availability zone or data center. SD-WAN health probes should monitor tunnel latency, jitter, and packet loss, with automatic failover to the secondary tunnel when the primary degrades beyond your defined thresholds. Typical failover thresholds: latency > 150ms, packet loss > 1%, or jitter > 30ms sustained for 10 seconds.

Traffic steering through the SSE tunnel should be policy-based: internet-bound traffic goes through the SSE PoP for inspection (SWG, CASB, DLP), while intra-site LAN traffic stays local. Direct internet breakout without SSE inspection should only be used for latency-sensitive traffic that you have explicitly whitelisted — typically video conferencing (Zoom, Teams) and select CDN traffic. Everything else goes through the tunnel. Resist the temptation to bypass SSE for 'trusted' SaaS apps — even Microsoft 365 traffic should be inspected because it is the number one vector for token theft and data exfiltration.

30/60/90 day rollout plan

Days 1-30: Pilot branches

Deploy to 3-5 pilot branches that represent your typical site profile. Include at least one small office (under 20 users), one medium office (20-100 users), and one site with challenging conditions (remote location, single ISP, or legacy equipment that needs to coexist). Run the pilot in monitor-only mode for the first two weeks: SSE policies log but do not block, so you can see what traffic patterns exist without disrupting users. Review the logs daily for the first week, then twice weekly. You are looking for: false positives in URL categorization, applications that break under TLS inspection, and any latency increase that users notice.

Days 30-60: Enforce and expand

Enable enforcement at the pilot branches: SWG blocks malware and policy-violating categories, CASB applies shadow IT policies, DLP scans for sensitive data. Simultaneously begin deploying SD-WAN appliances to the next wave of 10-20 branches. By this point your ZTP process should be proven and your SSE policies tuned based on pilot learnings. The most common policy adjustment at this stage is adding TLS inspection bypass rules for applications that break with certificate injection — typically thick-client financial applications, healthcare imaging systems, and certain IoT device management platforms.

Days 60-90: Full rollout

Deploy remaining branches in waves of 10-20 per week. At this pace, a 100-site deployment completes in 90 days from the first pilot. Track three metrics across every site: time-to-green (minutes from power-on to healthy status), helpdesk tickets per site in the first 48 hours, and mean latency delta (difference between pre-SASE and post-SASE latency to critical SaaS apps). Healthy benchmarks: time-to-green under 15 minutes, fewer than 2 helpdesk tickets per site, and latency delta under 10ms. If any site exceeds these thresholds, pause the rollout and investigate before continuing.

Failover and redundancy testing

Do not skip failover testing. After each pilot branch is deployed, perform controlled link-kill tests: disconnect the primary WAN link and verify that traffic fails over to the secondary within your SLA (typically under 30 seconds for SD-WAN path failover, under 60 seconds for SSE tunnel failover). Test both directions: primary to secondary and secondary back to primary. Some SD-WAN platforms have asymmetric failover behavior where the failback is slower than the failover. Document the actual failover times, not the vendor's claimed times.

Also test SSE PoP failover independently: if your SSE vendor's primary PoP becomes unreachable (simulate by blocking the PoP IP range on your SD-WAN), traffic should reroute through the secondary PoP tunnel. Measure the latency impact. If the secondary PoP is in a different region, users will notice increased latency during failover — this is expected but should be documented so that it does not trigger unnecessary escalations during an actual outage.

Common branch deployment failures

1. TLS inspection breaks internal applications. Every branch has that one legacy app that embeds certificates or uses certificate pinning. Identify these during the pilot, add bypass rules before expanding to production sites.
2. ISP MTU mismatches cause packet fragmentation. IPsec tunnels add overhead (typically 50-80 bytes). If the ISP path MTU is 1500 and your tunnel overhead is 60 bytes, set the SD-WAN interface MTU to 1440 to prevent fragmentation. Most SD-WAN platforms auto-detect this, but verify during pilot.
3. DNS resolution changes break local services. Branches often rely on local DNS for printers, file shares, and location-specific services. Ensure the SD-WAN or SSE configuration preserves local DNS resolution for internal domains while routing external DNS through the SSE for inspection.
4. Zero-touch provisioning fails because the appliance cannot reach the orchestrator. The most common cause: the on-site ISP modem or router has a restrictive firewall that blocks outbound HTTPS to non-standard ports. Verify orchestrator connectivity requirements with the on-site ISP equipment before shipping appliances.
5. Deploying enforcement at all sites simultaneously. One bad policy rule takes down internet access at every branch. Always deploy in waves with a 48-hour observation period between waves.

Sources & further reading

• Cisco, "SD-WAN Branch Design Guide" — cisco.com/c/en/us/solutions/enterprise-networks/sd-wan/branch-design-guide.html
• Fortinet, "FortiSASE Branch Deployment" — fortinet.com/products/sase
• Gartner, "Critical Capabilities for SD-WAN" — gartner.com/reviews/market/sd-wan-edge
• Palo Alto Networks, "Prisma SD-WAN Site Deployment" — paloaltonetworks.com/prisma/sd-wan

Related on sase.cloud

One email per publish. Unsubscribe anytime.