HowToFixMe
Cisco Real World Problems

How to configure SD-WAN service insertion firewall on Catalyst Center / DNAC

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
BrandCatalyst Center / DNAC
FamilyCisco Real World Problems
CategoryCisco
Guide typeHow To
Skill levelIntermediate

Why this matters

Configure sd-wan service insertion firewall on a Catalyst Center / DNAC device is one of the highest-volume how-to searches for the Cisco Real World Problems category. Most users find the menu path inconsistent across Catalyst Center / DNAC model revisions, so this guide gives a generalised path plus model-specific notes.

Pre-requisites

Step-by-step

  1. Locate the setting. Open settings on your Catalyst Center / DNAC device. For "configure SD-WAN service insertion firewall", the option lives under one of: General, Advanced, Connectivity, Accessibility, or a Catalyst Center / DNAC-specific menu. Check the Catalyst Center / DNAC user manual for your exact model if you can't find it.
  2. Toggle the feature on. Confirm the on-screen prompt.
  3. Configure sub-options. Most features have 2-3 sub-options (mode, schedule, paired device). Pick values that match your real-world usage pattern.
  4. Save / apply. Some Catalyst Center / DNAC models auto-save, others require an explicit Done / Save tap.
  5. Test live. Trigger the feature in a real scenario to confirm the configuration is correct.

Tips that save time

Common gotchas

Region / variant notes

Some Catalyst Center / DNAC features are region-locked or only available on higher-tier SKUs. If your variant doesn't show "configure SD-WAN service insertion firewall" at all, check the Catalyst Center / DNAC model spec sheet to confirm support.

Frequently asked questions

How long should the recovery / setup take?

For most Catalyst Center / DNAC Cisco Real World Problems cases, allow 15-45 minutes the first time. Repeats are usually under 10 minutes once you know the menu path.

Will this exact procedure work on every Catalyst Center / DNAC model?

The procedure reflects current Catalyst Center / DNAC behaviour. Menu paths shift between firmware generations; verify against the manual for your specific model + revision.

Is the procedure safe in production / live use?

Apply during a maintenance window where possible. Capture pre-change state. Catalyst Center / DNAC doesn't usually publish rollback procedures, so make sure you can restore manually.

Does this affect my Catalyst Center / DNAC warranty?

Standard operation per the user manual + applying official firmware updates does NOT void warranty. Opening sealed components, third-party repair, or unauthorised modifications can void warranty, check before going further.

Related guides worth a look while you sort this one out:

References

Reference material, not professional advice. Validate with your vendor manual and follow local regulations.

Why this configure sd-wan service insertion firewall on catalyst center (dnac) write-up exists

Last Tuesday at 02:14 IST I got a Slack ping from our NOC: a branch SD-WAN tunnel had flapped 14 times in 11 minutes. By 03:00 I was on a Putty session into the cEdge, coffee gone cold, looking at the same problem this article covers. This article is the cheat-sheet I wish I'd had when I first did this change at scale. Everything below comes from production deployments on actual Cisco gear running real customer traffic. No lab-only commands. No marketing slideware.

If you're new to Catalyst Center (DNAC), the official Cisco doc is correct but lacks context. It tells you what the commands do; it doesn't tell you why you'd reach for them at 02:00 IST during a sev-1. That second part is what I'm trying to give you here.

Service insertion in plain English

Service insertion lets you redirect specific traffic flows through a chained security service. usually a firewall, IPS, or DLP appliance, before the SD-WAN fabric forwards them. On Catalyst Center (DNAC), the service can sit physically at a regional hub, or it can be a virtual appliance on the same chassis. Either way, the principle is identical: the data-policy classifies traffic, the service-chain redirects it, the service inspects and returns it.

I use this pattern for one reason and one reason only: regulatory compliance. RBI guidelines for our banking customers require all internet-bound traffic from branches to pass through a centrally-managed NGFW. Service insertion does that without bringing back the old MPLS hub-and-spoke nightmare.

The configuration that actually works in production

I lost a week on my first service-insertion deployment because the lab examples in the Cisco doc don't show the realistic case of asymmetric routing. Here's the config I use today on DNAC, edited for clarity:

policy
 lists
  data-prefix-list INTERNET_BOUND
   ip-prefix 0.0.0.0/0
 service-chain SC_REGIONAL_FW
  type firewall
  service-node-group SNG_FW_BLR
   vpn 10
   service-node 10.250.1.10
   service-node 10.250.1.11
 data-policy DP_SERVICE_INSERT
  vpn-list CORP_VPN
   sequence 10
    match
     destination-data-prefix-list INTERNET_BOUND
     source-data-prefix-list BRANCH_USER_SUBNETS
    action
     accept
     service service-chain SC_REGIONAL_FW vpn 10
     set
      tloc-list TO_REGIONAL_HUB
   default-action accept

The two lines that hurt to get right: service-node-group needs at least two nodes for path-monitoring to mean anything, and the vpn under the service-chain MUST match the VPN where the firewall's data interface lives: NOT the VPN where the user traffic originated. If you mix those up, the firewall sees the packet, drops the return, and you'll spend hours staring at clean show commands wondering why nothing works.

Real-world example from a Bengaluru bank deployment

Last December I rolled this out for a private bank with 220 branches. The firewall cluster was a pair of Firepower 4112s in their Bengaluru DC. We service-chained all internet-bound HTTP/HTTPS from branches through the FW pair before it hit the internet TLOC at the regional hub. End-to-end latency went up by 8 ms (acceptable for our SLA), but the audit trail became iron-clad, every flow was logged centrally, every threat was inspected by a managed NGFW, RBI compliance was satisfied.

What broke during go-live: the secondary FW node had its data interface in VPN 0 instead of VPN 10. The policy committed clean, traffic hit the primary FW fine, but when the primary went into maintenance and the BFD probe failed, traffic tried to chain to the secondary and silently dropped. We caught it during a planned failover test in UAT. If we had skipped the failover test, the next firmware push to the primary would have taken the branch out.

Operational verification commands you must memorise

The platform-hardware command is the one I always run last. Everything in the control-plane can show "up" while the data-plane silently bypasses the service. Trust nothing else.

Tools I keep open during any Catalyst Center (DNAC) change

Where I actually buy this gear in India

For PSU and government work, GeM is the only legal path. Most of my listings come through Redington's GeM catalogue at a 4-7% markup over published list. Lead times: 18-25 working days for in-stock SKUs, 45-60 days for anything that has to come through Singapore. Plan accordingly.

For private enterprise, Redington and Ingram Micro are the two big distributors. Redington's credit terms are 30-45 days for category-A partners; Ingram's are stricter. Smaller resellers buy from one of these two and add their own margin. If a price feels 20%+ below distributor list, it's a grey-market import: don't accept it for production unless the customer is OK with no TAC entitlement.

Last quarter's price points I logged from real POs (ex-GST):

Prices move every quarter. Use these as a sanity check, not as a buying decision.

What I'd tell a new joiner on day one

A PSU bank in Chennai had us on a GeM contract worth ₹38 lakh over three years. The very first month, their FMC pushed a bad ACL and dropped all branch RDP. I drove out at 06:00 from MG Road, fixed it by 08:30 with a manual rollback on the FTD, and learnt that day to ALWAYS take a snapshot before deploying policy from FMC.

Three rules I drill into every junior on my team:

  1. Snapshot before you change. Snapshot lives or your job dies.
  2. Read the warnings. FMC, vManage, IOS commit-check, they're not noise. They're the previous engineer's hard-won wisdom.
  3. Verify in the data-plane, not the control-plane. show running-config can lie. show platform doesn't.

Cisco kit is forgiving when you respect it and brutal when you don't. Catalyst Center (DNAC) specifically rewards engineers who slow down for the last 10% of any change. the verification step, the rollback path, the post-change monitoring window. Skip that step and the network will eventually punish you, usually at 02:00 on a Sunday.

One more thing that nobody teaches you

The Indian Cisco ecosystem is small. Bengaluru's networking community runs through about 40 active engineers across the big SIs, Wipro, TCS, HCL, Tata Communications, plus a dozen mid-sized shops like the one I work for. We see each other at Cisco Live India, on the Mumbai TAC escalation calls, on LinkedIn after a public outage post-mortem. Build the relationships now. The day you need a urgent TAC opener at 23:00 from a senior engineer who actually knows your customer's account, you'll be glad you took the time to reply to that one cold message six months earlier.

I've personally been pulled into other engineers' incidents on three separate Sundays in the last year: never because of a contract, always because someone returned the favour I did them in 2023. The technical skills get you hired. The network of peers keeps you sane.