How to connect distributed branches through a secure, centrally managed SD-WAN hub

1. What is a hub-and-spoke topology?

Hub-and-spoke is an SD-WAN design in which branch appliances establish encrypted tunnels to a central hub instead of creating a separate tunnel to every other branch. The hub commonly resides at a data center, headquarters, or shared-services location and becomes the principal exchange point for private network traffic.

The model is easy to understand and scales efficiently: adding a branch normally requires one logical relationship with the hub, not a new tunnel to every existing site. Central policy and monitoring also become simpler because inter-site connectivity converges at a known location.

2. How the topology works

Figure 1. Branch spokes connect to the central hub; traffic between spokes is forwarded through the hub.

• Each spoke establishes an encrypted SD-WAN tunnel to the hub over one or more WAN links.

• The hub and spokes advertise the LAN subnets that must be reachable across the overlay.

• Traffic destined for a hub network travels directly through the spoke-to-hub tunnel.

• Traffic between two spokes reaches the hub first and is then forwarded into the destination spoke tunnel.

• SLA measurements and SD-WAN rules select the appropriate WAN path and provide failover when a link degrades.

3. Why organizations choose this design

1. Simpler scaling

The number of required tunnel relationships grows more slowly than in a full-mesh design. This reduces configuration complexity for deployments with many branches.

2. Centralized control

The hub provides a natural point for routing policy, shared security services, logging, and access to applications hosted at headquarters or in a data center.

3. Efficient branch onboarding

A new spoke can join the SD-WAN fabric by receiving a tunnel address, advertising its local networks, and applying the standard SLA and routing policy.

4. A practical implementation model

1. Plan addressing and reachability

Select a non-overlapping tunnel CIDR and confirm that all branch LAN subnets are unique. Determine which hub and branch networks must be exchanged. If the hub uses a static public IP, verify that it is reachable from every spoke and that the required ports are permitted by upstream firewalls.

2. Create the SD-WAN network

In the parent cluster, create the SD-WAN network, choose HUB_AND_SPOKE, assign the tunnel range and SLA profile, and select suitable MTU and encryption settings. Enable optional L2 tunneling or WAN optimization only when the application design requires them.

3. Add the hub member

Select the hub appliance, assign the HUB role, and provide its public endpoint where required. Choose participating WAN links and the path-selection behavior. Advertise hub-side LAN or shared-services networks that spokes need to reach.

4. Add spoke members

Add each branch appliance with the SPOKE role, choose its WAN links, and advertise only the local LAN subnets intended for private connectivity. Configure outbound forwarding toward the LAN for traffic that must enter the branch network.

5. Apply SLA and traffic rules

Create the required SD-WAN SLA and member rules at the hub and spokes. SLA monitoring should measure meaningful targets and thresholds for latency, jitter, packet loss, and reachability. Rules then use these measurements to select or fail over between available WAN links.

5. Traffic patterns to understand

6. Hub-and-spoke versus full mesh

Hub-and-spoke favors operational simplicity and centralized governance. Full mesh provides direct spoke-to-spoke paths that can reduce latency, but it increases tunnel relationships and policy complexity. Hub-and-spoke is usually the better fit when branch-to-data-center traffic dominates, while mesh may suit environments with heavy real-time communication directly between branches.

7. Validation checklist

• The hub endpoint is reachable from every spoke WAN connection.

• All intended member tunnels report healthy status and receive unique tunnel addresses.

• Advertised LAN subnets do not overlap.

• A host at each spoke can reach the required hub-side services.

• Spoke-to-spoke traffic works through the hub when that communication is permitted.

• Forward and return routes are symmetric enough for stateful security policies.

• SLA-based failover is tested by degrading or disconnecting a participating WAN link.

• The hub has adequate throughput, redundancy, and session capacity for aggregate branch demand.

8. Common design pitfalls

• Overlapping LAN subnets make route selection ambiguous.

• Missing return routes can make one-way tests appear successful while applications fail.

• MTU mismatch can break large packets or selected applications even when basic ping works.

• Overly broad subnet advertisement can expose networks that should remain isolated.

• A single, undersized hub creates a performance bottleneck and a large failure domain.

• Treating topology creation as sufficient without SLA and SD-WAN rules leaves path behavior undefined.

9. Technical Architecture Deep Dive

This section expands the topology guide into a design draft. Product labels vary between SD-WAN platforms, but the networking principles below apply to a Ray hub-and-spoke deployment and should be validated against the software release in use.

10. Underlay: the transport foundation

The underlay is the real IP network beneath SD-WAN. It consists of WAN interfaces, ISP or carrier circuits, provider routing, public or private addressing, and any upstream NAT or firewall devices. Typical underlays include broadband internet, dedicated internet, MPLS, leased lines, LTE/5G, and cloud private interconnects. A site can use more than one underlay at the same time.

• The underlay must provide stable IP reachability from each spoke WAN interface to the hub tunnel endpoint.

• Underlay routing should expose only what is needed to reach tunnel endpoints and controllers; corporate LAN prefixes normally belong in the overlay.

• Underlay quality—latency, jitter, loss, bandwidth, congestion, and NAT behavior—sets the ceiling for overlay performance.

• If a WAN circuit uses private addressing or carrier-grade NAT, confirm that tunnel establishment and keepalive behavior work through that NAT type.

• DNS and NTP reachability may be required for controller discovery, certificates, logging, and accurate SLA measurements.

11. Overlay: the secure logical fabric

The overlay is the encrypted network created between SD-WAN appliances over the available underlays. It abstracts the service network from individual carriers. Tunnel addresses identify overlay members, while advertised LAN prefixes describe the networks reachable behind each member. Policies decide which routes are visible, which paths are eligible, and how applications use available tunnels.

Figure 2. The underlay transports packets between tunnel endpoints; the overlay carries protected enterprise traffic and route intent.

12. Network planes and their traffic

1. Management plane

Carries administrator actions, configuration changes, inventory, software updates, dashboards, logs, and reporting between appliances and the management platform. It should be protected with role-based access, strong authentication, and restricted management reachability.

2. Control plane

Exchanges topology, member identity, reachable prefixes, path information, policy, and often encryption metadata. The control plane tells edge appliances what is reachable and permitted; it should not be assumed to carry ordinary user payloads.

3. Data plane

Carries application and user packets across encrypted tunnels. The hub forwards transit traffic between spokes, toward shared services, or toward a breakout. Path selection uses measured tunnel conditions and configured policy.

13. Complete traffic-flow matrix

14. Route behavior in a true hub-and-spoke design

A spoke should learn hub reachability and the remote networks that policy allows through the hub. In a strict design, spokes do not build direct data-plane adjacencies to other spokes. Inter-spoke traffic therefore consumes two overlay tunnel legs and hub forwarding capacity. Route advertisement can use connected/static information or a dynamic protocol at the service edge, depending on product support and deployment scale.

• Advertise only real, reachable LAN prefixes. A stale advertisement can black-hole traffic.

• Summarization reduces route scale but must not hide overlapping or partially reachable networks.

• More-specific routes override summaries and defaults; audit them when traffic bypasses the intended hub.

• A default route controls internet or broad transit behavior and should be introduced with rollback access.

• When MPLS and overlay routes coexist, define preference deliberately to prevent oscillation or asymmetric return paths.

15. Breakout and service-placement possibilities

1. Local internet breakout

The spoke sends internet traffic directly through its WAN. This normally reduces latency and hub bandwidth demand but requires branch security, NAT, and consistent policy. SaaS traffic often benefits from local breakout.

2. Central internet breakout

The spoke sends selected or all internet traffic through the overlay to the hub. The hub applies firewalling, inspection, logging, and source NAT. This provides a predictable public identity and common controls but adds path length and makes hub capacity critical.

3. Service chaining

Traffic may be steered through a firewall, IDS/IPS, proxy, load balancer, or other service at the hub. Service health must be tracked, and policy must state whether traffic should fail open, fail closed, or use a backup service when the primary instance is unavailable.

16. Path selection and SLA behavior

• Measure both directions when possible; one-way quality can differ.

• Use application-relevant thresholds. A tunnel can be reachable but unsuitable for voice or video.

• Define recovery hysteresis or hold-down behavior so a marginal circuit does not flap between states.

• Test brownout conditions—high loss, jitter, or latency—not only a clean physical disconnect.

17. NAT and return-path considerations

NAT can exist in the underlay, at a spoke breakout, or at the central hub. These are different roles. Upstream underlay NAT affects tunnel establishment. Breakout source NAT translates user traffic for internet access. Stateful firewalls and NAT require replies to return through the device holding the session state.

• For local breakout, source NAT normally occurs on the spoke internet-facing interface.

• For central breakout, source NAT normally occurs at the hub; replies must map back to the originating spoke session.

• Avoid translating private site-to-site overlay traffic unless addressing overlap or a specific policy requires it.

• Where multiple hubs or exits exist, use routing and state synchronization designs that preserve return-path validity.

18. Segmentation and security

Hub-and-spoke does not automatically mean every site can communicate. Separate users, servers, guests, IoT, voice, and management into appropriate routing or policy segments. Route visibility and firewall policy should follow least privilege. The hub is a convenient enforcement point for inter-spoke traffic, but local controls may still be needed for traffic that never reaches the hub.

• Authenticate appliances and protect tunnel keys and certificates.

• Limit management access and separate it from ordinary user segments.

• Inspect and log traffic according to data sensitivity, not merely topology.

• Define whether security services fail open or fail closed and test both outcomes.

19. High availability and scaling options

20. Failure scenarios and expected behavior

21. Detailed pre-deployment checklist

• Inventory every site, WAN circuit, public/private endpoint address, NAT device, LAN prefix, bandwidth, and application dependency.

• Eliminate or translate overlapping LAN prefixes before enabling broad inter-site reachability.

• Size hub throughput for aggregate encrypted traffic, security inspection, NAT sessions, and future growth.

• Choose tunnel CIDR, MTU, cipher, SLA targets, probe intervals, thresholds, and recovery timers.

• Document local, central, and hybrid breakout policies—including DNS and SaaS allow-list behavior.

• Define segmentation and the exact route advertisements allowed between sites.

• Design dual-WAN, dual-hub, management-access, and rollback paths.

• Confirm firewall rules for tunnel establishment, controller reachability, and underlay probes.

• Create test cases for every traffic row in the flow matrix and every failure row above.

22. Troubleshooting sequence

• Underlay first: verify WAN addressing, gateway, DNS/time, hub endpoint reachability, NAT/firewall traversal, and packet loss.

• Tunnel second: verify member status, tunnel addresses, encryption/authentication, keepalives, and MTU.

• Routing third: inspect advertised, learned, selected, and withdrawn prefixes at hub and spoke.

• Policy fourth: confirm segmentation, rule order, SLA state, path eligibility, forwarding direction, NAT, and security decisions.

• Data path last: run bidirectional ping, trace route, TCP/application tests, and packet capture at LAN, tunnel, and WAN boundaries.

• Resilience: reproduce failure or degradation and verify failover, failback, alerts, and session impact.

23. Recommended baseline design

24. Conclusion

A hub-and-spoke SD-WAN topology gives distributed sites a scalable private overlay with the hub acting as the connectivity and policy center. Success depends on more than bringing tunnels online: addressing, route advertisement, forwarding policy, SLA monitoring, return paths, hub capacity, and resilience must work as one design. When these elements are aligned, branches gain dependable access to shared services and to one another without the operational burden of a full mesh.

25. Frequently Asked Questions

1. What is a hub-and-spoke SD-WAN topology?

A hub-and-spoke SD-WAN topology connects branch locations through a central hub. Each branch establishes an encrypted tunnel to the hub, which acts as the primary exchange point for private traffic between branches and shared services.

2. How does hub-and-spoke SD-WAN differ from a full-mesh topology?

In a hub-and-spoke design, branches connect to the central hub rather than creating individual tunnels with every other branch. This simplifies deployment and management, while a full-mesh design provides direct branch-to-branch paths but requires more tunnel relationships and greater configuration complexity.

3. How does a hub-and-spoke topology handle traffic between branches?

Traffic from one branch travels through its encrypted tunnel to the hub, where it is forwarded through the destination branch’s tunnel. This means inter-spoke traffic depends on the hub having the correct routes and sufficient forwarding capacity.

4. What should be considered when designing a hub-and-spoke SD-WAN deployment?

Key considerations include non-overlapping LAN subnets, tunnel addressing, WAN capacity, route advertisements, SLA policies, MTU, encryption settings, segmentation, redundancy, and hub capacity. These elements need to work together to provide reliable traffic forwarding and failover.

5. Can internet traffic use a hub-and-spoke SD-WAN topology?

Yes. Internet traffic can use either local breakout at the spoke or central breakout through the hub. The choice depends on routing and security policy. Central breakout provides centralized inspection and control, while local breakout can reduce latency and hub bandwidth usage.