# Cisco SD-WAN Security, DIA & Troubleshooting: — Enterprise Firewall, SIG & the Show-Command Playbook Source: https://ai.techclick.in/blog_cisco_sdwan_security_dia_troubleshooting Markdown: https://ai.techclick.in/blog_cisco_sdwan_security_dia_troubleshooting.md Publisher: Techclick Infosec Pvt Ltd Cisco SD-WAN security & ops for the 300-415 exam: cEdge zone-based firewall, IPS/Snort, URL-Filtering, AMP, unified policy; DIA + SIG (Umbrella/Zscaler); and the bottom-up troubleshooting ladder — control connections, OMP, BFD, app-route. Cisco SD-WAN Security, DIA & Troubleshooting: — Enterprise Firewall, SIG & the Show-Command Playbook student learning map A visual study map for Cisco SD-WAN Security, DIA & Troubleshooting: — Enterprise Firewall, SIG & the Show-Command Playbook showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN Security, DIA & Troubleshooting: —... Cisco SD-WAN · 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 ① Embedded security on the cEdge —... 4. Practice ② Direct Internet Access + SIG —... 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 engineers think SD-WAN security means "buy a separate firewall box for every branch" and troubleshooting means "stare at the data plane until BFD comes up." Wrong on both counts. The cEdge is the firewall — a single Snort UTD container runs the zone-based firewall, IPS, URL-Filtering and AMP on the router itself, and for sites with no on-box stack you steer traffic to a cloud SIG . And you never start troubleshooting at BFD: BFD can't come up if control connections or OMP are down. You read the fabric bottom-up — control connections first — so you fix the lowest broken rung instead of chasing a symptom three layers above the cause. ## ① Embedded security on the cEdge — the firewall is now the router For years the rule was simple: branch traffic rode an MPLS line back to the HQ datacentre, where a big firewall inspected it. Cisco SD-WAN flips that. The cEdge (an IOS-XE SD-WAN WAN Edge router) carries its own security stack, so you can inspect traffic at the branch and break out to the internet without hairpinning to HQ. The whole stack rides inside one container. That container is the UTD (Unified Threat Defense) security virtual image — a secapp-utd… file you upload to vManage → Maintenance → Software Repository → Virtual Images and push to the cEdge. Inside it, the Snort engine powers four inspections: the enterprise (zone-based) firewall , IPS/IDS , URL-Filtering , and Advanced Malware Protection (AMP) with file reputation and ThreatGrid. One container, four jobs. 👉 So far: the cEdge runs its own security via the Snort UTD container. Next we'll see how the four inspections clip together into one policy, and what the firewall zones actually mean. Figure 1 — Embedded security stack on the cEdge A cEdge WAN Edge router with the IOS-XE SD-WAN security stack. A Snort UTD container hosts the enterprise zone-based firewall, IPS/IDS, URL filtering and Advanced Malware Protection. Traffic from the LAN VPN passes through zone-pairs into a unified security policy (advanced inspection profile) before exiting to MPLS or the Internet transport. - Embedded security on the cEdge — one UTD container, four inspections LAN / VPN 10 user traffic 10.10.10.0/24 cEdge (IOS-XE SD-WAN) — WAN Edge Zone-Based Firewall (zones + zone-pairs) inspect · pass · drop + self-zone Snort UTD container (security virtual image) IPS / IDS URL-Filter AMP / TG TLS decrypt unified policy = advanced inspection profile Internet transport biz-internet · DIA MPLS transport private · overlay no datacentre hairpin — inspect AT the branch underlay/untrusted overlay/trusted control/policy key insight allowed/SLA-met Look at the middle box: the UTD container holds all four inspections. LAN traffic enters via a zone-pair, gets inspected once, and exits to MPLS or DIA. No HQ hairpin. Start with the zone-based firewall (ZBFW) . You group VPNs/interfaces into zones (say LAN-zone and Internet-zone ), then create a zone-pair for each direction you want to allow. The policy is a list of sequences, and each sequence ends in an action: inspect (stateful allow + return traffic), pass (one-way allow, no state) or drop . Traffic between two zones with no zone-pair is denied by default — that default-deny is the whole point. The router's own traffic lives in the special self zone . The clever bit is the unified security policy . Instead of running the firewall, then IPS, then URL-Filter as separate features, you build an advanced inspection profile (IPS + URL-Filtering + AMP + TLS action/decryption) and attach it to a firewall sequence. One policy, one decision point. You build it in vManage → Configuration → Security → Add Security Policy , then reference it from the device template. ### The four inspections — what each one actually catches Tap each card. These are the four jobs the single UTD container does. 🧱 Zone-Based Firewall tap to flip Stateful L3/L4 control between zones via zone-pairs. Actions: inspect, pass, drop. Default-deny between zones with no pair. The gatekeeper. 🛡️ IPS / IDS (Snort) tap to flip Signature engine. IDS = alert only; IPS = block. Three sig sets by CVSS: Connectivity, Balanced (default), Security. So: stop known exploits in flight. 🌐 URL-Filtering tap to flip Allow/block by web category or reputation — block gambling, malware-hosting, adult. So: enforce acceptable-use without a separate proxy box. 🦠 AMP / ThreatGrid tap to flip File reputation + cloud sandboxing of downloads. Catches malware a signature would miss. So: a malicious .exe gets a verdict, not a free pass. cEdge CLI — is the Snort security container actually running? Branch-cEdge# show utd engine standard status Expected output Engine version: 1.0.13_SV3.0.2_XE17.9 Profile: Cloud-Low System memory: Usage : 32.10 % Snort instances: 1 Engine Status: Green Common mistake — the engine that won't go Green Symptom: you push the security policy but no traffic is inspected and show utd engine standard status shows the engine not Green. Cause: the cEdge is below the UTD resource floor — Snort needs roughly 4 vCPU and 8 GB RAM , and you must have uploaded a secapp-utd image that matches the IOS-XE version. Fix: size the platform for UTD, match the image to the code train, and confirm the App-Hosting / Secure App Hosting profile has the cores it needs. Quick check · Q1 of 10 Rahul at HCL groups his LAN VPN and his Internet transport into two zones but creates no zone-pair between them. Users complain they can't reach the internet at all. Why? a) Zone-based firewall denies traffic between two zones unless an explicit zone-pair with a policy exists b) IPS is blocking everything by default c) URL-Filtering quarantined the whole internet d) The cEdge needs a reboot to apply zones Correct: a. ZBFW is default-deny between zones: with no zone-pair (and no inspect/pass policy) from LAN-zone to Internet-zone, all that traffic is dropped. IPS/URL-Filter act on already-permitted flows, not the zone decision; no reboot is needed to apply a zone policy. Pause & Predict Predict: a recent Cisco advisory (May 2026, threat actor UAT-8616) covered active exploitation of an auth-bypass in the SD-WAN Controller / SD-WAN Manager (formerly vSmart/vManage). Why is the controller a juicier target than any single branch firewall? Type your guess. Reveal answer Answer: Because the controller programs the WHOLE fabric. Compromise one branch and you own one site; compromise the SD-WAN Controller/Manager (CVE-2026-20182, a CVSS 10.0 auth bypass in the control-connection peering handshake, exploited by UAT-8616) and you log in as a high-privileged account, expose NETCONF, push templates/policy to every WAN Edge, read every config, and pivot anywhere. That's why the hardening guide says: restrict management-plane access, patch SD-WAN Manager fast, and watch control-connection peering events for unknown devices. The security stack on the cEdge is only as safe as the controller that programs it. ## ② Direct Internet Access + SIG — break out locally, keep the firewall Here's the daily-life version. Backhauling all internet traffic to HQ is like everyone in your Mumbai office taking the company shuttle all the way to the Pune head office just to post a letter, then coming back. Direct Internet Access (DIA) is letting them drop the letter at the local post office — fast, cheap, done. You configure a DIA route in the service VPN and NAT on the internet-facing transport, and Office 365 / Teams / SaaS exits the branch directly. But that local post office has no security guard. The moment you break out at the branch, you've left the HQ firewall behind — and now nothing inspects that traffic. That is the security trade-off DIA forces you to solve. Two answers: run the on-box UTD stack from Section 1 (good for branches big enough for Snort), or steer the breakout into a cloud SIG (Secure Internet Gateway). Figure 2 — Backhaul vs DIA, and why DIA needs a SIG A two-path comparison. Left: traditional backhaul tunnels all internet traffic to the headquarters firewall, adding latency. Right: Direct Internet Access breaks out locally for fast SaaS but removes the central security stack, so traffic must be steered into a Secure Internet Gateway such as Cisco Umbrella or Zscaler via automatic SIG tunnels. Backhaul vs DIA — and why DIA needs a SIG Backhaul (old way) Branch HQ DC firewall Internet every Teams/Office365 packet hairpins to HQ first − added latency, MPLS bandwidth burned DIA (local breakout) Branch cEdge NAT + DIA route Internet / SaaS SaaS exits the branch directly — fast − but the HQ firewall is gone! who inspects now? The fix: steer DIA into a SIG (cloud firewall) automatic SIG tunnel → Cisco Umbrella / Zscaler / Secure Access IPsec (Umbrella) or IPsec/GRE (Zscaler) · uses first NAT-outside WAN iface SIG service route in the VPN sends traffic to the cloud stack on-box UTD (small branch) OR SIG (no on-box stack) — pick per site underlay/untrusted overlay/trusted control/policy key insight allowed/SLA-met Left = old hairpin (slow, MPLS-hungry). Right = DIA (fast) but the firewall vanished. Bottom = the fix: an automatic SIG tunnel puts a cloud firewall back in the path. A SIG tunnel is built for you from a feature template. The path: vManage → Configuration → Templates → Feature Template → Cisco SIG Credentials (Umbrella API key/secret or Zscaler partner login) and Cisco Secure Internet Gateway (SIG) for the tunnel itself. The cEdge then provisions automatic IPsec tunnels to Umbrella (or IPsec/GRE to Zscaler) using the first NAT-outside WAN interface — so DNS and the internet must be reachable through that same interface. You add a SIG service route in the VPN to send traffic to the SIG, and you can stand up multiple active tunnels for HA and bandwidth. vManage → Configuration → Templates → Feature Template → Cisco Secure Internet Gateway (SIG) . Real fields. (Recreated for clarity — your console matches this.)"> 🖥️ This is the screen you'll use — vManage → Configuration → Templates → Feature Template → Cisco Secure Internet Gateway (SIG) . Real fields. (Recreated for clarity — your console matches this.) vmanage.lab.local · Configuration · Templates · Cisco SIG 1 SIG Provider Umbrella (IPsec) — or Zscaler (IPsec/GRE) 2 Source Interface GigabitEthernet1 (first NAT-outside WAN) 3 Tunnel Type IPsec — Active Tracker (health) On — probe api.umbrella.com High Availability Active / Active (2+ tunnels) 4 Service VPN route vpn 10 → service sig (SIG service route) Save Two practitioner traps from the field. First, Umbrella enforces by DNS/domain — if an app or host talks to a raw IP address (or a local proxy answers the DNS), the query never reaches Umbrella and your policy is silently bypassed. Second, because the tunnel rides the first NAT-outside interface , if that interface's DNS or default route is wrong, the tunnel never forms — and your SaaS traffic black-holes instead of failing back. Always wire a tracker so the cEdge can detect a dead SIG and fail traffic the other way. cEdge CLI — is the SIG tunnel up to Umbrella/Zscaler? Branch-cEdge# show sdwan secure-internet-gateway tunnels Expected output TUNNEL IF TUNNEL NAME HA-PAIR TRACKER TUNNEL STATE ---------------------------------------------------------------------- Tunnel100001 SIG-Umbrella-Primary active UP up Tunnel100002 SIG-Umbrella-Backup backup UP up (traffic in vpn 10 with 'service sig' is now steered to the cloud) Quick check · Q2 of 10 Meera at Airtel enables DIA for a guest VPN so guests get fast internet, but the security team objects. What is the correct way to keep guests fast AND inspected? a) Backhaul all guest traffic to HQ again — DIA is unsafe b) Turn off NAT on the branch c) Keep DIA but steer the guest VPN into a SIG (Umbrella/Zscaler) via an automatic SIG tunnel d) Disable OMP for the guest VPN Correct: c. DIA gives the speed; the SIG gives back the firewall. Steering the guest VPN into Umbrella/Zscaler over a SIG tunnel inspects the breakout in the cloud. Backhauling throws away the DIA benefit; turning off NAT breaks DIA entirely; OMP is unrelated to internet inspection. Pause & Predict Predict: a site has DIA working (SaaS is fast) but the SIG tunnel to Umbrella is down, and no tracker was configured. What does the user actually experience, and why is that worse than the tunnel simply failing closed? Type your guess. Reveal answer Answer: Without a tracker, the cEdge doesn't know the SIG is dead, so traffic keeps getting pointed at a black-holed tunnel — pages just hang. Worse: if a fallback route exists, traffic may slip out the local breakout UNINSPECTED instead of being blocked. A tracker (probing e.g. the Umbrella API) lets the router detect the failure and either fail over to the backup tunnel or fail closed deliberately — your call, not luck. ## ③ The troubleshooting playbook — read the fabric bottom-up When a site goes dark, juniors panic and run show sdwan bfd sessions first because BFD is what carries user traffic. That's backwards. BFD is the top of a dependency stack: it cannot come up unless OMP gave the router TLOCs and prefixes, and OMP cannot peer unless the control connections to the controllers are up. So you diagnose from the bottom up — fix the lowest broken rung and the ones above it often heal themselves. Figure 3 — The bottom-up troubleshooting ladder A four-rung troubleshooting ladder. Rung 1: control connections to the controllers (DTLS UDP 12346). Rung 2: OMP peering with the Controller. Rung 3: BFD data-plane sessions between WAN Edges. Rung 4: app-aware routing / SLA. Each rung depends on the one below it, so you diagnose from the bottom up. The troubleshooting ladder — diagnose bottom-up 1 · Control connections show sdwan control connections / connection-history — DTLS UDP 12346 to vBond/vSmart/vManage FOUNDATION 2 · OMP peering show sdwan omp peers / omp routes — needs control up; no OMP = no TLOCs, no prefixes 3 · BFD data plane show sdwan bfd sessions — IPsec tunnels site-to-site on UDP 12346–12426; needs OMP TLOCs 4 · App-aware routing / SLA show sdwan app-route stats — loss/latency/jitter; needs BFD up to measure & steer TOP read upward — fix the lowest broken rung first Key insight: if rung 1 is down, rungs 2–4 are red NOT because they are broken — they simply can't exist yet. underlay/untrusted overlay/trusted control/policy key insight allowed/SLA-met Read the rungs upward. Rung 1 (control connections) is the foundation. If it's red, rungs 2–4 are red as a consequence, not as separate faults. Rung 1 — control connections. show sdwan control connections tells you if the WAN Edge has live DTLS/TLS tunnels to the Validator (vBond), Controller (vSmart) and Manager (vManage). DTLS runs over UDP 12346 with port-hopping through 12366/12386/12406/12426 (TLS uses TCP 23456). If you see no connections, run show sdwan control connection-history — the error codes tell you the reason : DCONFAIL (DTLS connection failed, usually a firewall blocking the port), NOVMCFG (device not attached to a template in vManage), CRTVERFL / CTORGNMMIS (certificate or org-name mismatch). show command — Rung 1: control connections Branch-cEdge# show sdwan control connections Expected output PEER PEER SITE DOMAIN PEER PEER TYPE SYSTEM-IP ID ID PRIVATE IP PUBLIC IP STATE UPTIME ------------------------------------------------------------------------------- vbond - 0 0 203.0.113.10 203.0.113.10 up 5:21:09 vsmart 10.255.0.3 100 1 172.16.10.3 172.16.10.3 up 5:20:55 vmanage 10.255.0.1 100 0 172.16.10.1 172.16.10.1 up 5:20:55 Rung 2 — OMP. Control up but routing broken? show sdwan omp peers must show the Controller peer in state Up ; then show sdwan omp routes proves you're actually learning prefixes and TLOCs from other sites. No OMP peer = no overlay map = every site is an island. A classic gotcha: max-control-connections 0 on a tunnel interface, or a missing colour, stops the router from advertising its TLOCs even though control looks fine. show command — Rung 2: OMP peering Branch-cEdge# show sdwan omp peers Expected output DOMAIN OVERLAY SITE PEER TYPE ID ID ID STATE UPTIME R/I/S ---------------------------------------------------------------------- 10.255.0.3 vsmart 1 1 100 up 5:18:42 12/0/9 (R=routes recv, I=installed, S=sent — non-zero means OMP is exchanging) Rung 3 — BFD. OMP good but two sites can't pass user data? show sdwan bfd sessions shows the IPsec data-plane tunnel state per colour-pair. Up means the tunnel is healthy; Down with rising transitions points at the underlay — a firewall blocking the BFD/IPsec ports (UDP 12346–12426), a NAT type that won't allow the tunnel, MTU/fragmentation, or a TLOC colour mismatch. Read the SOURCE TLOC COLOR / REMOTE TLOC COLOR columns to see which transport pair is failing. show command — Rung 3: BFD data plane Branch-cEdge# show sdwan bfd sessions Expected output SOURCE DST PUBLIC DETECT TX SYSTEM-IP SITE-ID STATE COLOR IP ENCAP MULTIPLIER INT UPTIME -------------------------------------------------------------------------------------- 10.255.1.20 200 up mpls 172.16.20.2 ipsec 7 1000 5:10:31 10.255.1.20 200 down biz-internet 203.0.113.55 ipsec 7 1000 - (mpls up, biz-internet DOWN → underlay/firewall issue on the internet colour) Karthik at TCS faces this A new branch cEdge shows NO BFD sessions and NO OMP peers. The junior on shift starts editing the data policy, convinced it's an app-route problem. Likely cause It's nothing to do with policy. BFD and OMP are both downstream of control connections — and the cEdge's control connections to vSmart/vManage are down. With control down, the router never gets TLOCs (no OMP) so it can never build IPsec tunnels (no BFD). Diagnosis Read bottom-up. show sdwan control connections shows the controllers DOWN; show sdwan control connection-history returns DCONFAIL on UDP 12346 — the branch firewall is dropping the DTLS port. vManage → Monitor → Devices → (branch) → Real Time → Control Connections, then Control Connection History Fix Open UDP 12346–12426 (and TCP 23456) from the branch WAN IP to the controllers on the branch/ISP firewall; confirm the device is attached to a template so it isn't NOVMCFG. Verify show sdwan control connections now shows vbond/vsmart/vmanage UP; minutes later show sdwan omp peers shows the Controller Up and show sdwan bfd sessions lists tunnels coming up — the upper rungs healed themselves. Quick check · Q3 of 10 Priya at Wipro sees control connections UP, OMP peer UP, but show sdwan bfd sessions lists a tunnel as DOWN on the biz-internet colour only (mpls is up). Where is the fault most likely? a) The vSmart Controller is offline b) The underlay path for the internet colour — a firewall/NAT/MTU issue on UDP 12346–12426, not the control plane c) OMP is misconfigured d) The device isn't attached to a template Correct: b. Control and OMP being up rules out the control plane and the controller. One colour up and the other down points squarely at that colour's underlay transport — a firewall blocking the IPsec/BFD ports, a problematic NAT, or MTU/fragmentation. An offline vSmart or NOVMCFG would have broken control connections too. Pause & Predict Predict: a cEdge shows control connections UP only to vBond (the Validator) but DOWN to vSmart and vManage. What single check explains the most cases, and what's the likely fix? Type your guess. Reveal answer Answer: Up-to-vBond-but-down-to-the-rest is the classic port-hopping / firewall fingerprint: the first DTLS reach to the Validator on UDP 12346 succeeded, but the firewall isn't allowing the full UDP 12346–12426 range the device hops through to reach the Controller and Manager. Check show sdwan control connection-history for DCONFAIL, and open the whole port range (plus TCP 23456) — not just 12346. A certificate/org-name mismatch (CRTVERFL/CTORGNMMIS) is the other suspect, but the partial-up pattern points at ports first. ## ④ A full triage end-to-end — then your cert + lab next steps Let's run the whole ladder on one ticket: "The Infosys Pune branch is down — users can't reach anything." You don't poke randomly; you walk the rungs from the bottom and let each show command rule out a layer. The first command that comes back broken is where you stop and fix. ### ▶ "A branch is down" — walked bottom-up Watch one ticket get diagnosed rung by rung. Each step rules out a layer until the real fault surfaces. Press Play for the healthy path, then Break it to see the failure. ① Control run show sdwan control connections → are vbond/vsmart/vmanage up ? ▼ ② OMP control up → show sdwan omp peers → is the Controller peer Up and learning routes? ▼ ③ BFD OMP up → show sdwan bfd sessions → are the colour-pair tunnels up? ▼ ④ App-route BFD up → show sdwan app-route stats → is loss/latency within SLA ? Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset That's the entire mental model: symptom at the top, cause at the bottom. A "voice is bad" ticket and a "whole site dark" ticket are diagnosed with the same ladder — you just find the broken rung at a different height. Pair it with the security view: if the site is up but a download got through that shouldn't have, you're now in show utd engine standard status and the security policy, not the data plane. Figure 4 — The master show-command cheat-sheet A nine-tile cheat sheet pairing each SD-WAN layer with its verification command: control connections, connection-history error codes, OMP peers, OMP routes, BFD sessions, app-route stats, security UTD status, SIG tunnels, and the DTLS port map. Keep this open while you troubleshoot. SD-WAN show-command cheat-sheet — print this Control plane show sdwan control connections DTLS up to vBond/vSmart/vMgr? Why it failed show sdwan control connection-history DCONFAIL · NOVMCFG · CRTVERFL OMP peering show sdwan omp peers show sdwan omp routes peer Up? TLOCs + prefixes learnt? Data plane (BFD) show sdwan bfd sessions tunnel up per colour pair? App SLA show sdwan app-route stats loss / latency / jitter per tunnel Security (UTD) show utd engine standard status Snort container Green? sig version SIG / DIA show sdwan secure- internet-gateway tunnel Up to Umbrella/Zscaler? Local TLOC view show sdwan control local-properties colour, NAT type, port-hop state Open these ports UDP 12346–12426 TCP 23456 (TLS) port-hop: 12346/66/86, 12406/26 underlay/untrusted overlay/trusted control/policy key insight allowed/SLA-met Your one-card playbook — keep it open on the second monitor during any SD-WAN ticket, and revisit it the night before the 300-415 exam. Pro tip — the two questions that solve almost any SD-WAN ticket (1) Is it a control problem or a data problem? Run show sdwan control connections first — that single command splits the entire problem space in two. (2) Is it reachability or inspection? If traffic flows but the wrong thing got through (or blocked), it's the security policy / UTD, not the fabric. Master those two forks and you'll out-triage engineers with years more time-served. Prove you've got it Take any real ask — "the Bengaluru branch can browse but Teams calls are dropping" — and say it out loud: control connections (rule out), OMP (rule out), BFD (rule out — all tunnels up), so it's app-route SLA on the voice class → check show sdwan app-route stats and the AAR policy. If you can name the rung for a symptom cold, you're ready for the SOC floor and the exam. Career + cert wrap. This is lesson 10 of 10 — you've gone from "why SD-WAN" to the four planes, the controllers, onboarding, OMP, the data plane, policies, app-aware routing/QoS, and now security and ops. The exam to target is Cisco ENSDWI 300-415 (a CCNP Enterprise concentration), which weighs Policies and Management & Operations / Troubleshooting heavily — exactly this lesson. What to lab next: build a zone-based firewall with a unified policy in Cisco dCloud or the always-on SD-WAN sandbox, configure a DIA breakout, stand up an Umbrella SIG tunnel, then deliberately block UDP 12346 and practise reading the failure bottom-up. Do that loop five times and the show-command ladder becomes muscle memory. Back one step: App-Aware Routing & QoS Back to the start: SD-WAN Fundamentals Quick check · Q4 of 10 Aditya at Flipkart gets a P1: "the Hyderabad branch is completely unreachable." Which single command does he run FIRST to split the problem in two? a) show sdwan app-route stats b) show utd engine standard status c) show sdwan bfd sessions d) show sdwan control connections Correct: d. show sdwan control connections is the bottom rung and the fastest way to separate a control-plane outage from a data-plane one. If control is down, OMP/BFD/app-route are all down as a consequence. App-route and BFD are upper rungs; the UTD status is about inspection, not reachability. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Do I still need a physical firewall at each branch? What's the difference between DIA and SIG? Why is the troubleshooting order control → OMP → BFD and not the reverse? Control connections are down — which command tells me WHY? Which ports must the firewall allow for the fabric to come up? Is the controller a security risk I should worry about? Pre-curated from Cisco SD-WAN 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 In Cisco SD-WAN, which single container on the cEdge hosts the zone-based firewall, IPS, URL-Filtering and AMP? a) The vSmart Controller process b) A standalone ASA appliance per branch c) The Snort UTD (Unified Threat Defense) security virtual image d) The vBond Validator Correct: c. The UTD security virtual image runs Snort as a container inside IOS-XE and powers all four inspections on the cEdge. vSmart and vBond are controllers (control plane), and the whole point of embedded security is to avoid a separate ASA box per branch. Q6 · Apply A branch needs Office 365 to exit locally for speed but the security team requires every internet flow inspected. The cEdge is too small to run the on-box UTD stack. What do you configure? a) DIA for the breakout + steer that traffic into a SIG (Umbrella/Zscaler) over an automatic SIG tunnel b) Backhaul everything to HQ over MPLS c) Disable NAT so traffic stays internal d) An app-aware routing SLA class only Correct: a. DIA gives the local speed; the SIG gives the cloud firewall when the box can't run on-box UTD. Backhaul defeats the purpose; disabling NAT breaks DIA; an SLA class steers paths but inspects nothing. DIA + SIG is the standard pairing. Q7 · Apply You configure DIA + an Umbrella SIG tunnel, but users still reach blocked sites by typing raw IP addresses. Why is the policy bypassed? a) The cEdge needs a reboot b) Umbrella enforces by DNS/domain — raw-IP traffic (or a local proxy answering DNS) never reaches Umbrella, so no policy is applied c) OMP is down d) The SIG tunnel only works over MPLS Correct: b. Umbrella's DNS-layer enforcement keys on the domain lookup; a host dialling a raw IP (or a proxy that answers DNS locally) skips that lookup and the policy. It's a known DIA/Umbrella gotcha, not a reboot, OMP, or transport issue — you'd add the cloud-delivered firewall / full SIG inspection to cover non-DNS flows. Q8 · Analyze A new branch shows control connections UP, but show sdwan omp peers shows the Controller peer DOWN and no routes are learned. BFD sessions are also absent. Most likely root cause? a) The branch ISP is down b) URL-Filtering blocked OMP c) AMP quarantined the routing table d) An OMP/colour issue (e.g. max-control-connections 0 or a missing colour) stops TLOC/route exchange — and with no OMP TLOCs, BFD can't build Correct: d. Control is up, so the underlay and controllers are reachable; the break is at OMP. A tunnel set to max-control-connections 0 or a colour problem prevents TLOC/route exchange, and without OMP TLOCs the data plane has nothing to build BFD on. URL-Filtering and AMP act on user traffic, not OMP, and the ISP being down would have dropped control connections too. Q9 · Analyze Control and OMP are healthy. show sdwan bfd sessions shows the mpls colour UP but the biz-internet colour DOWN with climbing transitions. Where do you look? a) Re-image the vSmart Controller b) Reattach the device template in SD-WAN Manager c) The internet colour's underlay — a firewall/NAT/MTU problem on the IPsec/BFD ports (UDP 12346–12426) d) The URL-Filtering category list Correct: c. One colour up and the other down, with control/OMP fine, isolates the fault to that colour's transport: a firewall dropping the IPsec/BFD ports, an unfriendly NAT, or MTU/fragmentation. The controller and template are ruled out by healthy control/OMP, and URL-Filtering has nothing to do with tunnel establishment. Q10 · Evaluate Two engineers debug "the branch is down." A starts at show sdwan bfd sessions and works downward; B starts at show sdwan control connections and works upward. Whose approach is sounder and why? a) A — BFD carries user traffic so it's the most important layer to check first b) B — control connections are the foundation; OMP and BFD depend on them, so bottom-up finds the cause instead of chasing a symptom c) Identical — order never matters d) A — top-down is always faster Correct: b. Bottom-up matches the dependency chain: BFD needs OMP TLOCs, OMP needs control connections. Starting at BFD when control is the real fault makes you debug a symptom three layers above the cause. B's order isolates the lowest broken rung first, which is faster and correct; order absolutely matters. 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: In one line, why do you start an SD-WAN outage at 'show sdwan control connections' instead of 'show sdwan bfd sessions'? Then compare to the expert version. Compare with expert answer Expert version: Because BFD and OMP both depend on control connections being up — if you start at the top of the stack you'll diagnose symptoms of a lower failure, whereas the one command at the bottom (control connections) instantly splits the problem into control-plane vs data-plane and points you at the real cause. ### 🗣 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 Security, DIA & Troubleshooting at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary cEdge / WAN Edge The branch router — IOS-XE SD-WAN. Runs the data plane and the on-box security stack. vEdge is the older Viptela-OS sibling. UTD (Unified Threat Defense) The security virtual image (a secapp-utd .tar) that runs Snort as a container inside IOS-XE; hosts firewall, IPS, URL-Filtering and AMP. Zone-Based Firewall (ZBFW) Stateful firewall using zones + zone-pairs; actions inspect/pass/drop; default-deny between zones with no pair; router traffic uses the self zone. Unified security policy One policy that attaches an advanced inspection profile (IPS + URL-Filter + AMP + TLS) to a firewall sequence — inspect once, not four bolt-ons. IPS / IDS (Snort sig sets) Signature engine; IDS alerts, IPS blocks. Three sets by CVSS: Connectivity, Balanced (default), Security. AMP Advanced Malware Protection — file reputation + ThreatGrid sandboxing of downloads, catching malware signatures miss. DIA (Direct Internet Access) Branch breaks out to the internet locally (NAT + DIA route) instead of backhauling to HQ — fast SaaS, less MPLS use. SIG (Secure Internet Gateway) Cloud security stack (Cisco Umbrella, Zscaler, Cisco Secure Access) the branch steers DIA traffic into over an automatic SIG tunnel. SIG tunnel Automatic IPsec (Umbrella) or IPsec/GRE (Zscaler) tunnel built from a feature template via the first NAT-outside WAN interface. Control connections DTLS/TLS tunnels from the WAN Edge to Validator/Controller/Manager (UDP 12346 / TCP 23456). The foundation everything else depends on. connection-history codes Failure reasons from show sdwan control connection-history: DCONFAIL (port blocked), NOVMCFG (no template), CRTVERFL/CTORGNMMIS (cert/org mismatch). BFD sessions Bidirectional Forwarding Detection — the data-plane IPsec tunnels between WAN Edges per colour-pair; rising transitions = an underlay problem. #### 📚 Sources Cisco — Catalyst SD-WAN Security Configuration Guide, IOS XE 17.x: "Enterprise Firewall with Application Awareness" (zones, zone-pairs, inspect/pass/drop, self zone, unified security policy / advanced inspection profile). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/security/ios-xe-17/security-book-xe/m-firewall-17.html - Cisco — Catalyst SD-WAN Security Configuration Guide, IOS XE 17.x: "Integrate Your Devices With Secure Internet Gateways" + "Cisco Umbrella Integration" (automatic IPsec/GRE SIG tunnels, first NAT-outside interface, SIG service route, NAT mandatory for DIA). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/security/ios-xe-17/security-book-xe/m-secure-internet-gateway.html - Cisco — IOS XE Catalyst SD-WAN Qualified Command Reference / Troubleshoot Control Connections (214509) + Troubleshoot BFD & Data Plane (214510): show sdwan control connections / connection-history error codes (DCONFAIL, NOVMCFG, CRTVERFL), show sdwan omp peers/routes, show sdwan bfd sessions. cisco.com/c/en/us/support/docs/routers/sd-wan/214509-troubleshoot-control-connections.html - Cisco — Catalyst SD-WAN Hardening Guide + Getting Started (Overlay Bring-Up): DTLS UDP 12346 / TLS TCP 23456, port-hopping 12346/12366/12386/12406/12426, firewall ports to open. sec.cloudapps.cisco.com/security/center/resources/Cisco-Catalyst-SD-WAN-HardeningGuide - Cisco Talos — "Active exploitation of Cisco Catalyst SD-WAN by UAT-8616" (May 2026): CVE-2026-20182, a CVSS 10.0 auth-bypass in the SD-WAN Controller/Manager control-connection peering handshake (NETCONF exposure, high-privileged login, root via CVE-2022-20775 downgrade), with hardening recommendations. blog.talosintelligence.com/uat-8616-sd-wan/ + Cisco advisory cisco-sa-sdwan-rpa2-v69WY2SW - Cisco Community — "SD-WAN edge device: there is no BFD and OMP sessions" (control connections must be up first) + Cisco SWAT SD-WAN Lab (IPS/UTD install, 4 vCPU/8 GB, signature sets, detection vs protection). community.cisco.com/t5/sd-wan-and-cloud-networking · swat-sdwanlab.github.io/mydoc_ips.html - Cisco Learning Network — 300-415 ENSDWI exam topics (Security: Secure DIA, Zone-Based Firewall, IPS/IDS, Umbrella; Management & Operations: troubleshooting vEdge/vSmart/vBond, packet capture). learningnetwork.cisco.com/s/ensdwi-exam-topics ### What's next? That's the full ten-part journey — from why SD-WAN exists to securing and troubleshooting it like an L3. Loop back to the fundamentals any time you want to re-anchor the four planes and the overlay before the exam. Next · Back to: Cisco SD-WAN Fundamentals → 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