The pitch is that SD-WAN makes the WAN intelligent. The reality is narrower and more useful: it lets you say "voice goes over the good link, backups go over the cheap one, and both survive a failure," without writing that logic by hand on every router.
That is a real improvement. It is also not magic.
The three things it actually does
| Capability | What it means |
|---|---|
| Application-aware path selection | Per-flow policy across multiple links |
| Overlay tunnels | Encrypted paths over any underlay, with consistent addressing |
| Centralized management | One policy, pushed to every site |
Everything else — zero-touch provisioning, cloud gateways, analytics — is packaging around those three.
What it does not do
- Create bandwidth. Two 100 Mbps links are 100 Mbps each, not 200 for one flow.
- Replace diversity. If both links share a conduit, the overlay has nothing to fail over to.
- Remove routing knowledge. Someone still has to understand why a prefix is reachable.
- Fix a bad design. An overlay over a broken underlay is a broken overlay.
Overlay does not mean immunity
SD-WAN vendors show a diagram where any link can carry any traffic. The diagram assumes the links are independent and adequately sized. Neither is guaranteed by the product.
Where the model fits a district
A district with a fiber ring between buildings and broadband to two campuses has exactly the problem SD-WAN describes: different links, different costs, different reliability, and applications that care.
| Traffic | Policy |
|---|---|
| Voice | Lowest latency link, fail over in under a second |
| Video conferencing | Latency and jitter sensitive, prefer fiber |
| Student web | Any link, cheapest |
| Backups | Off-peak, lowest-cost link, tolerant of delay |
| Management | Any link, but encrypted and logged |
That table is the design. The product is how you enforce it.
The UniFi version
UniFi does not market a full SD-WAN stack, but the pieces exist:
- Load balancing and failover across WAN interfaces, with health checks.
- Policy-based routing (traffic routes) to send specific sources or destinations out a specific WAN.
- Site-to-site VPN as the overlay between sites.
- Per-WAN weights for distribution.
What is missing compared with a dedicated SD-WAN product: application identification, per-flow steering based on measured latency/jitter, and centralized policy across many sites. For a district with two or three WAN links, the built-in tools cover most of the value.
Worked example: two campuses, three links
Campus A: 1 Gbps fiber, 200 Mbps broadband. Campus B: 500 Mbps fiber, LTE backup.
Policy:
- Voice and video prefer fiber at both sites.
- General traffic load-balances 80/20 toward fiber.
- On fiber loss, everything moves to broadband; voice is prioritized; backups are suspended.
- On total loss, LTE carries management and voice only.
The fourth rule is the one that prevents a bad day from becoming a worse one: a 50 Mbps LTE link with student video on it is unusable for the staff who need it.
What breaks in production
- Tunnel overhead reducing usable MTU, so large transfers stall until MSS is clamped.
- Health checks that probe the wrong thing, declaring a link dead when only one destination is unreachable.
- Policy that references applications the engine does not recognize, silently falling back to default.
- Licensing surprises: per-site, per-throughput, or per-feature.
- Complexity: three overlapping policy layers (routing, SD-WAN, firewall) that nobody can trace.
Checklist
- The underlay is documented: links, capacities, shared elements.
- Application policy is written as a table before it is configured.
- Health checks test a destination that matters.
- Failover and failback have been tested, including the degraded mode.
- MTU and MSS are set for every tunnel.
- Licensing costs are known for the expected site count.
Next
The edge is where address translation happens. Continue with NAT, CGNAT, and the Edge.