The COVID-19 pandemic has forced many organizations to take a renewed look at their VPN strategy. After all, with so many of the world’s users working from home, a VPN is often the only option for providing users with access to resources hosted on-premises.
For most organizations, the abrupt transition to everyone working from home was anything but smooth. Relatively few organizations had designed their VPNs to support a situation in which nearly all users were working remotely. Unsuspecting organizations encountered problems with everything from insufficient connection licensing to VPN saturation.
Part of the reason why VPN connections became completely overwhelmed was that nobody could have anticipated the sudden VPN usage spike. Another reason, however, is that VPN configurations have often failed to evolve with the times.
VPN servers have been a fixture in enterprise datacenters for the better part of two decades. Out of curiosity, I searched my own file server to see when I first began writing about VPNs. My oldest article on the subject was written way back in 1999. The point is that VPNs have been around for a very long time.
So, with that in mind, consider how different things were 20 years ago. The Internet was only just beginning to see mainstream adoption, and cloud services had yet to be invented (at least not as they exist today). Perhaps more importantly, few organizations had IT resources outside of their datacenter.
At that time, VPN technology made perfect sense. Users could establish an encrypted tunnel with a VPN server, and that would allow them to securely traverse the organization’s perimeter firewall and access the same network resources that they would have access to if they were working on site.
VPNs are much the same, but IT is very different
While VPNs still serve the same purpose today, IT is far different than it once was. In addition to the resources in its datacenter, most organizations also have resources residing in various clouds. These might include IaaS clouds like Amazon AWS and Microsoft Azure, or SaaS clouds like Microsoft 365.
So, consider what could happen if a user were to try to do all of their work while connected to their employer’s VPN. When the user attempts to access resources within the organization’s datacenter, the VPN acts as a pathway to those resources. Now suppose that the user attempts to access one of the Microsoft 365 services.
When the user first establishes a VPN session, they are assigned an IP address by the organization’s DHCP server. The DHCP server also provides the client computer with the IP address of the organization’s DNS server. When a user attempts to access a Microsoft 365 resource, the organization’s DNS server determines that the requested resource resides in the Microsoft 365 cloud, not in the organization’s own datacenter. It, therefore, forwards the request to Microsoft 365. In other words, because the user is connected to the corporate VPN, the user accesses the Microsoft 365 cloud over the organization’s Internet connection, not their own.
Using an organization’s Internet connection in this way probably isn’t a big deal if only a relatively small number of users are working remotely. However, if everyone is working remotely and the organization is suffering from VPN saturation, then allowing the organization’s own Internet connection to be used for Microsoft 365 traffic only adds to the congestion.
Microsoft 365 traffic and split tunneling
The solution to this problem is to use a technique called split tunneling. Unfortunately, I can’t show you the exact steps required for implementing split tunneling because every VPN does it differently. Even so, I want to at least explain how split tunneling works.
Normally, a VPN client redirects all of a user’s outbound traffic through the VPN tunnel, regardless of the traffic’s ultimate destination. Split tunneling allows a VPN client to be configured in such a way as to allow traffic to be selectively routed. Traffic related to resources within the corporate datacenter can be transmitted through the tunnel, while Internet traffic bypasses the tunnel and is sent through the user’s regular Internet connection instead. From a Microsoft 365 perspective, users can access Microsoft 365 directly rather than go through a VPN tunnel.
Offload Microsoft 365 traffic from your VPN
If you want to offload Microsoft 365 traffic from your VPN, then a great place to start is by enabling split tunneling and providing direct Internet access (using the user’s own Internet connection) to some of the more commonly used Microsoft 365 URLs. These are some URLs to which Microsoft recommends that clients connect directly:
- https://outlook.office365.com (TCP Port 443): This is one of the URLs that Outlook uses to communicate with Exchange Online.
- https://outlook.office.com (TCP Port 443): This URL is used by Outlook Online Web Access.
- https://<tenant>.sharepoint.com (TCP Port 443): This is the main URL used by SharePoint Online.
- https://<tenant>-my.sharepoint.com (TCP Port 443): This URL is used by OneDrive for Business.
In these URLs, you would replace <tenant> with your tenant name. The tenant name for my Microsoft 365 subscription, for example, is Posey. Therefore, my SharePoint URL would be https://posey.sharepoint.com, not https://<tenant>.sharepoint.com.
Microsoft does things a little bit differently with regard to Teams. Rather than providing a set of URLs, Microsoft simply lists a collection of port numbers. Traffic across these ports should use the user’s local Internet connection. The ports are:
- UDP 3478: Relay discovery allocation and real-time traffic
- UDP 3479: Teams audio
- UDP 3480: Teams video
- UDP 3481: Video screen sharing
Incidentally, Microsoft recommends making sure that users are running version 1.3.00.13565 or higher of the Teams client to avoid experiencing routing-related issues.
Split tunneling for your Microsoft 365 traffic: A good idea
It’s a good idea to use split tunneling for your Microsoft 365 traffic whenever possible. Doing so will give your users a better experience since they no longer have to incur the latency associated with relaying Microsoft 365 traffic through the corporate datacenter. It will also help to offload some of the congestion from your VPN. Microsoft provides a great deal of additional information about VPN split tunneling here.
Featured image: Shutterstock