SDWSCS Part 5: Secure DIA & Service Chaining

Parts 2–4 built the individual controls; this part assembles them into the two deployment patterns Cisco calls “dedicated security options”: secure DIA — the branch breaks out locally with the full embedded stack in the path — and service chaining — traffic is steered across the fabric to a security stack that lives somewhere else. They’re opposite answers to the same question: where should this VPN’s traffic meet its firewall?

Secure DIA, assembled

The plumbing of DIA was ENSDWI material (Part 9): NAT on the transport interface, plus either a centralized data policy (nat use-vpn 0) or a service-side static route pointing at VPN 0. What SDWSCS adds is the security wrap. The reference design for a branch with local breakout:

1. ZBFW zone pair LAN → WAN with inspect rules scoped to what the site is actually allowed to do directly (typically web + a SaaS application list), drop otherwise.
2. Advanced inspection profile on those rules: IPS (Balanced), AMP, URL filtering with reputation threshold.
3. Decrypt policy narrow: uncategorised + low-reputation destinations, never-decrypt for the regulated categories.
4. DNS security as the backstop (Umbrella integration — Part 7 covers the full version).
5. DIA fallback behaviour decided explicitly: if the local breakout path dies, does that traffic fail over to backhaul through the hub (and hit the hub’s security stack), or fail closed? Both are legitimate; not deciding is not.

The failure-mode question in that last step is the one design reviews miss. If Internet-bound traffic can follow both DIA and backhaul paths at different times, both enforcement points need equivalent policy, or a circuit flap silently changes your security posture.

Verification is the Part 2–4 toolkit plus NAT: show sdwan zonebfwdp sessions, show utd engine standard status, show ip nat translations, and vManage’s Monitor → Security dashboard for the aggregate view.

Service chaining: the fabric steers, the firewall decides

Some traffic shouldn’t be inspected by a router container, no matter how good Snort has got — payment VPNs with hard audit requirements, OT segments, anything your regulator expects a dedicated, separately-administered firewall for. Service chaining answers this without hairpinning everything through one DC.

The mechanism (this was exam-level in ENSDWI Part 10; here it’s deployment-level):

1. The service-hosting edge advertises the service. On the edge in front of the firewall stack, the service VPN declares service FW address <firewall-ip>. That edge advertises an OMP service route — “FW is reachable via me” — into the fabric for that VPN.
2. Policy steers traffic to the service. Two flavours:
   • Control policy (vSmart, topology-level): match routes/TLOCs, action ... set service FW. Whole-prefix steering — everything from spoke A towards prefix X transits the firewall.
   • Data policy (per-flow): match on 5-tuple/application, set service FW. Only the flows that need inspection detour; the rest route normally.
3. The firewall does its job and returns traffic to the service edge, which forwards normally. The firewall is a bump in the path — it needs routes back, and asymmetry is the classic break: if return traffic bypasses the chain, a stateful firewall drops the session. Symmetric steering policy (both directions matched) is not optional.

vSmart# show omp services
ADDRESS-FAMILY  VPN  SERVICE  ORIGINATOR   PATH-ID  LABEL
ipv4            10   FW       10.0.0.7     66       1005

If the service route isn’t in show omp services, nothing downstream matters — start there, then confirm the policy actually sets the service (show sdwan policy from-vsmart), then chase the return path.

Design patterns that recur

Requirement	Pattern
Regulated VPN, few sites	Chain to regional firewall pair via control policy
Only specific app flows need deep inspection	Data-policy chaining, everything else DIA
Guest Wi-Fi	DIA with URL filtering + reputation, no chain — don’t spend firewall capacity on guests
Shared services inspection between VPNs	Chain at the hub where the route leaking happens

The honest trade-off table: embedded security scales out (every new site brings its own enforcement) but multiplies policy instances; chaining concentrates policy in one auditable place but concentrates failure and adds path stretch. Most estates run both, split by VPN — which is exactly the hybrid posture Part 2 predicted.

Next up, Part 6: SASE — the argument that half of this enforcement belongs in the cloud, what Cisco’s SASE architecture actually consists of, and the use cases where it beats everything in Parts 3–5.