The built in security functions like IPS & AMP are some of the top benefits of Ciscos SD-WAN solution. The promise is a single device at the branch that provides security and WAN functionality. In the past this would have been broken out between a branch firewall like a ASA 5506 and a ISR router. There seems to be a lot of confusion around this use case and what the features are intended for. In this post I hope to clear this up, discuss the use case, and dive into the right way to configure it.

What is the intended usecase?

To cover the use-case for Secure DIA, its best to start with the misconception. When deploying NGFWs with IPS, IDS, and Malware engines it is common to filter all inbound and outbound traffic through the device. While it can be configured, this is not the intended use-case for the security functions(IPS/IDS/URL/AMP) on the Cisco SDWAN platform. The intended use-case is secure direct internet access (DIA). This means only inspecting internet bound traffic. This solves a typical design flaw. In traditional hub-spoke branch topologies the internet traffic is backhauled to the the datacenter(See Figure1). Speaking from experience, this is extremely common in todays networks. The traffic is then inspected by some beefy firewalls at the DC and punted out onto the internet. This all works great assuming you have the DC bandwidth and firewalls to handle the load. As more branches are added, DC throughput and firewalls need to continuously be expanded or re architected. This creates a monolithic scale up approach in our networks.

Figure 1

How do we solve this problem?

With secure DIA we push these basic web inspection functions down to the SDWAN appliance at the branch(See Figure2). Firewalls at the DC are maintained, however they are used for inbound and outbound DC communications. This secures all out in/outs to our network both at the DC and the branch while eliminating the pressures in a backhauled design. By only inspecting internet bound traffic, we also eliminate unnecessary strain on the edge SDWAN device and improve performance. Doing full inspection site to site often requires going up in device 1 or more tiers and increases costs. Reference graphic one for a comparison of traditional vs DIA architectures.

Figure 2

How is this architected?

From a SDWAN design standpoint, the architecture of the secure DIA feature is very simple. We enable the security services on the transport VPN which is always VPN 0(See Figure3). The SDWAN Security components are hard coded to ignore the transport VPN tunnels. This only leaves our internet traffic. Therefor, to inspect only internet traffic, we can simply enable the security features for VPN 0.

Figure 3

Final Thoughts

The Cisco SDWAN Secure Direct Internet Access (DIA) architecture solves a lot of problems in our networks today. It allows us to push security functions down to the branch and allow our users quicker access to the internet. As cloud SaaS software continues to grow, this is critical to our modern network designs. It will be interesting to see how this solution evolves overtime. While the current functionality meets most customer needs, there are still features missing that are present in a full firewall. This gap is mostly filled by Umbrella Secure Internet Gateway (SIG). Stay tuned for a later post diving into SIG!

To be continued….