Cisco SD-WAN Security, DIA & Troubleshooting: — Enterprise Firewall, SIG & the Show-Command Playbook

① 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.

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.

Branch-cEdge# show utd engine standard status

Engine version:  1.0.13_SV3.0.2_XE17.9
Profile:         Cloud-Low
System memory:
  Usage      :  32.10 %
Snort instances:  1
Engine Status:    Green

② 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).

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.

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.

Branch-cEdge# show sdwan secure-internet-gateway tunnels

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)

③ 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.

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).

Branch-cEdge# show sdwan control connections

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.

Branch-cEdge# show sdwan omp peers

                  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.

Branch-cEdge# show sdwan bfd sessions

                       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)

④ 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.

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.

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.