Direct Internet Access (DIA) in Catalyst SD-WAN

For years, branch internet traffic took a ridiculous journey: from the branch, across the WAN, to a central data centre, out through the corporate firewall, to the internet - and all the way back. Every Office 365 request, every YouTube video, every SaaS API call, backhauled hundreds of miles to reach a cloud that was often closer to the branch than the data centre was. Direct Internet Access ends that. It lets branch internet traffic exit locally, straight out the branch's own internet circuit.

This article covers DIA in Catalyst SD-WAN: what it is, how it is configured as a data policy, and the security question it forces. It extends the complete SD-WAN guide. Command syntax is drawn from Cisco's current 20.x documentation, clearly labelled as a documented reference.

The problem: backhaul

In a traditional hub-and-spoke WAN, branches have no local internet breakout - or if they do, it is not trusted. So all internet-bound traffic is sent across the WAN to a central site, inspected by the central security stack, and forwarded to the internet. The return path reverses it.

This made sense when internet traffic was a small fraction of the total and the applications lived in the data centre. It makes no sense now, when the majority of branch traffic is cloud and SaaS. Backhaul in that world means:

• Wasted WAN bandwidth - your expensive MPLS carries internet traffic twice (there and back) that never needed to be on it.
• Terrible latency to cloud apps - a branch in one city reaches a CDN node in that same city by going to a data centre three states away and back.
• A central chokepoint - every branch's internet traffic funnels through one security stack that has to be sized for all of it.

The solution: local breakout

DIA sends internet-destined traffic directly out the branch's local internet transport, with NAT, without touching the WAN. The branch reaches the cloud by the shortest path - its own local circuit - and the corporate WAN only carries traffic that genuinely needs to reach the corporate network.

In Catalyst SD-WAN, DIA is expressed as a data policy action (which is why it lives in the same framework as AAR). A centralised data policy matches internet-bound traffic and applies a NAT action that sends it out VPN 0 (the transport VPN):

policy
 data-policy DIA-POLICY
  vpn-list SERVICE-VPNS
  sequence 10
   match
    source-data-prefix-list BRANCH-SUBNETS
    destination-data-prefix-list INTERNET      ! 0.0.0.0/0 minus corporate
   !
   action accept
    nat use-vpn 0                              ! NAT and exit locally
    nat fallback                               ! if local internet fails, backhaul
   !
  !
  default-action accept
 !
!

The key action is nat use-vpn 0 - "NAT this flow and send it out the transport VPN's internet interface locally". The nat fallback option is the safety net: if the local internet circuit fails, traffic falls back to the traditional backhaul path so the branch is not cut off from the internet entirely.

The interface side

The transport interface needs NAT enabled so it can translate the branch's private addresses to its public internet address:

sdwan
 interface GigabitEthernet1
  tunnel-interface
   encapsulation ipsec
   color biz-internet
  !
 !
!
interface GigabitEthernet1
 ip nat outside
!
ip nat inside source list ... interface GigabitEthernet1 overload

Verification is standard NAT plus the SD-WAN policy view (documented reference):

Edge# show sdwan policy from-vsmart data-policy
Edge# show ip nat translations
Pro  Inside global      Inside local       Outside local      Outside global
tcp  203.0.113.5:1044   10.1.10.50:1044    140.82.113.3:443   140.82.113.3:443

That translation - a branch host (10.1.10.50) reaching a public address (140.82.113.3:443) via the branch's own public IP (203.0.113.5) - is DIA working: the flow went straight out the local circuit, not across the WAN.

The security question DIA forces

Here is what DIA gives you and what it takes away. It gives you local breakout - efficient, low-latency internet. It takes away the central security stack that every packet used to pass through. A branch now has traffic going straight to the internet without visiting the corporate firewall. So what protects it?

This is not optional to answer. The moment you enable DIA, every branch is an internet edge, and it needs internet-edge security. Catalyst SD-WAN offers several answers, and a real deployment uses one:

The industry has largely moved toward the cloud-delivered (SIG/SASE) model: rather than run a full security stack on every branch router, tunnel DIA traffic to a cloud gateway that provides consistent, always-updated security everywhere. But on-box security is a valid choice for branches that need local inspection or cannot depend on a cloud service. The one wrong answer is "none" - DIA without a security plan is a branch full of unprotected internet edges.

DIA design decisions

1. What is "internet"? Your DIA match must precisely separate internet traffic (breaks out locally) from corporate traffic (goes over the WAN). Usually "everything except the corporate prefix-list". Get this wrong and either corporate traffic leaks to the internet or internet traffic backhauls unnecessarily.
2. Which SaaS gets special treatment? Cloud OnRamp for SaaS measures the path to specific SaaS providers (Office 365, etc.) and can steer to the best-performing exit. Worth it for the SaaS you depend on.
3. Fallback behaviour. nat fallback keeps the branch on the internet if the local circuit dies, by reverting to backhaul. Decide whether you want it (usually yes).
4. The security model. On-box vs cloud (SIG). Decide before you deploy DIA, not after - it shapes the whole design.

Key takeaways

• DIA sends branch internet traffic directly out the local internet circuit with NAT, instead of backhauling it across the WAN to a central site. Efficient, low-latency, and it keeps expensive WAN bandwidth for corporate traffic.
• It is configured as a data policy action: match internet-bound traffic, apply nat use-vpn 0 to exit locally, with nat fallback as the safety net if the local circuit fails.
• Verify with show ip nat translations - a branch host reaching a public address via the branch's own public IP is DIA working.
• DIA removes the central security chokepoint, so every branch becomes an internet edge that needs internet-edge security: on-box (integrated firewall/IPS/URL/AMP) or cloud-delivered (SIG/SASE). "None" is the one wrong answer.
• Design carefully: define "internet" precisely, consider SaaS onramp, choose the fallback behaviour, and decide the security model before deploying.

Next: TLOC extension - sharing transports between edge routers. The full cluster index lives on the SD-WAN pillar.