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 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 rearchitect the endpoints so as to simplify connectivity requirements.
Please note, there may be service elements which 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 service elements outside the scope of Live Events/Stream such as PowerApps which get caught by this offload but these should be rare as they have to meet both the FQDN and the IP match before going direct.
As noted, 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.
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. (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 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. Note only the IPs (not FQDNs) published above should be used for VPN configuration.
By: Team microsoft.com
Comments
Post a Comment