Central Breakout Using Hub-and-Spoke SD-WAN Topology
A practical design guide for routing branch internet traffic through a secure central hub.
Branch networks often need the flexibility of SD-WAN without giving up centralized control. In a hub-and-spoke design, each branch forms an encrypted tunnel to a central hub. Instead of accessing the internet locally, branch traffic follows the tunnel to the hub and exits through the hub’s WAN connection.
This creates one consistent enforcement point for internet access. Security teams can apply the same inspection, access policies, public IP identity, and logging standards across sites, while operations teams gain a simpler place to observe and troubleshoot traffic flows.
Figure 1. Outbound and return traffic in a central-breakout hub-and-spoke design.
Centralized internet breakout changes how branch traffic is handled by bringing security, visibility, and public internet access under a common hub. The result is a more consistent approach to managing internet traffic across distributed locations.
All branches of internet traffic crosses the same inspection and policy boundary. This is useful when an organization needs uniform filtering, auditing, or compliance controls across many locations.
Internet sessions are easier to monitor because the breakout point is consolidated. Operations teams can correlate events, investigate failures, and measure usage from a common location.
Source NAT at the hub allows branch users to appear on the internet through the hub public IP. This can simplify SaaS allow-listing and partner access policies.
Implementing centralized internet breakout requires the SD-WAN fabric, hub, and spoke configurations to work together correctly. The process can be structured into four key steps, from building the fabric to directing internet-bound traffic through the hub.
Create an SD-WAN network in the parent cluster, assign a tunnel CIDR, select HUB\_AND\_SPOKE, choose the SLA profile, and set the required MTU and cipher. Enable options such as a public hub IP, Layer 2 tunneling, or WAN optimization only when they match the design.
Add the hub appliance, select HUB as its member type, supply its static public IP when applicable, and choose the WAN links that will participate. Configure outbound forwarding toward the WAN and ensure the hub has sufficient internet capacity for aggregate spoke traffic.
Add each branch appliance as a SPOKE, select its participating WAN links, and advertise only the LAN subnets that must be reachable over the fabric. Create the required SD-WAN SLA and member rules at the spoke so path selection and failover operate as intended.
Use the default route, 0.0.0.0/0, as the policy intent for central breakout. Validate that the selected rule sends internet-bound sessions into the SD-WAN fabric and that the hub forwards them toward its WAN. Avoid overlapping or more-specific routes that unintentionally bypass the hub.
Central breakout requires a complete forward and return path. At the hub, source NAT translates branch traffic to the hub’s public IP before it reaches the internet. Connection tracking and the corresponding return translation then associate replies with the original branch session and route them back through the correct tunnel.
If the platform exposes separate Forward NAT, Reverse NAT, or reverse-rule controls, enable and validate the rules required by the deployed software version. Existing automatically created SD-WAN rules may be reused when they match the intended route and security policy.
| Algorithm | Best suited to | Key consideration |
|---|---|---|
| Session-based weighted | Web, file transfer, TCP sessions | Keeps each session on one path and reduces packet reordering. |
| Packet cloning | Voice, critical real-time traffic | Improves resilience but consumes additional bandwidth. |
| Per-packet weighted | Selected stateless or UDP traffic | Uses links efficiently but may reorder packets. |
| Best path | Applications governed by SLA metrics | Adapts to latency, jitter, loss, and available bandwidth. |
For most general branch traffic, session-based weighted load balancing is a practical starting point because it balances utilization while preserving session consistency. More specialized techniques should be applied selectively according to application behavior and bandwidth cost.
Central breakout trades some path efficiency for control. Traffic may travel farther than it would with local breakout, increasing latency and hub bandwidth consumption. The hub also becomes a critical shared service, so resilient WAN links, capacity planning, redundant appliances, and tested failover are essential.
Use central breakout when security consistency, regulatory control, shared services, or a predictable public IP matter more than the shortest internet path. Where latency-sensitive cloud applications dominate, consider a hybrid policy that keeps selected applications local while routing governed traffic through the hub.
Central breakout is particularly useful when many branches need internet access but the organization wants security and operational decisions to remain centralized. Instead of deploying and maintaining a complete security stack at every location, branches send selected internet traffic to a hub where shared controls can be applied consistently.
Branch traffic can pass through centrally managed firewalls, inspection systems, logging platforms, and compliance controls. This helps enforce a common policy across locations and provides a consolidated audit trail.
Stores or small offices often have limited local IT resources. Central breakout allows internet access, content filtering, threat inspection, and troubleshooting to be managed from a data center or headquarters rather than separately at every branch.
When SaaS platforms, partners, or payment services permit access only from approved public IP addresses, central breakout can present the hub public IP for users at many branches. This avoids maintaining a separate allow-list entry for every local ISP address.
Traffic can be directed through central firewalls, secure web gateways, intrusion-prevention systems, proxies, data-loss prevention services, or malware inspection tools before it reaches the internet.
A branch can use an economical broadband or cellular underlay while the encrypted SD-WAN overlay carries governed internet traffic to the hub. The provider circuit supplies transport, while enterprise security policy remains under organizational control.
| Operational problem | How central breakout helps | Result |
|---|---|---|
| Different security policies at every branch | Routes internet traffic through a common enforcement stack at the hub. | More consistent protection and governance. |
| Limited visibility into branch internet traffic | Consolidates logs, sessions, alerts, and usage at the central exit. | Simpler monitoring and investigation. |
| Changing or numerous branch public IP addresses | Uses the hub public IP as the shared internet identity. | Simpler SaaS and partner allow-listing. |
| –High cost of security appliances at small sites | Allows branches to consume shared hub security services. | Lower branch complexity and operational overhead. |
| Difficult policy updates across many locations | Policy changes are concentrated at the central security boundary. | Faster and more uniform change control. |
| Uncontrolled direct internet access | The overlay default route or application policy sends governed traffic to the hub. | Reduced accidental policy bypass. |
| Complex branch troubleshooting | Provides a known traffic path and centralized logs for analysis. | Faster isolation of routing, NAT, or security problems. |
| Need to inspect branch-to-cloud sessions | Steers selected SaaS or cloud traffic through approved inspection services. | Improved compliance and threat detection. |
Consider an organization with fifty branch offices and a firewall cluster at headquarters. Without central breakout, every branch may use a different ISP address, security configuration, and logging method. With central breakout, the intended traffic flow becomes:
Central breakout is not automatically the right path for every application. The additional trip through the hub may create avoidable latency or consume excessive hub bandwidth. Consider local or hybrid breakout when:
A hybrid design is often the most balanced answer: keep trusted, latency-sensitive SaaS traffic local and send regulated, unknown, private-application, or high-risk traffic through the central hub.
A hub-and-spoke SD-WAN design provides a clear way to centralize branch internet access. When default-route policy, forwarding, NAT, SLA monitoring, and return routing are aligned, every spoke gains controlled access through a common security boundary. The result is simpler policy enforcement and better visibility, provided the hub is engineered for the traffic and availability it must carry.
Central internet breakout routes internet-bound traffic from branch locations through a central SD-WAN hub instead of allowing each branch to access the internet directly. The hub becomes the common point for security inspection, policy enforcement, monitoring, and NAT.
Central breakout provides consistent security policies, centralized visibility, and a predictable public IP address for branch users. It can also simplify SaaS allow-listing, compliance controls, troubleshooting, and security management across multiple locations.
The spoke uses the default route, 0.0.0.0/0, to identify internet-bound traffic and sends it through the encrypted SD-WAN tunnel to the hub. The hub then applies the required security policies and source NAT before forwarding the traffic to the internet.
Organizations should evaluate hub WAN capacity, firewall and encrypted-throughput requirements, redundancy, latency, NAT and return routing, and the applications that will use the centralized path. Central breakout can increase latency and hub bandwidth consumption, so capacity and failover planning are important.
Central breakout is particularly useful for distributed organizations such as banks, retail stores, branch offices, and environments that rely on IP-based SaaS allow-lists or shared security services. It is most valuable when centralized security, compliance, monitoring, or a common public IP is more important than taking the shortest path to the internet.
