For years, businesses have used VPNs to support the remote experience of their users. While core workloads remain on-premises, VPNs in remote clients routed through data centers on the corporate network are the primary method for remote users to access corporate resources. To secure these connections, businesses will build layers of network security solutions along the VPN path. This security is built to protect the internal infrastructure and to protect mobile browsing of external websites by rerouting traffic to the VPN and then through the local Internet perimeter. VPNs, network perimeters, and associated security infrastructure are often purpose-built and extended for defined traffic, often most connections are initiated from within the corporate network, and most connections are within the internal network perimeter.
For quite some time, as long as the concurrency of remote users is moderate and the traffic traversing the VPN is low, the VPN model where all connections from remote user devices are routed back to the local network (this is called forced tunneling ) is basically Sustainable. Some customers continue to use VPN-enforced tunnels as state quorum even as their applications move from inside the corporate perimeter to the public SaaS cloud.
This problem has grown over the years, with many customers reporting significant changes in network traffic patterns. Traffic that used to be on-premises now connects to external cloud endpoints. Many Microsoft customers report that about 80% of all network traffic previously was destined for some internal source (indicated by the dotted line in the figure above). In 2020, that number is now around 20% or lower as major workloads move to the cloud, trends not uncommon in other enterprises. Over time, as the cloud journey progresses, the above model becomes increasingly cumbersome and cumbersome, preventing organizations from becoming agile as they enter the cloud-first world.
The global COVID-19 crisis has escalated this issue and requires immediate correction. The need to keep employees safe is placing unprecedented demands on enterprise IT departments to support work-from-home productivity at scale. Microsoft 365 can help customers meet that need, but the high concurrency of users working from home generates a lot of Microsoft 365 traffic that, if routed through a forced tunnel VPN and on-premises network perimeter, can quickly saturate and run an under-capacity VPN infrastructure . In this new reality, using a VPN to access Microsoft 365 is no longer a performance barrier, but a hard wall that not only affects Microsoft 365 but also critical business operations that still must rely on a VPN to function.
Over the years, Microsoft has worked closely with customers and the wider industry to deliver effective, modern solutions to these problems from our own services, aligned with industry best practices. The connectivity principles of Microsoft 365 services are designed to work efficiently for remote users, while still allowing organizations to maintain security and control their connectivity. These solutions can also be implemented quickly with limited effort, but have a significant positive impact on the above problems.
The strategies Microsoft recommends for optimizing remote worker connections focus on quickly mitigating issues and delivering high performance in a few simple steps. These steps adapt the old VPN method for some defined endpoints bypassing the bottleneck VPN server. Equivalent or even more advanced security models can be applied at different layers without securing all traffic at the corporate network egress. In most cases this can be achieved efficiently within a few hours and then can be scaled to other workloads as requirements and time permit.
In the list below, you’ll see the most common VPN scenarios seen in corporate environments. Most customers typically run Model 1 (VPN Forced Tunneling). This section will help you make a quick and safe transition to Model 2 , which can be achieved with relatively little work and has huge benefits for network performance and user experience.
The most common starting scenario for most enterprise customers. With a forced VPN, this means that 100% of traffic is directed to the corporate network regardless of whether the endpoint resides within the corporate network. Any external (Internet) traffic (such as Microsoft 365 or Internet browsing) then flows back behind an on-premises security device (such as a proxy). In the current situation where nearly 100% of users work remotely, this model places a high load on the VPN infrastructure and can significantly impede the performance of all corporate traffic, allowing the business to function efficiently in times of crisis.
The efficiency of enterprises operating under the enterprise has been significantly improved. This model allows several high-load and latency-sensitive controlled and defined endpoints to bypass the VPN tunnel and go directly to Microsoft 365 services. This significantly improves the performance of offloading services and also reduces the load on the VPN infrastructure, allowing elements that still need it to operate with lower resource contention. It is this model that this article focuses on assisting with the transition to, as it allows simple, defined operations to be performed quickly, with a large number of positive results.
Expand the range of Model 2. Instead of sending a small set of defined endpoints directly, it sends all traffic directly to trusted services such as Microsoft 365 and SalesForce. This further reduces the load on the corporate VPN infrastructure and improves the performance of defined services. Since this model may require more time to evaluate and implement feasibility, a step may be repeated later after successful implementation of Model 2.
The third model is reversed, because only traffic identified as having a corporate IP address is sent through the VPN tunnel, so the Internet path is the default route for everything else. This model requires organizations to be well-adapted to a zero trust path in order to be able to implement this model securely. It should be noted that this model, or some variants, may become the required default over time as more services move from the enterprise network into the cloud.
Microsoft uses this model internally. For information on Microsoft’s implementation of VPN split tunneling, see Running a VPN: How Microsoft Keeps Teleworkers Connected .
A more advanced version of Model 2 where any internal services are published via modern security methods or SDWAN solutions such as Azure AD Proxy, Defender for Cloud Apps, Zscaler ZPA, etc.
In this section you will discover the simple steps required to migrate a VPN client architecture from a VPN – forced tunnel to a VPN -forced tunnel in common VPN scenarios , there are several trusted exceptions, namely the VPN split tunneling model #2 .
In the Microsoft 365 URLs and IP address ranges article, Microsoft clearly identifies the key endpoints that need to be optimized and classifies them as “optimized” . Currently only four URLs and 20 IP subnets need to be optimized. This small group of endpoints accounts for approximately 70% – 80% of traffic to Microsoft 365 services, including latency-sensitive endpoints (such as those used for Teams). Essentially, this is the kind of traffic we need to pay special attention to, and the kind of traffic that puts a strain on traditional network paths and VPN infrastructure.
- Endpoints owned and hosted for Microsoft, hosted on Microsoft infrastructure
- IP provided
- Low change rate, expected to remain small (currently 20 IP subnets)
- Bandwidth and/or Latency Sensitive
- The required security elements can be provided in the service rather than inline on the network
- Dedicate approximately 70-80% of traffic to Microsoft 365 traffic
For information on how endpoints Microsoft 365 categorizes and manages them, see Manage Microsoft 365 endpoints .
The current optimized URLs can be found in the table below. In most cases, just use the URL endpoint in the browser PAC file , where the endpoint is configured to send directly, not to the proxy.
When writing the IP address ranges that these endpoints correspond to, it looks like this. It is strongly recommended that you use a script when applying configuration (like this example, Microsoft 365 IP and URL web services, or URL/IP pages), check for updates, and establish a policy on a regular basis.copy
We have identified these critical endpoints and now need to move them out of the VPN tunnel and allow them to connect directly to the service using the user’s local Internet connection. The way this is done will vary depending on the VPN product and computer platform used, but most VPN solutions will allow simple configuration policies to apply this logic. For VPN platform-specific split tunneling guidelines, see the how-to guides for common VPN platforms .
If you want to test the solution manually, you can execute the following PowerShell example to simulate the solution at the routing table level. This example adds a route for each Teams media IP subnet to the routing table. You can test Teams media performance before and after, and observe differences in routing to a given endpoint.
In the script above, $intIndex is the index of the interface connected to the Internet (which can be found by running get-netadapter in PowerShell ; look for the value of ifIndex ), and $gateway is the default gateway for that interface (which can be found by running in a command prompt ipconfig or run in PowerShell (Get-NetIPConfiguration | Foreach IPv4DefaultGateway).NextHop found).
After adding the route, you can confirm that the routing table is correct by running route print in Command Prompt or PowerShell. The output should contain the route added, showing the interface index ( 22 in this case ) and the gateway for that interface ( 192.168.1.1 in this case ):
To add routes for all current IP address ranges in the “Optimized” category, the following script variant can be used to query the current “Optimized IP Subnets” set in the Microsoft 365 IP and URL web service and add it to the routing table .
If you accidentally added a route with the wrong parameters, or just want to revert your changes, you can delete the route you just added with the following command:PowerShellcopy
The VPN client should be configured so that IP-optimized traffic is routed in this way. This allows traffic to leverage on-premises Microsoft resources like Microsoft 365 Service Front Door, like Azure Front Door , to deliver Microsoft 365 service and connection endpoints as close to your users as possible. This allows us to deliver high performance levels to users located anywhere in the world and take advantage of Microsoft ‘s world-class global network, which is likely to be done within milliseconds of the user’s direct exit.
Some administrators may need more detailed information on how to operate call flow in Teams using the split tunneling model, and how to secure connections.
For calls and conferences, as long as the “Optimized IP Subnet” required for Teams media is properly placed in the routing table, when Teams calls the GetBestRoute function to determine which local interface corresponds to the route it applies to a particular destination, the The Microsoft target in the outgoing Microsoft IP block returns the local interface.
Some VPN client software allows URL-based routing. However, Teams media traffic does not have a URL associated with it, so IP subnets must be used to control routing of this traffic.
In some cases (usually unrelated to Teams client configuration), media traffic will traverse the VPN tunnel even with proper routing. If this is the case, it is sufficient to block the ip Teams or the port using the VPN with firewall rules.
To route media traffic through the desired method in Teams VPN scenarios, make sure users are running Microsoft Teams client version 1.3.00.13565 or greater. This release includes improvements to the client-side detection of available network paths.
Signal traffic is performed over HTTPS, is not latency sensitive to media traffic, and is marked as “allowed” in the URL/IP data, so it can be safely routed through the VPN client if required.
Microsoft Edge 96 and above devices also support VPN split tunneling for peer-to-peer traffic. This means customers can benefit from VPN split tunneling for the Teams web client on the edge. Customers who want to set it up for websites running on Edge can do so by following the additional steps of enabling the Edge WebRtcRespectOsRoutingTableEnabled policy.
A common argument for avoiding split tunneling is that it is less secure, ie any traffic that does not go through the VPN tunnel will not benefit from any encryption scheme applied to the VPN tunnel and is therefore less secure.
The main objection to this is that media traffic is already encrypted via Secure Real-Time Transport Protocol (SRTP), a profile of Real-Time Transport Protocol (RTP) that provides confidentiality, authentication, and replay attacks for RTP traffic Protect. SRTP itself relies on randomly generated session keys, which are exchanged over a TLS secure signaling channel. This is covered in detail in this security guide , but the main part is media encryption.
Media traffic is encrypted using SRTP using session keys generated by a secure random number generator and exchanged using a signaling TLS channel. Additionally, bidirectional media between the Mediation Server and its internal next hop is also encrypted using SRTP.
Skype for Business Online generates a username/password that can be used to securely access media relays using Relay Traversal (TURN) around NAT. Media relays exchange username/passwords over a TLS secure SIP channel. It’s worth noting that even though a VPN tunnel can be used to connect clients to the corporate network, when traffic leaves the corporate network to reach the service, it still needs to flow in SRTP.
Also read about Modern Security Controls in Remote Work Scenarios: Alternatives for Security Professionals and IT to Implement Modern Security Controls in Today’s Unique Remote Work Scenarios (Microsoft Security Team Blog)
Once the strategy is in place, it should be confirmed that it is working properly. There are several ways to test that the path is correctly set to use your local Internet connection:
- Run the Microsoft 365 Connectivity Test, which will run connectivity tests against you, including traceroutes as described above. We’ve also added VPN testing to this tool, which should provide additional insights.
- A simple tracert pointing to an endpoint in the split tunnel scope should show the path used, for example:PowerShellcopy
tracert worldaz.tr.teams.microsoft.comYou should then see the path through your local ISP to this endpoint, which should resolve to an IP in the range configured for Teams split tunneling.
- Take network capture using a tool like Wireshark for example. Screen UDP during the call and you should see traffic going to IPs in the Teams optimized range. If a VPN tunnel is being used for this traffic, the media traffic is not visible in the trace.
If you need more data to troubleshoot, or are requesting assistance from Microsoft Support, get the information below to help you find a solution faster. The Microsoft-supported TSS Windows CMD-based generic TroubleShooting scripting toolset helps you collect relevant logs in an easy way. See https://aka.ms/TssTools for tools and instructions to use .
Microsoft 365 live event traffic (this includes live events generated by Teams and events generated through Teams, Stream, or Yammer using external encoders), and on-demand Stream traffic is currently classified as Default and Optimized in the service’s URL/IP list. These endpoints are classified as default endpoints because they are hosted on CDNs that other services may also use. Customers typically tend to proxy such traffic and apply whatever security elements are typically performed on such endpoints.
Many customers require input of the URL/IP data needed to connect users to Stream/Live events directly from their local Internet connection, rather than routing high-volume and latency-sensitive traffic through the VPN infrastructure. Typically, this is not possible .
Use the following steps to connect directly to the Stream/Live Events service for clients using a forced tunnel VPN. This solution is designed to provide customers with an option to avoid routing live event traffic through a VPN when network traffic is high due to work-from-home scenarios. If possible, it is recommended to access the service through an inspection proxy.
When using this solution, there may be service elements that do not resolve to the provided IP address and thus traverse the VPN, but should be heavily trafficked (eg streaming data). This offload may capture other elements outside the scope of the Live Event/Stream, but these should be restricted as they must satisfy FQDN and IP matching before direct transmission.
Customers are advised to weigh the risk of sending more traffic bypassing the VPN with the performance gain of real-time events.
To enforce tunnel exceptions for live events and Stream Teams, the following steps should be applied:
Clients need external recursive DNS resolution available so that the following hostnames can be resolved to IP addresses.
- * .media.azure.net
*.azureedge.net for Stream events ( Configuring an encoder for live streaming in Microsoft Stream – Microsoft Stream | Microsoft Docs ).
*.media.azure.net and *.bmc.cdn.office.net are used for Teams-generated real-time events (Quick Start Events, RTMP-In Supported Events [Roadmap ID 84960]) scheduled from the Teams client.
Some of these endpoints are shared with elements other than Stream/Live events, and it is recommended not to configure VPN offload using only these FQDNs, even if technically the VPN solution (eg, it operates in the FQDN rather than the IP).
FQDNs are not required in the VPN configuration, they are entirely used for the PAC file and IP to send the associated traffic directly.
For organizations that utilize a PAC file to route traffic through a proxy over a VPN, this is typically accomplished using an FQDN. However, for Stream/Live * events, the provided hostname contains wildcard characters (eg .azureedge.net) and other elements that do not provide a full IP list. Therefore, if the request is sent directly based only on DNS wildcard matching, traffic to these endpoints will be blocked because there is no direct route .
To fix this, we can provide the following IPs and use them in combination with the hostname from step 1 in the sample PAC file. The PAC file checks that the URL matches the URL used for the Stream/Live event, and if so, checks that the IP returned from the DNS lookup matches the IP provided for the service. If the two match, the traffic is routed directly. If the FQDN/IP (either element in) does not match, the traffic is sent to the proxy. Therefore, the configuration ensures that everything that resolves to IPs and IPs outside the defined namespace scope will traverse the proxy normally through the VPN.
Live events are streamed to customers using multiple CDN providers to provide optimal coverage, quality and resiliency. Currently, both Azure CDN Microsoft and Verizon are available for download. This may change over time due to regional availability etc. This article is your source for keeping you up to date with the latest information on IP ranges.
For Azure CDN from Microsoft, you can download the list from Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center – you will need to look specifically for the service tag AzureFrontdoor.Frontend in the JSON; addressPrefixes will show IPv4/ IPv6 subnet. IPs may change over time, but the list of service tags is always updated before being used.
For Azure CDN from Verizon (Edgecast) you can find an exhaustive list using https://docs.microsoft.com/rest/api/cdn/edge-nodes/list (click Try It ) – you will need to look specifically for the Premium_Verizon section. Note that this API displays source (and arbitrary). Currently, the API has no mechanism for distinguishing origin from anycast.
To implement this in a PAC file, the following example can be used to send Microsoft 365 Optimize traffic through the FQDN (recommended best practice), and critical flow/live event traffic directly through a combination of the FQDN and the returned IP address. The placeholder edited to the name of the specific tenant, where contoso is from contoso.onmicrosoft.com
Here is an example of how to generate a PAC file:
- Save the script below as Get-TLEPacFile.ps1 on your local hard drive .
- Go to the Verizon URL and download the resulting JSON (copy it to cdnedgenodes.json)
- Put the file in the same folder as the script.
- In a PowerShell window, run the following command. If the SPO URL is required, change the tenant name for something else. This is type 2, so type 1 (“ optimized” and “allowed”).PowerShellcopy
.\Get-TLEPacFile.ps1 -Instance Worldwide -Type 2 -TenantName <contoso> -CdnEdgeNodesFilePath .\cdnedgenodes.json -FilePath TLE.pac
- The TLE.pac file will contain IPv4/IPv6 (all namespaces and IPs).
Again, it is not recommended to perform VPN offload using only the FQDN; leveraging the FQDN and IP address in the function helps to scope the use of this offload to a limited set of endpoints, including Live Events/Streams. The function is constructed in such a way that a DNS lookup is performed for a direct match to the FQDN listed by the client (ie the DNS resolution of the remaining namespace remains unchanged).
If you wish to limit the risk of uninstalling endpoints not related to Live Events and Stream * , you can remove the .azureedge.net domain from the configuration, where most of this risk resides as this is shared for all Azure CDN customers area. The downside of this is that any events that use the external encoder will not be optimized, but the /Teams event is generated inside the external encoder.
The final step is to add a direct route to the VPN configuration for the live event IPs described in Collecting the current list of CDN endpoints to ensure that traffic is not sent to the VPN through a forced tunnel. See the Implementing VPN Split Tunneling section for details on how to do this for Microsoft 365 Optimize endpoints, which is exactly the same process as the Stream/Live event IPs listed in this document.
Note that only the IP (FQDN) collection of the current endpoint CDN should be used for VPN configuration.
No, this will send real-time events or Stream video direct latency sensitive streaming traffic, any other traffic that does not resolve to the published IP will continue to use the VPN tunnel.
No, the connection can only be IPv4 (if required).
Microsoft strictly controls the format and type of information in the service to ensure that customers can reliably use that information for secure and optimal routing based on endpoint classes.
The default endpoint class does not provide IP information for a number of reasons (the default endpoint might be outside of Microsoft’s control, might change too frequently, or might be in a block shared with other elements or). Therefore, the default endpoint is designed to be sent through the FQDN to inspection proxies, such as normal web traffic.
In this case, the above endpoints may be CDNs used by elements not controlled by Microsoft (non-real-time events or Streams), so sending traffic directly also means that anything else that resolves to these IPs will also be sent directly from the client. Given the unique nature of the current global crisis, to meet the short-term needs of our customers, Microsoft has provided the above information for customers to use as appropriate.
Microsoft is working on reconfiguring real-time event endpoints to allow them to be included in the Allowed/Optimized endpoint category in the future.
No, access to all required tagged endpoints in the URL/IP service is essential for the service to function. Also, any optional endpoints marked as Stream (with IDs 41-45).
- Live events generated within the Teams app
- View Stream hosted content
- Events generated by external devices (encoders)
It’s not the same, and the above advice fully applies to those who use the service. The demo from within Teams will see the presenter’s traffic flow to the UDP endpoint marked as optimized listed in the URL/IP service line 11, with the detailed VPN offloading recommendations listed in the Implementing VPN Split Tunneling section .
Yes, this cannot be avoided due to the shared FQN used to serve some elements. This traffic is usually sent through a corporate proxy, which can apply inspection. Using both FQDN and IP in a VPN split tunnel scenario minimizes this risk, but it still exists. Customers can remove the .azureedge.net domain from the uninstall configuration to minimize this risk, but doing so will remove the active events supported by Stream (External encoder events scheduled by Teams, Yammer events generated in Teams, external scheduled by Yammer Encoder events and on-demand viewing in Stream scheduled events or Stream). * Scheduling and Teams events in quests are not affected.
This section provides links to detailed guidance on implementing split tunneling for the most common partner Microsoft 365 traffic in this space. We will add these guides as they become available.
- Windows 10 VPN Client : Microsoft 365 On-Premises VPN Client Optimizes Windows 10 Traffic for Remote Workers
- Cisco Anyconnect : Optimizing Anyconnect Split Tunneling for Office365
- Palo Alto GlobalProtect : Optimize Microsoft 365 VPN Split Traffic Tunnel Excludes Access Routing
- F5 Networks BIG-IP APM : Optimize remote access traffic over VPN when Microsoft 365 BIG-IP APM
- Citrix Gateway : Optimizing Office365 Citrix Gateway VPN Split Tunneling
- Pulse Security : VPN Tunneling: How to Configure Split Tunneling to Exclude Microsoft 365 Apps
- Checkpoint VPN : How to Split Servers for Tunnel and Other SaaS Microsoft 365
Microsoft Security Team Releases Alternative Approaches for Security Professionals and IT to Implement Modern Security Controls in Today’s Unique Remote Work Scenario (blog post) Outlines Security Professionals and IT Implementing Modern Security in Today’s Unique Remote Work Scenario key method of control. Additionally, below are some frequently asked customer questions and answers on this topic.
The answer is a feature called tenant restrictions . Authentication traffic is not high and not particularly latency sensitive, so it can be sent through a VPN solution to a local proxy that applies the feature. An allowed list of trusted tenants is maintained here, and if the client tries to get a token from an untrusted tenant, the proxy will deny the request. If the tenant is trusted, the token is accessible if the user has the correct credentials and permissions.
So even if the user can establish a TCP/UDP connection to the above “optimized” marked endpoint, but without a valid token to access the tenant in question, they will not be able to log in and access/move any data.
No, it’s not the same as Microsoft 365 endpoints with consumer services (Onedrive.live.com and example) so split tunneling doesn’t allow users to access consumer services directly. Traffic to the consumer endpoint will continue to use the VPN tunnel and existing policies will continue to be in effect.
How can I apply DLP and protect my sensitive data if the traffic no longer flows through the on-premises solution?
To help prevent accidental disclosure of sensitive information, Microsoft 365 has a rich set of built-in tools . Use the built-in DLP capabilities of Teams and SharePoint to detect sensitive information that is not properly stored or shared. If part of your remote work policy involves bring your own device (BYOD) policies, you can use app-based conditional access to prevent sensitive data from being downloaded to users’ personal devices
In addition to the tenant throttling feature mentioned in Question 1, Conditional Access policies can be applied to dynamically assess the risk of authentication requests and react accordingly. Microsoft recommends implementing a zero trust model over time where we can maintain control in the mobile and cloud first world using Azure AD access policies. Conditional access policies can be used to make real-time decisions about the success of an authentication request, depending on a number of factors:
- Device, is the device known/trusted/domain joined?
- IP – Is the authentication request from a known company IP address? Or from a country you don’t trust?
- Application – Does the user have permission to use this application?
Based on these policies, we can then trigger policies such as approval, triggering MFA, or blocking authentication.
Likewise, Microsoft 365 provides protection for “optimized” marked endpoints in various layers of the service itself, as outlined in this document . As mentioned earlier, it is more efficient to provide these security elements in the service itself than trying to do so in a device that may fully understand the protocol/traffic. By default, SharePoint Online automatically scans file uploads for known malware
Endpoints marked optimized , as these will provide the most benefit for low-level work. However, if required, the service needs “Allow marked endpoints” to work and have IP addresses provided for endpoints that can be used if necessary.
In addition, there are various vendors offering cloud-based proxy/security solutions called Secure Web Gateways that provide central security, control, and corporate policy applications for regular web browsing. These solutions work well in a cloud-first world (if highly available, high-performance, and provisioned close to users) by allowing secure Internet access from cloud-based locations close to users. This will eliminate the need for hairpinning through the VPN/corporate network for regular browsing traffic, while still allowing for central security control.
However, even with these solutions in place, Microsoft strongly recommends that optimized traffic marked as Microsoft 365 be sent directly to the service.
For guidance on allowing direct access to an Azure virtual network, see Point-to-Site Remote Work Using an Azure VPN Gateway .
Port 80 is only used for things like redirecting a session to port 443, no customer data is sent or accessed over port 80. Encryption outlines encrypting data in transit and at rest Microsoft 365 traffic types outlines how to use SRTPto protect Teams traffic.
No , not applicable. One caveat to the above recommendation is that Chinese users connect to Microsoft 365 globally. Due to frequent cross-border network congestion in this area, direct Internet egress performance may vary. Most customers in this region use VPNs to bring traffic into the corporate network and utilize their licensed MPLS lines or similar egress out of the country via optimized paths. This article outlines this further for Chinese users Microsoft 365 .
Yes, there are caveats. Most Teams features are supported in the browsers listed in Get clients for Microsoft Teams .
Additionally, Microsoft Edge 96 and above devices support VPN split tunneling for peer-to-peer traffic by enabling the Edge WebRtcRespectOsRoutingTableEnabled policy. Currently, other browsers may not support VPN split tunneling for peer-to-peer traffic.