Cisco SD-WAN - Security Overview

Updated: Oct 29, 2019

Cisco SD-WAN - Viptela Security Features 

Cisco Viptela is Cisco’s new offering of the ever popular SD-WAN concept of which tech giants such as Juniper, VMware, Fortigate, and others are currently pushing onto the market. In summary, the purpose of SD-WAN is to simplify the method in which network devices work today. Routers, switches, and other network devices have two planes that exist on their hardware which are called control and data. The control plane handles routing updates and any traffic coming directly into the device, while the data plane handles user traffic and anything else going through the device. SD-WAN splits the control and data plane completely into their own entity, and have devices whose sole purpose is to handle control plane traffic and vice versa for data. Cisco Viptela offers this same solution with their own interpretation of how the control and data planes are created. Viptela has developed three controllers for the control plane which are respectively named vManage, vBond, and vSmart. vBond will be the only public facing device needed, as it serves as the initial authoritative responder for any new vEdges that come onto the network. vManage is the single pane of glass management tool whose purpose is to create policies to push to vEdges that come online to the network. vSmart is the server that will send all routing policies, updates, etc. to new vEdges in order to establish the data plane. vEdges are the devices that will send traffic over the data plane establishing a point to point peering with every other vEdge device that come online to the network. 

The purpose of this document is to display the fundamental security setup of the control and data planes between the controllers and edge devices. Additionally, this document outlines some of the security features Viptela offers if one was to utilize a vEdge device as not only a router/switch, but also as a small makeshift next generation firewall for a branch/midsized office. Ports and protocols that need to be opened on the firewall is also discussed in this document. 

Secured connection starts with the controllers in the control plane set up for certificate authorization. vBond, vSmart, and vManage all must share the same Root CA (Certificate Authority) in order to setup DTLS (Dynamic Transport Layer Security) connections between each controller’s respective connection to one another.  All devices come pre-installed with the standard Symantec/Vera sign manufactured certificates and therefore can be brought onto any network to begin the authentication process. There are currently three methods for PKI (Private Key Infrastructure) authentication, which are the Cisco provided cloud solution where the certs are handled by Cisco, private cloud based certs, and an enterprise on premise Root CA server responsible for maintaining the PKI infrastructure. Upon startup, vSmart attempts to connect to vBond and the two controllers start a two-way authentication process over a DTLS tunnel. vBond sends it’s trusted root CA certificate to verify it’s cert is signed by the root, along with a list of a serial number file of all the vEdges. The same process is done to verify the vBond’s certificate executed by vSmart. Once authentication is successful, the two controllers maintain a permanent DTLS tunnel and establish an OMP (Overlay Management Protocol) session. The same process is done from vSmart to vManage and vManage to vBond.   

For the controller setup process, organization name is important and must be the same amongst all controllers in a single tenant environment. The organization name will be tied to the identity certificate authenticating each controller. A multi-tenant configuration can only include different organization names amongst separate vSmart controllers. Once the organization name is agreed upon, customers can purchase Cisco provided serial numbers/tokens of all Viptela vEdge devices to be placed on the network. How these numbers are distributed to vManage is dependent upon a customer’s deployment. These purchased serial numbers are installed in vManage and sent to vBond in order to authorize the vEdges.  

For initial setup of vEdge connection to the vBond controller, the vEdge powers on and attempts to connect with the vBond Orchestrator over a DTLS encrypted connection. All vEdge devices come preconfigured with a public vBond DNS name (or IP address) that is reachable over the internet. Once a DTLS connection is established from a successful certificate authentication, vBond sends an AES-256 encrypted challenge to the vEdge containing a serial number and chassis-number. If there is a match, the vEdge then goes through the same process with vSmart, vManage, and forming a permanent DTLS connection with each controller.  

Building off the topic of control plane encryption via DTLS, Viptela offers less overhead on the data plane when vEdges form a secure IPsec connection. In a typical IPSec peering scenario, IKEv1/IKEv2 key exchange is first established to setup a secure connection known as phase 1. Phase 2 commences to form the secure data plane after the two peers agree upon authentication and integrity parameters. Each peer attempting to form an IPsec tunnel with a headend/spoke device will require additional key exchanges and with a large deployment/infrastructure can result in additional overhead on said devices. With Viptela the IPsec peering between vEdges dispenses the use of IKE altogether and utilizes its existing DTLS connections to the control plane therefore making it unnecessary to setup additional key exchanges on the data plane. Each data plane connection still generates an AES-256 symmetric key and ESP-HMAC-SHA1 integrity value on all vEdge devices. This security feature disallows the need for a key server and makes future deployments easily scalable.  

In addition to the already secure data plane encryption Viptela provides, data packets from vEdge to vEdge are practically non-decipherable. When looking at a packet capture, a user will be able to view source and destination traffic, along with DTLS connections to the control plane. However, when looking deeper into the contents of any data packet, they will all share the same details. The packet capture will display a UDP packet with destination/source IP’s but not much else that could determine what type of data is being sent over the data plane. This feature is due to the security of the Viptela software to basically append all data packets with a UDP header and essentially make all connections vEdges have with other vEdges uniform and difficult to sniff from potential attackers.  

Viptela devices/software utilizes a specific range UDP ports for control and data plane connectivity. The standard ports that should be open if there is a firewall in between controllers and vEdges are following below: 

•  Port 12346 

•  Port 12366 

•  Port 12386 

•  Port 12406 

•  Port 12426 

vEdges use these ports for communication over the control and data plane. If the vEdge is unable to establish a control connection, the vEdges will port-hop the specified ports named above until connectivity is ensured. These ports are also configurable to offset by an increment of 20 in order to expand the range of usable ports for control connections called port hopping. The port numbers that are usable when enabling this feature can be illustrated below: 

•  Port (12346 + port offset value) 

•  Port (12366 + port offset value) 

•  Port (12386 + port offset value) 

•  Port (12406 + port offset value) 

•  Port (12426 + port offset value) 

In addition, the following ports are required for vManage communication that need to be opened on the firewall, the following table lists the Administrative ports vManage requires for typical administration cases.  

vManage can also be clustered but will need the following ports to be opened in case each 

server is logically placed in separate enclaves.  

Viptela offers a generous suite of security features that can be enabled in vManage and pushed to the corresponding vEdges via security policy. vManage comes with predefined security levels to help users decide on which features they wish to enable. The features include URL redirection, firewall security zones, Application firewalling, IPS/IDS (Intrusion Prevention System/Intrusion Detection System), and DNS Umbrella inspection. The only service that requires additional licensing/purchasing is the Umbrella feature where DNS traffic is redirected to the Umbrella cloud for categorization and deeper inspection. However, if end users decide not to use the security features and wish to keep their existing firewall within their network infrastructure, Viptela offers the firewall service option. Configured as a global feature template, the firewall service option allows end users to configure a reference for a routing policy to redirect customer traffic to an existing firewall for further inspection and placed back onto its original path after the firewall allows said traffic. 

Umbrella security offers users an option to secure DNS traffic with corresponding policies and the ability to redirect all suspicious DNS requests to a blocked page or sandbox for further inspection. Cisco offers two different type of deployments in regards to their Umbrella solution. One method is to deploy the OpenDNS image as a VM (Virtual Machine) in a virtualized environment, which enables end users to have an on premise option when configuring their DNS security policies. There is also the Cisco hosted cloud OpenDNS service that is publicly reachable over the internet that offers the same function as the VM suggestion. However, in both scenarios, DNS traffic is always redirected to two public DNS addresses owned by Cisco for inspection, unless said traffic is whitelisted. With that said, Viptela’s integration with the Umbrella option is seamless and transparent if utilized. For functionality, users will need to have their DNS requests pointed towards whatever vEdge device is connected to the internet. The vEdge will act as the DNS conditional forwarder and send traffic to the OpenDNS public IP addresses based on policy rules. Connectivity to the Umbrella Cloud is authenticated via HTTPS with an API (Application Programmable Interface) token in order to enable its services. Communication is encrypted through DNScrypt and is enabled by default to provide a secure channel for authentication between the Umbrella Cloud and vEdges.  

URL Filtering and Intrusion prevention are other security features Viptela supports, which uses the Snort Inspection Engine for detailed analysis. The same engine used by Cisco’s next generation firewall, named Firepower Threat Defense. Cisco has made a concerted effort to incorporate the Snort engine into its next generation firewalls for IPS/IDS advancement capabilities. As a result, it shows the security investment Cisco has placed into the Viptela series for intrusion prevention. Web reputation and IPS signature updates are enabled in the settings screen on vManage and therefore must be connected to the internet for up to date IPS signature sets. IPS and URL filtering essentially go hand in hand with their capabilities in configuration. Both have whitelisting and blacklisting functionalities and are also easy to configure as policies. Both are also able to send alerts to an external Syslog server for updates on any potential attacks.  

The differences between the two security features are the objects that are configurable within their respective policies. IPS/IDS have three different fields of signature sets listed as balanced, connectivity, and security. Security being the highest set of rules that check the vulnerabilities of different high risk categories with a CVSS score of 8 or greater. The following categories are inspected: 

App-detect, blacklists, exploit-kits, malware-cnc, and SQL injection. In regards to URL filtering, connectivity to the cloud is necessary for category or reputation-based URL Filtering in order to check the reputation of a website. If this field is enabled the reputation scores are given to the following categories: High Risk (0-20), Suspicious (0-40), Moderate Risk (0-60), Low Risk (0-80), and Trustworthy 


If category/reputation filtering is deselected, Viptela still supports whitelisting/blacklisting of URLs, along with custom URL expressions to monitor.  

In case a separate firewall is not deployed with a vEdge Router, vManage can be configured as a zone-based firewall with service VPN’s tied to configurable zones. The following illustration provides an example:  

The following zones can be summarized as follows: Retail, Guest network, and shared services (printers, customer database). Each VPN is placed in their respective zones along with the directional configuration needed for the router to begin inspecting/firewalling traffic.  In the example above traffic originating from VPN 1 (Retail Point/Guests) is allowed inbound into VPN 3 (shared services), but not the  

other way around. The same logic that applies to an existing IOS Router’s functionality to create security zones can be applied here with this existing setup. However, the biggest differences that vEdge devices offer are the abilities to include URL filtering, DNS security, and a wider suite of IPS/IDS and layer 7 firewall capabilities. This adds an extra level of security features not included with regular Cisco IOS Routers, which already offer layer 3-7 policy inspection. With the added capabilities listed, a branch office can be completely secure depending on policy configuration.  

In a separate scenario, perhaps customers want to use the vEdge Router for what it is, which is to simply route traffic over the control and data planes without use of the security features listed. Instead, they wish to use their existing security stack, such as a firewall or NGIPS, for inspection and policing of data traffic. Viptela offers the solution of service chaining to allow data traffic to be off loaded to a configurable number of NGIPS’s (Next-Generation Intrusion Prevention System) and firewalls. This is achieved via a central control/data policy configured in vManage to redirect the intended traffic to a specified IP address referring to a firewall’s IP interface. vSmart will be the controller responsible for ensuring the service ID is sent to each corresponding service VPN configured in said policy. vSmart is aware of each service behind the vEdges in its network due to the capability of the vEdge Routers to send OMP updates using the service route Subsequent Address family Identifier  (SAFI) bits of the OMP protocol. Each service route SAFI has the following attributes: VPN ID, Service ID (your firewall and NGIPS), Labels, Originator ID, TLOC (Transport Location), and Path ID. With the creation of the control policy, the VPN ID’s are essential to identify the traffic that needs to be off loaded to a firewall. With this configured, the directional next hop, or path ID for OMP is identified along with the Service ID (firewall IP). The centralized/data policy is applied to all vEdges once applied. However, if needed, a local policy can also be configured for better granularity. The last step is to identify the firewall service IP in the service VPN feature template for the corresponding vEdges already attached to an existing device template. For better illustration, refer to the picture below: 


Washington DC |