Over recent weeks, many organizations rapidly adopted new remote worker policies and practices without having the benefit of time or meaningful historical data to inform the architectural decisions needed. Coupled with the adoption of video, web and VoIP conferencing technologies, an unprecedented strain has been levied across IT resources which were built for a different time.
In this blog series, I’ll dive deeper into the architectural challenges to consider and provide perspectives on how we have been assisting organizations meet their immediate needs for secure connectivity, threat and data data protection from anywhere and for any device.
Traditional VPN Implementations
A traditional VPN configuration uses a single VPN concentrator/gateway for ingress to the network. This is because in the past, users were remotely accessing applications in a data center, so it makes sense to place the VPN concentrator in the data center as well.
Another advantage of this configuration is that traditional network perimeter designs also placed a variety of protections at the organization’s internet egress point. Therefore, by bringing traffic back to HQ, the organization was able to reuse the protections it put in place for on-premise users.
However, the use of a full tunnel to a single VPN gateway is not the optimal for cloud applications. This is especially true as organizations migrate their data center applications to the cloud. The network team is tempted to implement a split tunnel as an alternative to a full tunnel, which allows internet and cloud traffic to route over the user’s normal network connection. With split tunnel, the remote user has a shorter path to the internet and cloud, but the traffic would be uninspected.
Split-Tunnel vs. Full Tunnel Configurations
Most organizations size their VPN based on some assumptions of what their normal remote workload looks like. For example, a common model is to size your VPN requirements based on typical historical workloads, such as using an estimate that no more than 30% of your workforce is remote at a given time, and presuming that the trend will continue.
What happens if you deploy your remote access VPN with a full tunnel, and the number of remote workers or the application mix suddenly changes? A configuration based on past assumptions can quickly overwhelm the number of connections that you can support on the gateway and amount of bandwidth that’s available.
Route All Traffic through the VPN: The Bandwidth Challenge
VoIP and video collaboration tools are popular, mainstream applications that require bandwidth between users at a minimum (in peer to peer configurations) and to the cloud as well when using an application with a cloud server. Network teams normally have time to plan and implement capacity before the application’s rollout, based on the projected use.
Take Zoom for example, a popular choice for enterprise video conferencing. For one on one video calls, a Zoom session at 720p video requires 1.2 Mbps of bidirectional traffic for each user. A network architect planning the rollout might look at the number of total employees, and the number of people that need conferences on a given day.