Most engineers think…
Most people picture SD-WAN as 'a smarter MPLS' or 'a box that load-balances two internet links'. That mental model falls apart the moment an interviewer asks about underlay vs overlay.
Versa SD-WAN is an overlay: a fabric of encrypted IPsec/IKE tunnels built between VOS devices, riding on top of whatever underlay transports a branch happens to have — MPLS, broadband Internet, LTE/5G. The whole point is transport independence: the overlay behaves the same regardless of which link carries it. Once you see that split — links you buy underneath, tunnels Versa builds on top — topology choices, NAT traversal and the Controller's role all click into place.
① Underlay vs overlay — links you buy vs tunnels Versa builds
The single most important idea: there are two layers. The underlay is the set of physical transports a branch buys — MPLS, broadband Internet, LTE/5G. The overlay is the fabric of encrypted tunnels Versa builds on top of those transports.
Because the overlay rides on top, SD-WAN is transport-independent. A tunnel over a cheap broadband line and a tunnel over MPLS are both just SD-WAN paths to the fabric — same policy, same behaviour. You stop caring which carrier delivered the bits and start caring about the path's quality.
The interview line: underlay = the links you buy; overlay = the encrypted tunnels Versa builds over them. SD-WAN value comes from the overlay, not from any single transport.
In an interview, open with the split: underlay = the transports you buy (MPLS, Internet, LTE/5G); overlay = the encrypted IPsec tunnels Versa builds over them. Then add the magic word — transport-independent — and you've framed the whole topic in two sentences.
In SD-WAN, the 'overlay' is best described as…
② The IPsec tunnels — IKE paths between VOS devices
Versa builds the overlay as IPsec/IKE tunnels between VOS devices. Each tunnel is an SD-WAN path, and a branch builds one per transport toward each peer it talks to.
So the maths is simple. A branch with two transports to a hub forms two parallel paths — the same logical destination reachable two ways. Scale that to an N-site full mesh and you get tunnels between every pair of sites, multiplied by the number of transports they share.
Why parallel paths matter
Every tunnel is monitored for liveness and SLA (loss, latency, jitter — covered in the App Steering lesson) so traffic can shift from a degraded path to a healthy one. Two transports is not just backup; both can be active and steered per application.
The physical transports a branch buys — MPLS, broadband Internet, LTE/5G. The links underneath; Versa does not own them.
The fabric of encrypted IPsec/IKE tunnels Versa builds on top of the underlay. The SD-WAN paths that actually carry your traffic.
One encrypted SD-WAN path between two VOS devices over one transport. Keys negotiated by IKE, traffic secured by IPsec.
Control-plane helper: branches register with it, it seeds reachability, then VOS devices tunnel directly. Not a packet path.
A branch has two transports (MPLS and broadband) to one hub. How many SD-WAN paths to that hub?
③ Topologies — hub-and-spoke, full mesh, dynamic on-demand
You choose how the tunnels are laid out. Hub-and-spoke: spokes tunnel to a DC or regional hub VOS. It is simple and scales well, but spoke-to-spoke traffic goes via the hub, adding a hop.
Full mesh: every site builds tunnels to every other site, per transport. Best latency for site-to-site traffic, but the tunnel count grows fast as you add sites.
Dynamic / on-demand tunnels: spoke-to-spoke tunnels are built automatically only when two spokes actually need to talk, then torn down when idle. This gives you mesh-like performance with hub-and-spoke scale — the practical default for voice and video between branches.
Full mesh gives the best latency but the tunnel count explodes as sites grow, eating resources. For large estates the right answer is hub-and-spoke plus dynamic on-demand tunnels — you get direct spoke-to-spoke paths only when traffic actually needs them.
▶ Watch two branches build a direct on-demand tunnel
How a spoke-to-spoke path is created end-to-end. Press Play for the healthy path, then Break it to see the classic failure.
You want direct spoke-to-spoke paths for voice without a tunnel to every site sitting up permanently. Which topology?
④ NAT traversal & the Controller — how branches find each other
Most branches sit behind NAT — and Internet transports increasingly behind CGNAT, with no fixed public IP. Versa still builds tunnels through this using NAT traversal, so a branch on a plain broadband line joins the overlay fine.
The piece that makes this work is the Controller. Branches register with it, and it seeds reachability — who exists, where, and how to reach them — so VOS devices can then build the data-plane tunnels directly between each other.
The interview line: the Controller seeds reachability, then branches tunnel directly. It is a control-plane helper, not a packet path — your traffic still rides the direct overlay tunnels.
Rohan at a Pune retail chain faces this
A new store on a cheap broadband line (behind the ISP's CGNAT) won't form its SD-WAN tunnel to the data-centre hub, while MPLS sites are fine.
The Internet underlay sits behind carrier NAT with no public IP, and NAT traversal / UDP encapsulation wasn't enabled on that transport's IPsec profile.
Check the branch in Director: the MPLS path is up but the Internet path stays in IKE negotiation; the branch has a private RFC1918 address from the ISP, confirming CGNAT.
Director ▸ Monitor ▸ Tunnels + Devices ▸ IPsec profile (NAT-T)Enable NAT traversal (NAT-T / UDP encapsulation) and keepalives on the Internet transport profile so the tunnel forms through CGNAT, and confirm the branch is registered to the Controller.
Re-check tunnels: the Internet path comes up alongside MPLS, two SD-WAN paths show healthy, and the store reaches the hub over the overlay.
Don't close a 'branch is slow' ticket on a guess. In Director, read each transport's tunnel state and SLA — which paths are up, their loss/latency/jitter, and whether traffic is steering correctly. That single view answers most overlay tickets.
What is the Controller's role when a branch behind CGNAT comes online?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why is the Versa SD-WAN data plane called an 'overlay' and why does that make it transport-independent? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Underlay
- The physical transport networks a branch buys — MPLS, broadband Internet, LTE/5G. The links underneath the SD-WAN fabric.
- Overlay
- The fabric of encrypted IPsec/IKE tunnels Versa builds on top of the underlay; the SD-WAN paths that carry your traffic.
- Transport-independent
- The overlay behaves the same regardless of which underlay transport (MPLS, Internet, LTE/5G) carries it.
- IPsec / IKE tunnel
- An encrypted overlay tunnel between VOS devices — keys negotiated by IKE, traffic secured by IPsec. Each is one SD-WAN path.
- SD-WAN path
- One overlay tunnel over one transport between two sites; a site with two transports has two parallel paths to a peer.
- Hub-and-spoke
- Topology where spokes tunnel to a central hub VOS; simple and scalable, but spoke-to-spoke traffic transits the hub.
- Full mesh
- Topology where every site tunnels to every other site per transport; best latency but tunnel count grows fast.
- Dynamic / on-demand tunnel
- A spoke-to-spoke tunnel built automatically only when two spokes need to talk, then torn down — mesh performance, hub scale.
- NAT traversal
- UDP encapsulation and keepalives that let IPsec tunnels form through NAT/CGNAT when a branch has no public IP.
- Controller
- Versa control-plane component branches register with; it seeds reachability and routing so VOS devices can tunnel directly.
📚 Sources
- Versa Networks — Versa Secure SD-WAN product page and architecture overview. versa-networks.com
- Versa Networks — Underlay vs overlay and transport independence in Versa SD-WAN. versa-networks.com
- Versa Networks Docs — VOS devices, IPsec/IKE overlay tunnels and SD-WAN paths. docs.versa-networks.com
- Versa Networks Docs — SD-WAN topologies: hub-and-spoke, full mesh and dynamic on-demand tunnels. docs.versa-networks.com
- Versa Networks Docs — Controller registration, reachability and NAT traversal for branches behind CGNAT. docs.versa-networks.com
- Versa Networks — Transport options: MPLS, broadband Internet and LTE/5G in Versa SD-WAN. versa-networks.com
What's next?
Got the overlay? Next, go deep on App Steering — how Versa measures each path for loss, latency and jitter, scores it against an SLA, and moves traffic between transports the moment one degrades.