Course contents

Unit 6: Advanced securityLesson 6.1 (1 of 11 in this unit)3 of 25 in the Advanced Cisco SD-WAN course

Cisco SD-WAN security overview

The layers of SD-WAN security, which feature does which job, where each one runs, and the licences and platform resources they depend on.

Advanced · 12 min read

You'll learn to name the layers of Cisco SD-WAN security, say which feature does which job and where it runs, choose features for a guest network, a payment network and a branch with direct internet access, and troubleshoot in a sensible order.

Technical definition

SD-WAN security is not one feature. It is a set of layers: trusted control connections, encrypted tunnels between WAN Edge routers, segmentation into service VPNs, a zone-based firewall, threat inspection on the edge, and security services in the cloud. Each layer stops a different kind of problem, and none of them replaces the others.

Six layers, six different jobs

Security questions about an SD-WAN usually fail because two layers get mixed up. Encryption is not inspection. Separate VPNs are not a firewall. Keeping the layers apart makes the rest of this course easier.

  1. Trust and the control plane. Before a WAN Edge joins the fabric, it and the SD-WAN Manager (formerly vManage), SD-WAN Controller (vSmart) and SD-WAN Validator (vBond) prove their identity with certificates. The control connections then run over DTLS or TLS. This layer decides who may be part of the network.
  2. Data-plane encryption. User traffic between WAN Edge routers is carried in IPsec tunnels, so a transport provider cannot read or change it.
  3. Segmentation. Service VPNs keep corporate, voice, guest and payment traffic in separate routing tables. Traffic moves between them only where you configure it to.
  4. The application-aware firewall. A zone-based, stateful firewall on the edge decides which traffic may pass between groups of VPNs. See the zone-based firewall lesson.
  5. Threat features on the edge. Intrusion prevention (IPS), URL filtering and advanced malware protection (AMP) look at the content of traffic. The TLS proxy decrypts web traffic so those features can see inside it.
  6. Cloud security. DNS-layer security and tunnels to a Secure Internet Gateway (SIG) send internet-bound traffic to a security service in the cloud. This is the SD-WAN side of SASE and SSE; the idea is explained in What is SASE?.

Layers 1 and 2 are on by design. Layers 3 to 6 are choices you make per site, per VPN and per risk.

Six security layers on an SD-WAN edge
Six security layers on an SD-WAN edgeSix layers do different jobs. One: trust, certificates between the WAN Edge and the controllers, with control connections over DTLS or TLS. Two: data-plane encryption, IPsec between WAN Edge routers. Three: segmentation with service VPNs. Four: a zone-based, stateful, application-aware firewall. Five: threat features, which are IPS, URL filtering, AMP and the TLS proxy. Six: cloud security, DNS-layer security and tunnels to a Secure Internet Gateway.1 TrustCertificates between WAN Edge and controllersControl connections over DTLS or TLS2 EncryptionIPsec between WAN Edge routersA transport provider cannot read or change it3 SegmentationService VPNsCorporate, voice, guest and payment stay apart4 FirewallZone-based, stateful, application-awareDecides what passes between groups of VPNs5 Threat featuresIPS, URL filtering, AMP, TLS proxyLook inside the traffic itself6 Cloud securityDNS-layer security, SIG tunnelsInternet traffic checked by a cloud service

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Encryption is not inspection, and separate VPNs are not a firewall. Layers 1 to 3 are on by design; layers 4 to 6 you choose and configure.

Which feature stops what, and what it needs

Which feature stops what, and what it needs
Which feature stops what, and what it needsFeature; What it stops or enforces; Where it runs; What it depends on. Certificates and control connections: Unknown devices joining the fabric; eavesdropping on control traffic Every device A working certificate setup and reachability to the controllers IPsec between edges: Reading or changing user traffic in transit WAN Edge Tunnels that are up; nothing to enable per application Service VPNs: Unwanted mixing of networks WAN Edge Correct VPN on each interface and LAN Zone-based firewall: Traffic between zones that no rule allows WAN Edge Zones that contain the right VPNs; application recognition for application rules IPS: Known exploit patterns, by signature WAN Edge, in a container or virtual service Spare memory and storage, a security package, the right subscription URL filtering: Access to blocked website categories or poor-reputation sites WAN Edge, in a container or virtual service The same resources, a category and reputation source, and decryption for full HTTPS visibility AMP: Known malicious files; files judged by analysis in the cloud WAN Edge, with a cloud lookup Resources, reachability to the cloud service, the right subscription TLS proxy: Nothing alone; it lets other features see inside HTTPS WAN Edge Certificates trusted by clients, resources, and a decision on what not to decrypt DNS-layer security: Lookups of bad domains Cloud resolver, steered by the edge A cloud account and the DNS queries actually using it SIG tunnels: A wide set of web and cloud controls, delivered by the cloud service Cloud, reached by a tunnel from the edge A cloud service subscription, tunnels, and a plan for tunnel failureFeatureWhat it stops or enforcesWhere it runsWhat it depends onCertificates andcontrolconnectionsUnknown devices joiningthe fabric; eavesdroppingon control trafficEvery deviceA working certificatesetup and reachability tothe controllersIPsec betweenedgesReading or changing usertraffic in transitWAN EdgeTunnels that are up;nothing to enable perapplicationService VPNsUnwanted mixing ofnetworksWAN EdgeCorrect VPN on eachinterface and LANZone-basedfirewallTraffic between zonesthat no rule allowsWAN EdgeZones that contain theright VPNs; applicationrecognition forapplication rulesIPSKnown exploit patterns,by signatureWAN Edge, in a containeror virtual serviceSpare memory and storage,a security package, theright subscriptionURL filteringAccess to blocked websitecategories orpoor-reputation sitesWAN Edge, in a containeror virtual serviceThe same resources, acategory and reputationsource, and decryptionfor full HTTPS visibilityAMPKnown malicious files;files judged by analysisin the cloudWAN Edge, with a cloudlookupResources, reachabilityto the cloud service, theright subscriptionTLS proxyNothing alone; it letsother features see insideHTTPSWAN EdgeCertificates trusted byclients, resources, and adecision on what not todecryptDNS-layer securityLookups of bad domainsCloud resolver, steeredby the edgeA cloud account and theDNS queries actuallyusing itSIG tunnelsA wide set of web andcloud controls, deliveredby the cloud serviceCloud, reached by atunnel from the edgeA cloud servicesubscription, tunnels,and a plan for tunnelfailure

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Read each row across: the left box names the item, the others describe it.

The last column is where designs go wrong. Subscription names, licence tiers and which routers support which feature change between releases, so treat that column as a prompt to check current documentation, not as a reference.

Features that live inside the router

IPS, URL filtering and AMP do not run in the normal forwarding path alone. On IOS XE SD-WAN they run in a separate container or virtual service on the router, and the firewall hands matching traffic to it. That engine needs memory and storage that the router would otherwise use for other work, plus a security package installed from the SD-WAN Manager. Two consequences follow.

  • Platform and sizing matter before design starts. A small branch router may not have the spare resources for every feature, or may support only some of them. The platform's own guide has the figures for your release.
  • Inspection costs throughput and adds latency. Measure it on the platform you will actually deploy, with realistic traffic, not on a lab router with no load.
Where do the cloud features fit in this picture?

They move the work off the router. DNS-layer security and SIG tunnels use the edge only to steer traffic, so branch router resources matter less, and tunnel capacity and the cloud service matter more. The trade-off is a dependency on a service you do not run. That choice is the subject of the SASE lesson.

The guided security workflow in the Manager

The SD-WAN Manager offers a guided way to build a security policy. It asks which kind of protection you want, for example compliance, guest access or direct cloud access, and then walks through the firewall, IPS, URL filtering, AMP and DNS settings that fit. The scenario names and the order of the pages vary by release, so read what your Manager shows instead of relying on a fixed list. The workflow produces a security policy that you then attach to a device template or to a site. It builds the same objects you could build by hand, so knowing what each feature does remains necessary.

Choosing features for three situations

Choosing features for three situations
Choosing features for three situationsSituation; Reasonable starting set; Why. Guest access at BR-02 (VPN 30, 10.30.1.0/24): Guest VPN in its own zone; firewall allowing only internet, no route to corporate; URL filtering by category; DNS-layer security Guests are unmanaged devices. The main aims are isolation and keeping them off harmful sites. IPS and AMP add cost and are optional. Payment network (VPN 40, 10.40.1.0/24): Own VPN and zone; firewall with narrow rules to the payment destinations only; IPS in detection first; TLS proxy only where policy and law allow it; logging kept Compliance standards ask for segmentation, restricted access and evidence. You need to show what is allowed and prove it with logs. Branch with direct internet access (VPN 10 out to the internet): Firewall; URL filtering; DNS-layer security or SIG; IPS and AMP if the platform and risk justify them; TLS proxy if most web traffic is HTTPS and you need to inspect it Traffic leaves the corporate network without passing a central firewall, so the branch itself must provide those controls, or the cloud must.SituationReasonable starting setWhyGuest access at BR-02(VPN 30, 10.30.1.0/24)Guest VPN in its own zone; firewallallowing only internet, no route tocorporate; URL filtering by category;DNS-layer securityGuests are unmanaged devices. Themain aims are isolation and keepingthem off harmful sites. IPS and AMPadd cost and are optional.Payment network (VPN40, 10.40.1.0/24)Own VPN and zone; firewall withnarrow rules to the paymentdestinations only; IPS in detectionfirst; TLS proxy only where policyand law allow it; logging keptCompliance standards ask forsegmentation, restricted access andevidence. You need to show what isallowed and prove it with logs.Branch with directinternet access (VPN 10out to the internet)Firewall; URL filtering; DNS-layersecurity or SIG; IPS and AMP if theplatform and risk justify them; TLSproxy if most web traffic is HTTPSand you need to inspect itTraffic leaves the corporate networkwithout passing a central firewall,so the branch itself must providethose controls, or the cloud must.

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Read each row across: the left box names the item, the others describe it.

These are starting points, not Cisco requirements. VPN numbers, subnets and site IDs are examples from the lab. The two labs in this course apply the guest and payment cases: secure guest access and PCI compliance.

What these features do not do

  • Separate VRFs are not a firewall. VPN 30 and VPN 10 cannot reach each other by default, but that is a routing fact. Add route leaking or a shared service and the separation is gone, with no rule to log it. A firewall states what is allowed and records what was refused.
  • Encryption does not inspect. IPsec protects traffic between your own edges. It says nothing about whether the traffic is safe.
  • Inspection cannot see what it cannot read. Without the TLS proxy, IPS and URL filtering work from limited information about HTTPS, such as the name a client asks for. Content stays hidden.
  • Signatures catch what is known. New attacks and misconfigured applications are not stopped by a signature that does not exist yet.
  • Edge security does not secure the LAN. A compromised laptop inside VPN 10 is still inside VPN 10.

A troubleshooting order for a security policy that seems to do nothing

Start at the bottom layer and move up. Each step rules out a whole class of causes.

  1. Does the traffic reach the router? Check routing and the LAN side. A missing route is not a security fault.
  2. Is it in the right VPN and zone? A VPN that belongs to no zone is outside the firewall's rules, and what that means depends on the release.
  3. Is the policy attached? A policy that exists in the Manager but is not part of the device's template does nothing.
  4. Is the traffic encrypted beyond reach? If a feature needs to see inside HTTPS, check the TLS proxy.
  5. Is inspection healthy? Check the engine's status, the signature or category data, and that the router has resources free.
show sdwan control connections show sdwan bfd sessions show sdwan zbfw zonepair-statistics show utd engine standard status

One command per layer: control trust, tunnels, firewall counters, inspection engine. The zbfw and utd commands are covered in the firewall and IPS lessons; check the exact syntax on your release.

Example output written for this lesson, simplified; real output has more fields and a different layout
BR-01#show sdwan control connections
PEER    PEER     PEER SYSTEM  SITE  PEER PRIV     LOCAL         STATE  UPTIME
TYPE    PROT     IP           ID    IP            COLOR
vsmart  dtls     10.255.0.11  1     10.255.0.11   mpls          up     12:03:41:07
vsmart  dtls     10.255.0.11  1     10.255.0.11   biz-internet  up     12:03:40:55
vmanage dtls     10.255.0.10  1     10.255.0.10   mpls          up     12:03:41:02
BR-01 has authenticated control connections to the Controller and the Manager, so layer 1 is healthy. If these were down, nothing above them would be worth checking. The Validator is used at the start to introduce the edge, so it may not be listed once the other connections are up.

Where each feature is taught

Test yourself on the security layers

Predict · scenario 1

A colleague says guests at BR-02 are safe because their traffic is in VPN 30 and the tunnels use IPsec. What is the best response?

Predict · scenario 2

IPS is configured for VPN 10 at BR-01 but sees no HTTPS attacks inside web sessions. The IPS engine is healthy. What is the most likely reason?

Predict · scenario 3

You must give a payment network at a branch the strongest case for an audit. Which set is the best starting point?

Predict · scenario 4

A new security policy exists in the Manager, but BR-03A shows no firewall counters at all. The control connections are up and traffic flows. What do you check next?

FAQ

Is the IPsec between WAN Edge routers a firewall?
No. IPsec keeps traffic private and unchanged while it crosses the transport network. It does not look at what the traffic is or decide whether it should be allowed. A packet carrying malware is delivered just as safely as any other packet.
Do I need every security feature at every branch?
No. Choose by risk. A branch with only private traffic towards the data centre needs less than one with direct internet access for guests. Each inspection feature also costs router resources, and some depend on subscriptions, so turning everything on everywhere is rarely the right design.
Why does a feature that is configured still do nothing?
Usually because traffic does not reach it: the VPN is not covered by the policy, the policy is not attached to the right site, or the traffic is encrypted and the feature cannot see inside it. Work through the layers in order before changing the policy itself.