How to Optimize Stream & Live Events traffic in a VPN scenario

[Paul Collinge]

***Updated August 4, 2021: This article was initially intended to provide customers with an option to optimize connectivity to the services during the early days of the Covid-19 pandemic. As time went on from the original publication date, parts of the article are no longer accurate. Additionally, it’s currently not possible to maintain that accuracy and as such, you may find missing IP ranges. This is the final update on this blog.***

The current official guidance for Stream connectivity can be found in this Microsoft Docs article here, which links to another Docs article for the Microsoft 365 URL/IP service where you’ll find the Stream FQDNs in the "Default" category. Additional troubleshooting guidance can be found in this Microsoft Support article here. If you still need further assistance outside of the support articles currently available online, please contact Microsoft support.

***Updated February 25, 2021: With two new IP ranges which have had to be added to provide additional capacity and resilience as we work to improve the endpoint requirements for the service. Added are 13.107.213.0/24 and 13.107.224.0/24***

***Updated September 22, 2020: With a new FQDN and additional IP ranges as part of steps to simplify connectivity for the service. This information is provided as-is, in response to customer demand for options to optimize Live Events & Stream traffic via VPN during the Covid crisis***

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 solution to this challenge until such time as we can re-architect the endpoints so as to simplify connectivity requirements. 

Please note, there may be service elements that don't resolve to the IP addresses provided and thus traverse the VPN, but the bulk of high volume traffic (eg streaming data) should do. There also may be other elements outside the scope of Live Events/Stream which get caught by this offload but these should be relatively limited as they have to meet both the FQDN and the IP match before going direct, but this scenario does exist with this temporary solution so customers are advised to assess the need to implement this solution with that in mind and the risk of allowing direct access to shared domains such as *.azureedge.net. This solution is intended to provide customers with a temporary option to avoid Live Events traffic being routed via VPN whilst high home worker scenarios are in place, if possible though it is advised to access the service through an inspecting proxy. Customers are advised to weigh up the risk of a limited number of unintended endpoints being routed direct, over the need to ensure Live Events traffic is not sent via a VPN.

To reiterate, this is intended to be a temporary solution to provide customers some level of relief to use at their discretion whilst we work through engineering changes to simplify and scope this traffic optimization. 

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
• *.bmc.cdn.office.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. (Note FQDNs are not required in the VPN configuration, they are purely for use in PAC files in combination with the IPs to send the relevant traffic direct).

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 both the IP and FQDN 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
152.195.19.97	2606:2800:11f:1cb7:261b:1f9c:2074:3c
152.199.52.147	2606:2800:157:3ac:1a2e:26c9:99c:8f9
152.199.21.175	2606:2800:233:1cb7:261b:1f9c:2074:3c
152.199.39.108	2606:2800:247:1cb7:261b:1f9c:2074:3c
13.107.208.0/24	2620:1ec:29::/48
13.107.219.0/24	2620:1ec:40::/47
13.107.246.0/24	2620:1ec:bdf::/48
13.107.253.0/24
13.107.213.0/24
13.107.224.0/24

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

Note in this example the IPv6 addresses are not used. If your client and network is IPv6 enabled then you should add the IPv6 addresses from the table above into the section with the IPv4 addresses.

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, "*.bmc.cdn.office.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') ||
isInNet(resolved_ip, '152.195.19.97', '255.255.255.255') ||
isInNet(resolved_ip, '152.199.52.147', '255.255.255.255') ||
isInNet(resolved_ip, '152.199.21.175', '255.255.255.255') ||
isInNet(resolved_ip, '152.199.39.108', '255.255.255.255') ||

isInNet(resolved_ip, '13.107.213.0', '255.255.255.0') ||
isInNet(resolved_ip, '13.107.224.0', '255.255.255.0') ||
isInNet(resolved_ip, '13.107.208.0', '255.255.255.0') ||
isInNet(resolved_ip, '13.107.219.0', '255.255.255.0') ||
isInNet(resolved_ip, '13.107.246.0', '255.255.255.0') ||
isInNet(resolved_ip, '13.107.253.0', '255.255.255.0'))

{

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 a limited scope including Live Events/Stream. 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. 

If you wish to limit the risk of offloading endpoints not related to Live Events and Stream, you can remove the *.azureedge.net domain from the configuration which is where the majority of this risk lies as this is a shared domain within Azure for customers. The downside of this is that any event using an external encoder and those scheduled through Yammer will not be optimized but events produced/organized within Teams will be. So if events via Teams is all you are using, this configuration may work well.

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. Note, only the IPs (not FQDNs) published above should be used for VPN configuration. 

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 non Microsoft controlled elements 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

Question:   Does this advice cover presenter traffic?

Answer:  It does not, the advice above is purely for those consuming the service. Presenting from within Teams will see the presenter's traffic flowing to the Optimize marked UDP endpoints listed in URL/IP service row 11 with detailed VPN offload advice outlined here

Question:   Does this configuration risk traffic other than Live Events & Stream being sent direct?

Answer: Yes, unfortunately due to shared FQDNs used for some elements of the service, this is unavoidable. This traffic is normally sent via a corporate proxy which can apply inspection. In a VPN split tunnel scenario, using both the FQDNs and IPs will scope this risk down to a minimum but it will still exist. Customers can remove the *.azureedge.net domain from the offload configuration and reduce this risk to a bare minimum but this will remove the offload of Teams live events produced using an Encoder and those scheduled in Yammer. Events produced in Teams are unaffected.