During this current COVID-19 crisis, many organizations have had to rapidly implement a work-from-home model for the majority of their users. For many, this means an enormous increase in load to the VPN infrastructure as all traffic is traditionally sent via this path that was invariably not designed for the volume or type of traffic now reliant on it.

 

To improve performance, and also reduce load on the VPN infrastructure, many customers have achieved significant results by following the Microsoft guidance to implement split tunneling (or forced tunnel exceptions to use the correct technical term) on the Optimize-marked Office 365 endpoints. This traffic is high-volume and latency-sensitive traffic, and thus sending it directly to the service solves the problems outlined above and is also the designed best practice for these endpoints.

 

Microsoft 365 Live Events (Teams-produced live events and those produced with an external encoder via Teams, Stream, and Yammer) and on-demand Stream traffic are not currently listed within the Optimize category with the endpoints listed in the ‘Default’ category in the Office 365 URL/IP service. The endpoints are located in this category as they are hosted on CDNs that may also be used by other services, and as such customers generally prefer to proxy this type of traffic and apply any security elements normally done on diverse endpoints such as these.

 

In most organizations the traffic is internally routed via a network path that is designed to cope with the load and provide latency at a level that doesn’t impact service quality. With the switch to large scale remote working, many customers have asked for the information required to connect their users to Stream/Live Events directly from their local internet connection, rather than route the high-volume and latency-sensitive traffic via an overloaded VPN infrastructure. Typically, this is not possible without both dedicated namespaces and accurate IP information for the endpoints, which is not provided for the Default marked Office 365 endpoints.

 

Microsoft is working to provide more-defined and service-specific URL/IP data to help simplify connectivity to the service for the VPN connection model but as you can imagine for a global SaaS service like Office 365, this is not something which can be achieved overnight. Therefore, in the interim we’ve been working on interim methods to meet customer demand for this information. As a result of some changes we were able to perform relatively quickly, we are able to provide the following steps to allow for direct connectivity for the service from a client using a forced tunnel VPN.

This is slightly more complex than normal to implement (requiring an extra function in the PAC file) but should provide a comprehensive solution to this challenge until such time as we can rearchitect the endpoints so as to simplify connectivity requirements. 

 

To implement the Forced tunnel exception for Teams Live Events and Stream, the following steps should be applied:

 

1. External DNS resolution.

 

The client needs external, recursive DNS resolution to be available for the following FQDNs so they can resolve host names to IPs.

 

• *.streaming.mediaservices.windows.net
• *.azureedge.net
• *.media.azure.net

It is important to note, it is not advised to just use these URLs to configure VPN offload even if technically possible in your VPN solution (eg if it works at the FQDN rather than IP). This is due to the fact some of these endpoints are shared with other elements outside of Stream/Live Events and as such the IPs provided below are not comprehensive for that FQDN, but are for Teams Live Events/Stream. 

 

2. PAC file changes (Where required)

 

In most organizations, a PAC file will be used in a VPN scenario to configure the client to send traffic either direct, or via the internal proxy server. Normally this is achieved using FQDNs. However, with Stream/Live Events, the namespace provided currently includes wildcards such as *.azureedge.net, which also encompasses other elements for which it is not possible to provide full IP listings. Thus, if the wildcard is sent direct, traffic to these endpoints will be blocked as there is no route via the direct path for it in step 3.

 

To solve this, we’re able to provide the following IPs and use them in combination with the FQDNs in section 1 for Stream/Live Events in an example PAC file. The PAC file checks if the URL matches those used for Stream/Live Events and then if it does, it then also checks to see if the IP returned from a DNS lookup matches those provided for the service. If both match, then the traffic is routed direct. If either element (FQDN/IP) doesn’t match then the traffic is sent to the proxy. This way we ensure anything which resolves to an IP outside of the scope of Stream/Live Events will traverse the proxy via the VPN as normal.

 

Table 1: IP addresses for Live Events & Stream

 

IPv4	IPv6
72.21.81.200	2606:2800:011F:17A5:191A:18D5:0537:22F9
152.199.19.161	2606:2800:133:206E:1315:22A5:2006:24FD
117.18.232.200	2606:2800:0147:120F:030C:1BA0:0FC6:265A
192.16.48.200	2606:2800:0157:1508:1539:0174:1A75:1191
93.184.215.201	2606:2800:11F:7DE:D31:7DB:168F:1225
68.232.34.200	2606:2800:133:F17:19E8:2356:251B:02A9
192.229.232.200	2606:2800:0147:0FF8:129B:22EB:020B:1347

 

To implement this in a PAC file you can use the following example which sends the Office 365 Optimize traffic direct (which is recommended best practice) via FQDN, and the critical Stream/Live Events traffic direct via a combination of the FQDN and also the returned IP address. Contoso would need to be edited to your specific tenant name where contoso is from contoso.onmicrosoft.com

 

Example PAC file

 

function FindProxyForURL(url, host)

 

{

    var direct = “DIRECT”;

     var proxyServer = “PROXY 10.1.2.3:8081”;

   

   //Office 365 Optimize endpoints direct

   if(shExpMatch(host, “outlook.office.com”)

   || shExpMatch(host, “outlook.office365.com”)

   || shExpMatch(host, “contoso.sharepoint.com”)

   || shExpMatch(host, “contoso-my.sharepoint.com”))

 

{

   return direct;

}

 

 /* Don’t proxy Stream/Live Events traffic*/

   

 

 if(shExpMatch(host, “*.streaming.mediaservices.windows.net”)

 || shExpMatch(host, “*.azureedge.net”)

 || shExpMatch(host, “*.media.azure.net”))

 

 

{

 var resolved_ip = dnsResolve(host);

 

if (isInNet(resolved_ip, ‘72.21.81.200’, ‘255.255.255.255’) ||

isInNet(resolved_ip, ‘152.199.19.161’, ‘255.255.255.255’) ||

isInNet(resolved_ip, ‘117.18.232.200’, ‘255.255.255.255’) ||

isInNet(resolved_ip, ‘192.16.48.200’, ‘255.255.255.255’) ||

isInNet(resolved_ip, ‘93.184.215.201’, ‘255.255.255.255’) ||

isInNet(resolved_ip, ‘68.232.34.200’, ‘255.255.255.255’) ||

isInNet(resolved_ip, ‘192.229.232.200’, ‘255.255.255.255’))

 

 

{

 return direct;

}

}

 

 

// Default Traffic Forwarding.

return proxyServer;

        

}

 

 

It’s worth stressing again, it is not advised to attempt to perform the VPN offload using just the FQDNs, utilizing both the FQDNs and the IPs in the function helps scope the use of this offload to just Stream/Live Events. The way the function is structured means that only if the FQDN matches those listed, do we perform a DNS lookup for it i.e DNS does not have to be performed for all namespaces used by the client.

 

3. Configure routing on the VPN to enable direct egress

 

The final element is to add a direct route for the Live Event IPs in Table 1 into the VPN configuration to ensure the traffic is not sent via the forced tunnel into the VPN. Detailed information on how to do this for the Office 365 Optimize endpoints can be found in this article, and the process is exactly the same for the Stream/Live Events IPs listed in this document.

 

 

FAQ:

 

Question:  Will this send all my traffic for the service direct?

Answer:    No, this will send the latency-sensitive streaming traffic for a Live Event or Stream video direct, any other traffic will continue to use the VPN tunnel if they do not resolve to the IPs published.

 

Question:  Do I need to use the IPv6 Addresses?

Answer:     No, the connectivity can be IPv4 only if required.

 

Question:  Why are these IPs not published in the Office 365 URL/IP service?

Answer:    Microsoft has strict controls around the format and type of information that is in the service to ensure customers can reliably use the information to implement secure and optimal routing based on endpoint category.

 

The default endpoint category has no IP information provided for numerous reasons, such as it being outside of the control of Microsoft, is too large, or changes too frequently, or is in blocks shared with other elements. For this reason Default marked endpoints are designed to be sent via FQDN to an inspecting proxy, like normal web traffic.

 

In this case, the above endpoints are CDNs that may be used by other elements other than Live Events or Stream, and thus sending the traffic direct will also mean anything else which resolves to these IPs will also be sent direct from the client. Due to the unique nature of the current global crisis and to meet the short-term needs of our customers, Microsoft has provided the information above for customers to use as they see fit.

 

Microsoft is working to reconfigure the Live Events endpoints to allow them to be included in the Allow/Optimize endpoint categories at a later date.

 

 

Question:   Do I only need to allow access to these IPs? 

Answer:     No, access to all of the ‘Required’ marked endpoints in the URL/IP service is essential for the service to operate. In addition, any Optional endpoint marked for Stream (ID 41-45) are required. 

 

Question:   What scenarios will this advice cover?

Answer: 

 

1. Live events produced within the Teams App

2. Viewing Stream hosted content

3. External device (encoder) produced events