For many companies, providing remote workoptions wasalready a rapidly growingmovement (+173% since 2005 according to Global Workplace Analytics). That was before the COVID-19 crisis, which has massively accelerated that trend and highlighted a number of remote work problems that require immediate remediation.The need to maintain security without sacrificing performance has generated unprecedented demands on enterprise IT to support work-from-anywhere productivity at a massive scale.
Microsoft 365 is well positioned to help customers fulfill that demand, but high concurrency of users working from home generates a large volume of Microsoft 365 traffic which, if routed through forced tunnel VPN and on-premises network perimeters, causes rapid saturation and runs VPN infrastructure out of capacity. In this new reality, using VPN to access Microsoft 365 is no longer just a performance impediment, but a hard wall that not only impacts Microsoft 365 but critical business operations that still have to rely on the VPN to operate.
For many years enterprises have been using VPNs to support remote experiences for their users. Whilst core workloads remained on-premises, a VPN from the remote client routed through a datacenter on the corporate network was the primary method for remote users to access corporate resources. VPNs, network perimeters, and associated security infrastructure were often purpose built and scaled for a defined volume of traffic, typically with the majority of connectivity being initiated from within the corporate network, and most of it staying within the internal network boundaries.
VPN models where all connections from the remote user device are routed back into the on-premises network (known as forced tunneling) were largely sustainable as long as the concurrent scale of remote users was modest and the traffic volumes traversing VPN were low.The use of forced tunneled VPNs for connecting to distributed and performance sensitive cloud applications is extremely suboptimal.This problem has been growing for a number of years, with many customers reporting a significant shift of network traffic patterns. Traffic that used to stay on premises now connects to external cloud endpoints.
For customers who connect their remote worker devices to the corporate network or cloud infrastructure over VPN, Microsoft recommends that key Microsoft 365 scenarios includingMicrosoft Teams, SharePoint Online, and Exchange Online are routed over a VPN split tunnel configuration. This becomes especially important as the first line strategy to facilitate continued employee productivity during large scale work-from-home events such as the COVID-19 crisis. The essence of this approach is to provide a simple method for enterprises to mitigate the risk of VPN infrastructure saturation and dramatically improve Microsoft 365 performance in the shortest timeframe possible.
This VPN split tunnel guidance is in alignment with the Microsoft 365 Network Connectivity principles, which are designed to work efficiently for remote users whilst still allowing an organization to maintain security and control over their connectivity. These connectivity principles can also be implemented for remote users very quickly with limited work yet achieve a significant positive impact on the problems outlined above.
Microsoft's recommended strategy for optimizing remote worker's connectivity is focused on rapidly alleviating the problems with the traditional approach and providing high performance with a few simple steps. These steps guide you to split tunnel Microsoft 365 traffic for a small number of defined endpoints to bypass bottlenecked VPN infrastructure and leverage cloud-based security services natively available within the Microsoft 365 stack.
For the latest information on how to plan network connectivity for your remote users and provide the best possible cloud experience watch the Enable a seamless remote work experience video below. This is one video from the 7-part Microsoft 365 Network Connectivity Video Series, which you can find at aka.ms/netvideos.