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

Published Jun 04 2020 12:53 PM 83.2K Views

***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 herewhich 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 and***


***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 * 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.


  • *
  • *
  • *
  • *

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).


  1. 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 *, 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




















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


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";


//Office 365 Optimize endpoints direct

if(shExpMatch(host, "")

|| shExpMatch(host, "")

|| shExpMatch(host, "")

|| shExpMatch(host, ""))



return direct;



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



if(shExpMatch(host, "*")
|| shExpMatch(host, "*")
|| shExpMatch(host, "*")
|| shExpMatch(host, "*"))




var resolved_ip = dnsResolve(host);


if (isInNet(resolved_ip, '', '') ||

isInNet(resolved_ip, '', '') ||

isInNet(resolved_ip, '', '') ||

isInNet(resolved_ip, '', '') ||

isInNet(resolved_ip, '', '') ||

isInNet(resolved_ip, '', '') ||

isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||

isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', '') ||
isInNet(resolved_ip, '', ''))



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 * 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.


  1. 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. 





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?



  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 * 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. 

Super Contributor

Hi @Paul Collinge,

Thank you for sharing this. But obviously some questions come to my mind :)


Is it too much to ask, if those three namespace could be clarified? In which case those are really used? So far I have not seen any other namespaces for Live Event attendees than * But when doing a nslookup like:


I could see aliases which are for other name spaces, but on clients I have not seen those in use. Is that something which you use as a preparation for the future purposes?


This same seems to go with Stream videos:

Standard Stream service.png


Also, I'm not sure if it is important to clarify that this is only (correct me if I'm wrong) for Live Event attendees traffic (TCP). No matter if they were looking for Live Event session via Teams client or via browsers. But the producers and speakers are still utilizing Teams own split tunnel solution and having UDP as preferably protocol. So there are no needs for .PAC file in that case. Only external name resolution and TCP/IP routing is enough (and FW rules) following your previous article.


Hi @Petri X 

                     There are a whole host of scenarios which will change the endpoint used for the consumption of the service, be it a Live Event in Teams, consuming Stream etc. The Live Events/Stream engineering group have provided the FQDN/IP information to cover as many of those scenarios as comprehensively as possible. As it's intended as a short term solution until the namespaces can be updated to simplify this solution, it isn't something we can break down further as it's a complex array of scenarios. 

You can of course just add as an FQDN if you wish but you may possibly find things for the service dont always go direct. 


As for the producers of the event, you're correct. If they are using Teams then the traffic will go to the Optimize marked Office 365 endpoints via UDP and there is no FQDN for these endpoints (Row 11 in the URL/IP service).  I'll add an FAQ to this effect. 

Super Contributor

Thanks for the writeup!  I also have a few questions.  Is there something on the roadmap for a long term solution?  Does this cover Yammer live events as well?  

Occasional Contributor

Would you not want to split * regardless of destination IP as if you do not do so then video on demand playback from Stream would not split.  For example, playing back a video from Stream I can see it reaches out to which does not resolve to an IP in your list.  Similarly, if a user downloads a video that uses, for example,  it again does not match your whitelist.


Perhaps this article needs to be clear that we are talking about Stream/Teams live events only, and not Stream on demand?


The O365 IP/URL list also includes: and = - Not in the IP list above = - In the list above


Is that correct?

Regular Visitor

When we implement this change for Live Events we see that PowerBI is using " -" which according to your rules above will send the traffic direct. From our security point of view we would not want PowerBI going direct. Is the routing direct as expected, or can we limit this to ONLY Live Events traffic?

Super Contributor


This might go a bit complicated, but on .PAC file you could exclude that host. I was wishing to hear so much from Paul that "*" was the only namespace required. But unfortunately these two extra appeared which might cause extra multiplier for challenging level. You could try with that domain only to see if that solves it. But as that is against their recommendation we are quite alone :D


Regular Visitor

I've also seen traffic hit which isn't mentioned

Super Contributor


That is also interesting. We have also seen the following IPs: & before this announcement. But not after that. Did you manage to find out the host name for that?


@Bailey44  could you share via PM the hostname used when you hit and whether this was just the webpage loading or the actual streaming content?

@Petri X we scoped in the CDNs to the address for some elements which is why you see these IPs less now. There are some elements which still use them but it's possible a CDN has been missed, if so i'll get it fixed. 


Thanks both for the feedback, very helpful.


@DaveOBrien unfortunately because of the need for * there are various other elements which may get caught by the ruleset, you've found one in PowerApps there. The use of the IPs in the PAC file should scope this down to only a few rare scenarios but it seems you've tripped over one.


I tried to indicate this in the article but i've made it a bit clearer now.  I appreciate it's not a perfect solution and we're working to provide a more specific namespace to work with here which should solve this problem completely, but we wanted to provide something to work with and let customers make the decision on using it as this is a pressing problem for many.


Thanks for the feedback though, again, very useful. 


FYI - another conflict to consider when working with split tunnels, especially based on URLs is Anti Virus. For example, Sophos (when web control enabled) does some kind of local proxy for all HTTPS traffic. And this bleaks VPN client attempts to exclude this traffic from the tunnel.


Details - Sophos KB 135185 - Palo Alto GlobalConnect VPN in Domain Split Tunnel Mode incompatible with Sophos ...

Regular Visitor


i know the traditional reason you might want traffic from a service to go via VPN/proxy, for inspection purposes, but for a service such as Office 365, with its deep auditing tools in Compliance & Security Centre , why worry about sending the traffic direct?


it already has data-in-transit protection via TLS1.2+. I assume you are using Azure AD to authenticate users? Possibly with 2FA enabled.  What am I missing from a data security perspective?


the only traffic my org really needs to send via vpn to a proxy is user authentication traffic to ensure users can only visit Office 365 tenants our org has authorised for access.  All our iOS/android O365 traffic goes direct, using InTune to control data.  Am really interested to understand your view on this.

Super Contributor

Hey @Paul Collinge 

So, we have the first add-ons for the Live Event endpoints to be added. Interesting to see how this goes, and how much we need to learn internally to get this done correctly :cool:

Hope everybody who has done this customization has noticed the coming change.



@Petri X  Appreciate this temporary solution isn't an ideal scenario but rest assured the Live Events team are working hard behind the scenes to implement the changes required to much simplify the connectivity story for the service, these are pretty significant and will take time to complete. I'm hopeful the next update will be to that end, the changes just made are part of that process though.


The team are also acutely aware of the need for visibility of these changes until we are able to move the endpoint information directly under the Office 365 endpoint service categories where they can publish IPs and changes seamlessly. To that end they have worked to reach out directly to Microsoft Premier customer's account teams, our FastTrack organization, and also a Message Center note is planned shortly to notify customers of this change. 



Super Contributor

@Paul Collinge 

One clarification, do you really expanding the previous domain from * to * When looking for the following page: Streaming Endpoints (Origin) in Azure Media Services, that seems to speak still *


@Petri X  yes * is required, which encompasses * The page you reference doesn't contain a comprehensive set of endpoints required for the service. The list above is what's been provided to me by the TLE product team so I'm confident it's correct and complete. 

Super Contributor

Ok, thank you @Paul Collinge again for your answer. Just wanted to clarify this as previously * was enough. And now that is not anymore the case.


Will these extensions also start opening more services than what is required for Live Event participants only? I'm just like to be sure when presenting these to the security teams, that they are not able to came back say: "Hey, Petri, you asked Live Event, but as you can see lot of other services are now open as well". And I do not meant it is bad, but I'm wishing to be able to share correct expectations for others as well.


Hi Paul,


Can you advise if / how your list correlates to the Azure CDN Edge node list in regards Live Events?


I was advised to use the node list but it keeps growing and more importantly is different to yours.





Senior Member



We're also seeing traffic from:, which resolves to []




Super Contributor

Are we any closer to having these ranges published in the official Microsoft 365 URLs list and REST API?

Super Contributor

Hi @Paul Collinge ,

Is this thread still alive? :D


We have start to seen dark clouds on the sky. There are more and more (hundreds) out of the URL entries which are landing to the same area with meetings:

etc.. etc..


Many of these are linked to advertises, and that makes me worried if this is a really good idea anymore. Amount of dangerous advertisements has been big in past. Would be nice if this still could be segmented that meeting streams are segmented differently than other traffic.


Version history
Last update:
‎Dec 03 2021 04:44 PM
Updated by: