Why would you want a Software-Defined WAN? The most straightforward answer is that you wish to a single place to control your WAN by policy, rather than managing dozens, hundreds, or even thousands of devices one at a time through their separate configuration files. The second part is replacing or supplementing expensive private network connections with Internet connectivity and centrally managed VPNs. The VMware SDWAN solution (formerly VeloCloud) delivers policy-based management and cloud VPNs at scale. Rohan Naggi ran me through the basic principles of SDWAN in the first video of the Build Day TV series about the VMware solution. There are three parts of the solution: physical routers deployed to each site (SD-WAN Edge), a cloud management console (SD-WAN Orchestrator), and a cloud-based network forwarding plane (SD-WAN Gateway).

One of the SDWAN solution’s key objectives is to enable branch office, home office, and edge deployment and operation without ever needing IT staff to go onsite. In the second video, we had Jeffrey Powers deploy an SDWAN appliance at his home. After plugging in the cables, all Jeff had to do was click a link that he was emailed. The device was added to Rohan’s console, then had both the latest firmware and latest configuration policy automatically applied. We also deployed an SDWAN appliance to AWS, allowing an Internet VPN independent of the AWS Private Gateway functionality and function the same as locations with hardware-based SDWAN connections. Both Rohan and Jeff have dual Internet connections for their SDWAN for redundancy and network load sharing. The fourth video demonstrated how applications continue to operate when one link fails or misbehaves. It was particularly impressive to be watching the live performance graphs shared via a Zoom conference. The graphs kept updating when Rohan unplugged the primary Internet connection. Zoom traffic simply shifted to the secondary link without interruption.

The largest part of an SDWAN policy is controlling how different types of traffic are handled, we looked at the options in the third video. For each website, application, or network port, you get to choose whether to use your existing private network, a cloud VPN or a direct Internet connection. The VPN can be routed through your tenancy in the VMware SDWAN cloud service or any of your SDWAN hardware devices, or it can be peer-to-peer between individual devices. Policies can control whether traffic is sent directly via the Internet or through one of the SDWAN VPN tunnels to another SDWAN node. The failover portion allows control of what sites, applications, or TCP ports can load share the connections or failover from one connection to another. Preventing non-critical applications from failing over will leave more bandwidth for production applications and reduce the cost of mobile network-based backup links.

One of the defining features of a mature product is its integration with other common products in the same area. Our fifth and final video in the VMware SD-WAN series looks at the integration of various firewall options, including third-party firewall options. Naturally, there is a firewall built into the SD-WAN which is controlled through the SD-WAN policies. There is also an option to use an existing on-premises firewall by sending all branch traffic back to that site. More interesting options include running a virtual edition of a third-party firewall on the SD-WAN edge device at each branch or integration with cloud-delivered firewall-as-a-service products. These integrations with existing firewall products and technologies will suit regulated industries, or when there is a segregation of duties between the WAN and security teams. The final option that we discussed is full integration into VMware’s end-user compute ecosystem with Workspace One. The integrated setup allows different levels of access for a staff member using a trusted SD-WAN connection versus an untrusted public WiFi even when they use the same laptop in both locations.

It does feel like a paradox that a software-defined solution requires dedicated hardware, but the reality is that software always runs on hardware. It would be a problem if the vendor’s hardware didn’t suit customer requirements. The first dimension is the hardware’s performance; the VMware SD-WAN ranges from Edge 610 at 10-200MBPS to Edge 3800 at 0.5-10GBPS and all with capability for multiple physical WAN connections. The SDWAN architecture allows you to avoid hairpining traffic through these edge devices, so most of the time, you only need enough bandwidth for access from the site as the VPNs can pass through the cloud gateway. The second dimension is the cost, some vendors like a pricing model tied to the physical network port count; the VMware SDWAN is a subscription-based model, with no large capital expense.

I’m impressed with the VMware SDWAN solution; I like policy-based management and no-touch onsite deployment central to this product. In the demos, the initial policy applied to Jeff’s appliance and my AWS virtual appliance was very simple. In production, you would have a fully built-out policy applied to all devices of a particular class and providing full functionality immediately. One class of devices would be work from home, another would be branch offices or retail stores, and another would be corporate offices. With a policy for each class, there would be relatively few policies, but each could be quite sophisticated and detailed. Policy-based management is essential for large populations of somewhat transient locations. Seasonal work from home staffing or temporary retail would be ideal uses, particularly since getting an Internet connection for the VPN is usually a lot quicker than provisioning a new corporate WAN circuit. If you are struggling with the complexity of WAN management or cost, the VMware SDWAN solution is worth evaluating. You might be able to accommodate a lot more WAN locations, such as work from home or edge computing environments with a secure and policy-based WAN management platform.