# Versa SD-WAN Overlay — Transports & the IPsec Tunnel Fabric Source: https://ai.techclick.in/blog_versa_sdwan_overlay_tunnels Markdown: https://ai.techclick.in/blog_versa_sdwan_overlay_tunnels.md Publisher: Techclick Infosec Pvt Ltd A clear, interactive guide to the Versa SD-WAN data plane (2026): underlay vs overlay, the encrypted IPsec/IKE tunnels Versa builds over MPLS, broadband Internet and LTE/5G, why SD-WAN is transport-independent, the three topologies (hub-and-spoke, full mesh, dynamic on-demand), NAT traversal behind CGNAT, and how the Controller seeds reachability so branches tunnel directly. Versa SD-WAN Overlay — Transports & the IPsec Tunnel Fabric student learning map A visual study map for Versa SD-WAN Overlay — Transports & the IPsec Tunnel Fabric showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Versa SD-WAN Overlay — Transports & the IPsec... Versa · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Underlay vs overlay — links you... 4. Practice ② The IPsec tunnels — IKE paths... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. Figure 1 — Overlay on top of the underlay Versa builds the encrypted overlay on top of whatever transports the branch buys — the overlay behaves the same on any of them. - Overlay on top of the underlay Overlay (Versa) Encrypted IPsec/IKE tunnels — the SD-WAN fabric Transport-independent Same behaviour on any underlay below Underlay (you buy) MPLS, broadband Internet, LTE/5G links Versa builds the encrypted overlay on top of whatever transports the branch buys — the overlay behaves the same on any of them. Say 'underlay vs overlay' first 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. Quick check · Q1 of 10 · Understand In SD-WAN, the 'overlay' is best described as… a) The MPLS and Internet links you buy b) The set of encrypted tunnels Versa builds on top of the transports c) The Versa Director management console d) A single physical appliance at the branch Correct: b. The overlay is the fabric of encrypted IPsec/IKE tunnels Versa builds on top of the underlay transports. The links you buy (MPLS, Internet, LTE/5G) are the underlay; Director is management, not the data path. 👉 So far: Underlay = the transports you buy (MPLS, Internet, LTE/5G); overlay = the encrypted IPsec tunnels Versa builds over them. SD-WAN is transport-independent. ## ② 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. Figure 2 — How a branch joins the overlay Each transport becomes a separate encrypted SD-WAN path between VOS devices. How a branch joins the overlay Register branch to Controller Learn peers reachability seeded IKE negotiate keys IPsec path tunnel per transport Monitor liveness + SLA Each transport becomes a separate encrypted SD-WAN path between VOS devices. 🧱 Underlay tap to flip The physical transports a branch buys — MPLS, broadband Internet, LTE/5G. The links underneath; Versa does not own them. 🕸️ Overlay tap to flip The fabric of encrypted IPsec/IKE tunnels Versa builds on top of the underlay. The SD-WAN paths that actually carry your traffic. 🔐 IPsec / IKE tunnel tap to flip One encrypted SD-WAN path between two VOS devices over one transport. Keys negotiated by IKE, traffic secured by IPsec. 🛰️ Controller tap to flip Control-plane helper: branches register with it, it seeds reachability, then VOS devices tunnel directly. Not a packet path. Quick check · Q2 of 10 · Apply A branch has two transports (MPLS and broadband) to one hub. How many SD-WAN paths to that hub? a) One — tunnels are shared b) Zero until failover c) Two — one parallel path per transport d) Four — two each way Correct: c. Versa builds one encrypted IPsec path per transport toward a peer, so two transports to a hub form two parallel SD-WAN paths. Both can be active and steered per application, not just backup. 👉 So far: Versa builds IPsec/IKE tunnels between VOS devices — one SD-WAN path per transport. Two transports to a hub = two parallel paths; an N-site full mesh = paths between every pair, per transport. ## ③ 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. Figure 3 — Hub-and-spoke overlay Spokes tunnel to a hub VOS; spoke-to-spoke traffic transits the hub unless on-demand tunnels are enabled. Hub-and-spoke overlay Hub VOS DC / regional Branch Mumbai Branch Pune Branch Delhi Branch Chennai Branch on LTE Spokes tunnel to a hub VOS; spoke-to-spoke traffic transits the hub unless on-demand tunnels are enabled. Figure 4 — Full mesh vs dynamic on-demand Both give direct spoke-to-spoke paths; on-demand builds them only when needed, keeping tunnel counts low. Full mesh vs dynamic on-demand Full mesh Tunnel to every site, always up Best latency site-to-site Tunnel count grows fast Heavy on resources at scale Dynamic on-demand Spoke-to-spoke built when needed Torn down when idle Mesh performance, hub scale Great for voice and video Both give direct spoke-to-spoke paths; on-demand builds them only when needed, keeping tunnel counts low. 'Full mesh is always best' over-reach 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. ① Need to talk A user in the Mumbai branch starts a voice call to the Pune branch; today they only have tunnels to the hub. ▼ ② Ask Controller Both VOS devices already registered with the Controller, which has seeded reachability for both spokes. ▼ ③ Build on-demand The two spokes negotiate IKE and bring up a direct IPsec tunnel over their shared Internet transport. ▼ ④ Direct + monitor Voice now flows spoke-to-spoke without the hub hop; the new path is monitored and will tear down when idle. Press Play to step through the healthy on-demand tunnel path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Analyze You want direct spoke-to-spoke paths for voice without a tunnel to every site sitting up permanently. Which topology? a) Dynamic / on-demand tunnels b) Pure hub-and-spoke c) Full mesh d) No overlay at all Correct: a. Dynamic on-demand tunnels build spoke-to-spoke paths automatically only when two spokes need to talk, then tear them down — mesh-like performance with hub-and-spoke scale. Full mesh keeps every tunnel up; pure hub-and-spoke sends spoke-to-spoke via the hub. 👉 So far: Three topologies: hub-and-spoke (simple, scalable, spoke-to-spoke via hub), full mesh (best latency, more tunnels), dynamic on-demand (mesh performance with hub-and-spoke scale). ## ④ 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. Figure 5 — Tunnel through CGNAT A branch behind carrier NAT still joins the overlay — NAT traversal and the Controller make it reachable. Tunnel through CGNAT Behind CGNAT no public IP Register to Controller NAT traversal UDP encap + keepalive Direct tunnel to peer VOS A branch behind carrier NAT still joins the overlay — NAT traversal and the Controller make it reachable. 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. Likely cause 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. Diagnosis 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) Fix 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. Verify 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. Prove the path from the tunnel state, not a ping 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. Quick check · Q4 of 10 · Understand What is the Controller's role when a branch behind CGNAT comes online? a) It carries all the branch's data traffic b) It replaces IPsec with plain routing c) It blocks NAT'd branches from the overlay d) It seeds reachability so the branch can then tunnel directly to peers Correct: d. The Controller is a control-plane helper: branches register, it distributes reachability/routing, then VOS devices build the data-plane tunnels directly. It is not the packet path — traffic rides the direct overlay tunnels. 👉 So far: Branches behind NAT/CGNAT still build tunnels via NAT traversal. The Controller seeds reachability, then branches tunnel directly — it's a control-plane helper, not the packet path. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is the difference between underlay and overlay? What kind of tunnels does Versa build, and between what? What are the three SD-WAN topologies? Why is SD-WAN called transport-independent? How does a branch behind CGNAT still build tunnels? What exactly does the Controller do? 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. Q5 · Remember Which of these is the underlay? a) The encrypted IPsec tunnels b) The physical transports — MPLS, Internet, LTE/5G c) The Versa Controller d) The application-steering policy Correct: b. The underlay is the physical transport networks a branch buys (MPLS, broadband Internet, LTE/5G). The overlay is the encrypted tunnels Versa builds on top of them. Q6 · Understand What makes SD-WAN 'transport-independent'? a) The overlay behaves the same regardless of which underlay carries it b) It only ever uses MPLS c) It removes the need for any links d) It encrypts only on broadband Correct: a. Because the overlay rides on top of the underlay, an SD-WAN path behaves the same whether MPLS, Internet or LTE carries it. That independence is the core value of SD-WAN. Q7 · Apply Five sites in a full mesh, each pair sharing two transports. Compared with hub-and-spoke, what happens to tunnel count? a) It stays the same b) It drops to one c) It grows fast — paths between every pair, per transport d) Tunnels disappear entirely Correct: c. Full mesh builds tunnels between every pair of sites, multiplied by shared transports, so the count grows quickly with site count — the trade-off for best site-to-site latency. Q8 · Analyze Spoke-to-spoke voice is laggy because it hops through the hub. Best fix that keeps scale? a) Switch the whole network to MPLS b) Enable dynamic / on-demand spoke-to-spoke tunnels c) Remove the Controller d) Disable IPsec to speed it up Correct: b. On-demand tunnels build a direct spoke-to-spoke path only when needed and tear it down when idle, removing the hub hop while keeping hub-and-spoke scale. Full mesh would also work but at much higher tunnel cost. Q9 · Evaluate A branch on plain broadband behind CGNAT can't form its Internet tunnel. Strongest first check? a) Replace all classifiers b) Buy an MPLS circuit c) Reboot the hub d) Confirm NAT traversal (NAT-T) is enabled and the branch is registered to the Controller Correct: d. CGNAT means no public IP, so the tunnel needs NAT traversal (UDP encapsulation/keepalives) and the branch must be registered with the Controller for reachability to be seeded. That's the root cause to check first. Q10 · Evaluate An interviewer asks for the one-line model of the Versa data plane. Best answer? a) MPLS replaced by one big firewall b) Underlay = links you buy; overlay = IPsec tunnels Versa builds over them; transport-independent; pick hub-spoke, mesh or on-demand; Controller seeds reachability, then branches tunnel directly c) A single appliance that load-balances two links d) A cloud proxy that stores all traffic Correct: b. That sentence captures the whole model: the two layers, transport independence, the topology choices, and the Controller's control-plane role with direct data-plane tunnels. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 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. Compare with expert answer Expert version: Because the data plane is a fabric of encrypted IPsec/IKE tunnels Versa builds on top of whatever transports a branch has (the underlay — MPLS, Internet, LTE/5G). Since the tunnels ride above the physical links, an SD-WAN path behaves identically no matter which underlay carries it — that's transport independence. You then choose a topology (hub-and-spoke, full mesh, or dynamic on-demand), branches behind NAT/CGNAT still build tunnels via NAT traversal, and the Controller seeds reachability before VOS devices tunnel directly to each other. The value lives in the overlay, not in any single link you buy. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Versa SD-WAN at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt