Implementing VPN split tunneling for Microsoft 365

Article
12/21/2023

Note

This article is part of a set of articles that address Microsoft 365 optimization for remote users.

For an overview of using VPN split tunneling to optimize Microsoft 365 connectivity for remote users, see Overview: VPN split tunneling for Microsoft 365.
For a detailed list of VPN split tunneling scenarios, see Common VPN split tunneling scenarios for Microsoft 365.
For guidance on securing Teams media traffic in VPN split tunneling environments, see Securing Teams media traffic for VPN split tunneling.
For information about how to configure Stream and live events in VPN environments, see Special considerations for Stream and live events in VPN environments.
For information about optimizing Microsoft 365 worldwide tenant performance for users in China, see Microsoft 365 performance optimization for China users.

Microsoft's recommended strategy for optimizing remote worker's connectivity is focused on rapidly mitigating problems and providing high performance with a few simple steps. These steps adjust the legacy VPN approach for a few defined endpoints that bypass bottlenecked VPN servers. An equivalent or even superior security model can be applied at different layers to remove the need to secure all traffic at the egress of the corporate network. In most cases, this can be effectively achieved within hours and is then scalable to other workloads as requirements demand and time allows.

Implement VPN split tunneling

In this article, you'll find the simple steps required to migrate your VPN client architecture from a VPN forced tunnel to a VPN forced tunnel with a few trusted exceptions, VPN split tunnel model #2 in Common VPN split tunneling scenarios for Microsoft 365.

The diagram below illustrates how the recommended VPN split tunnel solution works:

Split tunnel VPN solution detail.

1. Identify the endpoints to optimize

In the Microsoft 365 URLs and IP address ranges article, Microsoft clearly identifies the key endpoints you need to optimize and categorizes them as Optimize. There are currently just four URLS and 20 IP subnets that need to be optimized. This small group of endpoints accounts for around 70% - 80% of the volume of traffic to the Microsoft 365 service including the latency sensitive endpoints such as those for Teams media. Essentially this is the traffic that we need to take special care of and is also the traffic that will put incredible pressure on traditional network paths and VPN infrastructure.

URLs in this category have the following characteristics:

Are Microsoft owned and managed endpoints, hosted on Microsoft infrastructure
Have IPs provided
Low rate of change and are expected to remain small in number (currently 20 IP subnets)
Are bandwidth and/or latency sensitive
Are able to have required security elements provided in the service rather than inline on the network
Account for around 70-80% of the volume of traffic to the Microsoft 365 service

For more information about Microsoft 365 endpoints and how they are categorized and managed, see Managing Microsoft 365 endpoints.

Optimize URLs

The current Optimize URLs can be found in the table below. Under most circumstances, you should only need to use URL endpoints in a browser PAC file where the endpoints are configured to be sent direct, rather than to the proxy.

Optimize URLs	Port/Protocol	Purpose
https://outlook.office365.com	TCP 443	This is one of the primary URLs Outlook uses to connect to its Exchange Online server and has a high volume of bandwidth usage and connection count. Low network latency is required for online features including: instant search, other mailbox calendars, free / busy lookup, manage rules and alerts, Exchange online archive, emails departing the outbox.
https://outlook.office.com	TCP 443	This URL is used for Outlook Online Web Access to connect to Exchange Online server, and is sensitive to network latency. Connectivity is particularly required for large file upload and download with SharePoint Online.
`https://\<tenant\>.sharepoint.com`	TCP 443	This is the primary URL for SharePoint Online and has high-bandwidth usage.
`https://\<tenant\>-my.sharepoint.com`	TCP 443	This is the primary URL for OneDrive for Business and has high bandwidth usage and possibly high connection count from the OneDrive for Business Sync tool.
Teams Media IPs (no URL)	UDP 3478, 3479, 3480, and 3481	Relay Discovery allocation and real-time traffic. These are the endpoints used for Skype for Business and Microsoft Teams Media traffic (calls, meetings, etc.). Most endpoints are provided when the Microsoft Teams client establishes a call (and are contained within the required IPs listed for the service). Use of the UDP protocol is required for optimal media quality.

In the above examples, tenant should be replaced with your Microsoft 365 tenant name. For example, contoso.onmicrosoft.com would use contoso.sharepoint.com and contoso-my.sharepoint.com.

Optimize IP address ranges

At the time of writing the IP address ranges that these endpoints correspond to are as follows. It's very strongly advised you use a script such as this example, the Microsoft 365 IP and URL web service or the URL/IP page to check for any updates when applying the configuration and put a policy in place to do so regularly. If utilizing continuous access evaluation, refer to Continuous access evaluation IP address variation. Routing optimized IPs through a trusted IP or VPN may be required to prevent blocks related to insufficient_claims or Instant IP Enforcement check failed in certain scenarios.

104.146.128.0/17
13.107.128.0/22
13.107.136.0/22
13.107.18.10/31
13.107.6.152/31
13.107.64.0/18
131.253.33.215/32
132.245.0.0/16
150.171.32.0/22
150.171.40.0/22
204.79.197.215/32
23.103.160.0/20
40.104.0.0/15
40.108.128.0/17
40.96.0.0/13
52.104.0.0/14
52.112.0.0/14
52.96.0.0/14
52.122.0.0/15

2. Optimize access to these endpoints via the VPN

Now that we have identified these critical endpoints, we need to divert them away from the VPN tunnel and allow them to use the user's local Internet connection to connect directly to the service. The manner in which this is accomplished will vary depending on the VPN product and machine platform used but most VPN solutions will allow some simple configuration of policy to apply this logic. For information VPN platform-specific split tunnel guidance, see HOWTO guides for common VPN platforms.

If you wish to test the solution manually, you can execute the following PowerShell example to emulate the solution at the route table level. This example adds a route for each of the Teams Media IP subnets into the route table. You can test Teams media performance before and after, and observe the difference in routes for the specified endpoints.

Example: Add Teams Media IP subnets into the route table

$intIndex = "" # index of the interface connected to the internet
$gateway = "" # default gateway of that interface
$destPrefix = "52.120.0.0/14", "52.112.0.0/14", "13.107.64.0/18" # Teams Media endpoints
# Add routes to the route table
foreach ($prefix in $destPrefix) {New-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

In the above script, $intIndex is the index of the interface connected to the internet (find by running get-netadapter in PowerShell; look for the value of ifIndex) and $gateway is the default gateway of that interface (find by running ipconfig in a command prompt or (Get-NetIPConfiguration | Foreach IPv4DefaultGateway).NextHop in PowerShell).

Once you have added the routes, you can confirm that the route table is correct by running route print in a command prompt or PowerShell. The output should contain the routes you added, showing the interface index (22 in this example) and the gateway for that interface (192.168.1.1 in this example):

Route print output.

To add routes for all current IP address ranges in the Optimize category, you can use the following script variation to query the Microsoft 365 IP and URL web service for the current set of Optimize IP subnets and add them to the route table.

Example: Add all Optimize subnets into the route table

$intIndex = "" # index of the interface connected to the internet
$gateway = "" # default gateway of that interface
# Query the web service for IPs in the Optimize category
$ep = Invoke-RestMethod ("https://endpoints.office.com/endpoints/worldwide?clientrequestid=" + ([GUID]::NewGuid()).Guid)
# Output only IPv4 Optimize IPs to $optimizeIps
$destPrefix = $ep | where {$_.category -eq "Optimize"} | Select-Object -ExpandProperty ips | Where-Object { $_ -like '*.*' }
# Add routes to the route table
foreach ($prefix in $destPrefix) {New-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

If you inadvertently added routes with incorrect parameters or simply wish to revert your changes, you can remove the routes you just added with the following command:

foreach ($prefix in $destPrefix) {Remove-NetRoute -DestinationPrefix $prefix -InterfaceIndex $intIndex -NextHop $gateway}

The VPN client should be configured so that traffic to the Optimize IPs are routed in this way. This allows the traffic to utilize local Microsoft resources such as Microsoft 365 Service Front Doors such as the Azure Front Door that delivers Microsoft 365 services and connectivity endpoints as close to your users as possible. This allows us to deliver high performance levels to users wherever they are in the world and takes full advantage of Microsoft's world class global network, which is likely within a few milliseconds of your users' direct egress.

HOWTO guides for common VPN platforms

This section provides links to detailed guides for implementing split tunneling for Microsoft 365 traffic from the most common partners in this space. We'll add additional guides as they become available.