How to quickly optimize Office 365 traffic for remote staff & reduce the load on your infrastructure

[Paul Collinge]

Update 02 April 2020.

A genuine thank you all for your feedback around this article. Given the enormous popularity of this subject in the current crisis, we've worked hard over the past few weeks to improve and expand the guidance in this article and as a result, we've moved the Office 365 VPN connectivity guidance to a new home which is linked below. As with this article, we've aimed to provide simple and priority driven guidance to help customers deliver solutions to this problem quickly and securely in this current climate. 

Further we've reached out to key VPN partners who have rapidly responded to provide step by step guides on how to configure Office 365 split tunneling/Forced Tunneling with exceptions, within their particular implementation. Cisco (AnyConnect), Palo Alto (GlobalProtect) and F5 Networks (BIG-IP APM) are the first to publish, with more to come over the coming days. Special thanks to those partners for their commitment and rapid delivery of this guidance for our mutual customers.

New Links:

• Overview: VPN Split Tunneling for Office 365 
• Implementing VPN Split Tunneling for Office 365
• Securing Remote Users (From the Microsoft Security Team)

Please continue to provide feedback via the comments section on the articles above and we'll endeavour to respond as quickly as possible and continue to improve the guidance as needed. 

Paul & The Office 365 Network Connectivity & Performance team 

**********************************************************************************************************

Original Article below:

Over the past few weeks, Microsoft, and more specifically the Office 365 Network team have seen a large influx of questions from customers around how best to optimize their Office 365 connectivity as they work diligently to plan for a large amount of their userbase suddenly working from home. We’ve also seen similar queries from customers looking for best practice whilst rapidly enabling their Office 365 benefits, Free Teams plans or free 6 month E1 trial recently announced to rapidly roll out Teams to allow their business to continue to function and allow users to collaborate effectively without being in the Office.  

The recent COVID-19/Coronavirus outbreak has caused many customers to rapidly enable, or proactively plan for the bulk of their employees working from home. This sudden switch of connectivity model for the majority of users typically has a significant impact on the corporate network infrastructure which may have been scaled and designed before any major cloud service was rolled out and in some cases, not designed for a situation when it is required simultaneously by all users.

Network elements such as VPN concentrators, central network egress equipment such as proxies, DLP etc, central internet bandwidth, backhaul MPLS circuits, NAT capability and so on are suddenly put under enormous strain due to the load of the entire business using them, with the end result being poor performance and productivity coupled with a poor user experience for those users forced to adapt to working from home.

A simple diagram of a traditional network model can be seen below, where remote user's connectivity is forced in and back out of the corporate network to reach critical resources as well as branch offices using MPLS circuits to reach the services offered at head office. It is an incredibly common network model for businesses around the world, but it was designed to be effective for a pre-cloud world.

A traditional enterprise network, which does not work well in a cloud first world

This model made perfect sense and worked very well when the bulk of applications, data and services resided within the corporate network (the dotted line in the diagram), but as enterprises shift to the cloud, it rapidly becomes a cumbersome environment which doesn’t scale well or provide the organization with any agility to react to situations such as that we face today. Many customers report to Microsoft that they have seen a very rapid shift of network traffic which used to be contained within the corpnet now almost exclusively connecting to some external cloud-based source.

Fortunately, Microsoft has been working closely with customers and the wider industry for many years to provide effective, modern solutions to these problems from within our own services, and also aligned to industry best practice. Solutions that apply very simply and effectively to remote workers as much as they do to branch offices. Microsoft has designed the connectivity requirements for the Office 365 service to work efficiently for remote users whilst still allowing an organization to maintain security and control over their connectivity.

Below we will outline the simple steps an organization can take to drastically reduce the impact Office 365 traffic has on the traditional corporate infrastructure when we have a large percentage of users working remotely all at once. The solution will also have a significant impact on user performance and also provide the benefit of freeing up the corporate resources for elements which still have to rely on it.

Most remote users who are not using a virtualized desktop will use a VPN solution of some sort to route all connectivity back into the corporate environment where it is then routed out to Office 365, often through an on premises security stack which is generally designed for web browsing.

The key to this solution is separating out the critical Office 365 traffic which is both latency sensitive and that which also puts enormous load on the traditional network architecture. We then treat this traffic differently and use the user’s local internet connection to route the connectivity directly to the service. To do this we need to follow a simple set of actions:

1. Identify the endpoints we need to Optimize

Microsoft has already identified these endpoints and marks them very clearly for reference. In the URL/IP list for the service these endpoints are marked as “Optimize”. There are just four URLS which need to be optimized and nineteen IP subnets. In just this small group of endpoints we can account for around 80% of the volume of traffic to the service and it also includes the latency sensitive endpoints such as those for Teams media. Essentially this is the traffic that we need to take special care of and is also the traffic which will put incredible pressure on traditional network paths.

URLs in this category have the following characteristics:

• Are Microsoft owned and managed endpoints hosted on Microsoft infrastructure.
• Have IPs provided
• Low rate of change to URLs/IPs compare to other two categories
• Expected to remain low in number of URLs
• Are High volume and/or latency sensitive

You can also query the REST API Web Service for this information, and a PowerShell example script which does this and outputs the URLs/IPs/Ports for all three endpoint categories can be found using the link above.  

Endpoint to Optimize	Port/s	Use
https://outlook.office365.com	TCP 443	This is one of the Core URLs Outlook uses to connect to its Exchange Online server and has high volume of bandwidth usage and connection count. Low network latency is required for online features including: Instant search, Other mailbox calendars, Free / busy lookup, manage rules & alerts, Exchange online archive, Emails departing the outbox.
https://outlook.office.com	TCP 443	This is use for Outlook Online web access to connect to its Exchange Online server and network latency. Connectivity is particularly required for large file upload and download with SharePoint Online.
https://<tenant>.sharepoint.com	TCP 443	This is the primary URL for SharePoint Online and has high volume of bandwidth usage.
https://<tenant>-my.sharepoint.com	TCP 443	This is the primary URL for OneDrive for Business and has high volume of bandwidth and possibly high connection count from the OneDrive for Business Sync tool.
Teams Media IPs (no URL)	UDP 3478, 3479, 3480, and 3481	Relay Discovery allocation and real time traffic (3478), Audio (3479), Video (3480), and Video Screen Sharing (3481). These are the endpoints used for Skype for Business and Microsoft Teams Media traffic (Calls, meetings etc). Most endpoints are provided when the Microsoft Teams client establishes a call (and are contained within the required IPs listed for the service). UDP is required for optimal media quality.

<tenant> should be replaced with your Office 365 tenant name. For example contoso.onmicrosoft.com would use contoso.sharepoint.com and constoso-my.sharepoint.com

At the time of writing the IP ranges which these endpoints correspond to are as follows. It is strongly advised you use the script referenced previously or the URL/IP page to check for any updates when applying the policy, and do so on a regular basis.

104.146.128.0/17

13.107.128.0/22

13.107.136.0/22

13.107.18.10/31

13.107.6.152/31

13.107.64.0/18

131.253.33.215/32

132.245.0.0/16

150.171.32.0/22

150.171.40.0/22

191.234.140.0/22

204.79.197.215/32

23.103.160.0/20

40.104.0.0/15

40.108.128.0/17

40.96.0.0/13

52.104.0.0/14

52.112.0.0/14

52.96.0.0/14

52.120.0.0/14

• TCP ports 80/443
• UDP ports 3478, 3479, 3480, 3481

IPV6 endpoints can be ignored if not currently required, i.e. the service will currently operate successfully on IPV4 only (but not the other way round). This will likely change in future but IPV4 only is possible for the time being.

2. Optimize access to these endpoints via the VPN

Now that we have identified these critical endpoints, we need to divert them away from the VPN tunnel and allow them to use the user’s internet connection to connect directly to the service. The vast majority of VPN solutions allow split tunnelling, where identified traffic is not sent down the VPN tunnel to the corporate network but rather sent direct out the user’s local internet connection. The VPN client should be configured so that traffic to the above, Optimize marked URLs/IPs/Ports are routed in this way. This allows the traffic to utilize local Microsoft resources such as Office 365 Service Front Doors such as AFD as one example, which deliver Office 365 services & connectivity points as close to your users as possible. This allows us to deliver extremely high performance levels to users wherever they are in the world. There is also Microsoft’s world class global network which is very likely within  a small number of milliseconds of your users direct egress, and is designed to take your traffic securely to Microsoft resources wherever they may be in the world, as efficiently as possible.

The solution would look something like that below.

A client's VPN connection with split tunneling enabled

Sounds simple? It is in most cases, but for an enterprise, this shift in connectivity invariably raises questions about security. In the traditional network approach security is often applied inline to network traffic as it egresses to the internet. Proxies and firewalls perform inspection on the traffic to check for data exfiltration, viruses and so on. By bypassing this we are removing this layer of protection we have come to rely on when connecting to the internet. The good news is, for the highlighted endpoints above, Microsoft has numerous features in place which means your security with the modern approach may well be higher than available previously. We will run through some of the common solutions below, not all will be relevant or necessary to all customers, but we will cover the majority of common concerns that come up when implementing modern network connectivity.

3. Common questions when implementing local breakout and split tunnelling for Office 365

It should be noted that the two steps above are all that is necessary to solve the performance/scalability issues if you need to move very quickly given the current situation. The elements below can be added as needed and as time allows or you may have them in place already.

Q1. How do I stop users accessing other tenants I do not trust where they could exfiltrate data?

A: The answer is a feature called tenant restrictions. Authentication traffic is not high volume nor especially latency sensitive so can be sent through the VPN solution to the on-premises proxy where the feature is applied. An allow list of trusted tenants is maintained here and if the client attempts to obtain a token to a tenant which is not trusted, the proxy simply denies the request. If the tenant is trusted, then a token is accessible if the user has the right credentials and rights.

So even though a user can make a TCP/UDP connection to the Optimize marked endpoints above, without a valid token to access the tenant in question, they simply cannot login and access/move any data.

Q2. Does this model allow access to consumer services such as personal OneDrive accounts?

A: No, it does not, the Office 365 endpoints are not the same as the consumer services (Onedrive.live.com as an example) so the split tunnel will not allow a user to directly access consumer services. Traffic to consumer endpoints will continue to use the VPN tunnel and existing policies will continue to apply.

Q3. How do I apply DLP and protect my sensitive data when the traffic no longer flows through my on-premises solution?

A: If required, endpoints can be protected with Office DLP if required and it’s much more efficient to provide this feature in the service itself rather than try and do it in line at the network edge. Azure Information protection can also be used to provide a high level of information protection if required.

Q4. How do I evaluate and maintain control of the user’s authentication when they are connecting directly?

A: In addition to the tenant restrictions feature noted in Q1, conditional access policies can be applied to dynamically assess the risk of an authentication request and react appropriately. Microsoft recommends the Zero Trust model is implemented over time and we can use Azure AD conditional access policies to maintain control in a mobile & cloud first world. Conditional access policies can be used to make a real-time decision on whether an authentication request is successful based on numerous factors such as:

• Device, is the device known/trusted/Domain joined?
• IP – is the authentication request coming from a known corporate IP address? Or from a country we do not trust?
• Application – Is the user authorized to use this application?

We can then trigger policy such as approve, trigger MFA or block authentication based on these policies.

Q5. How do I protect against viruses and malware?

A: Again, Office 365 provides protection for the Optimize marked endpoints in various layers in the service itself, outlined in this document. As noted, it is vastly more efficient to provide these security elements in the service itself rather than try and do it in line with devices which may not fully understand the protocols/traffic.

For the Exchange endpoints listed above, Exchange Online Protection and Office 365 Advanced Threat Protection do an excellent job of providing security of the traffic to the service.

Q6. Can I send more than just the Optimize traffic direct?

A. Priority should be given to the Optimize marked endpoints as these will give maximum benefit for a low level of work. However, if you wish, the Allow marked endpoints are required for the service to work and have IPs provided for the endpoints which can be used if required.

There are also various vendors who offer cloud based proxy/security solutions called secure web gateways which provide central security, control and corporate policy application for general web browsing. These solutions can work well in a cloud first world, if highly available, performant, and provisioned close to your users by allowing secure internet access to be delivered from a cloud based location close to the user. This removes the need for a hairpin through the VPN/corporate network for general browsing traffic, whilst still allowing central security control.

Even with these solutions in place however, Microsoft still strongly recommends the Optimize marked Office 365 traffic is sent direct to the service.

Q7. Why is port 80 required? Is traffic sent in the clear?

A. Port 80 is only used for things like redirect to a port 443 session, no customer data is sent or is accessible over port 80. This article outlines encryption for data in transit, and at rest for Office 365 and this article outlines how we use SRTP to protect Teams media traffic.

Q8. Does this advice apply to users in China using a worldwide instance of Office 365?

A. No it does not. The one caveat to the above advice is users in the PRC who are connecting to a worldwide instance of Office 365. Due to the common occurrence of cross border network congestion in the region, direct internet egress performance can be variable. Most customers in the region operate using a VPN to bring the traffic into the corporate network and utilize their authorized MPLS circuit or similar to egress outside the country via an optimized path. This is outlined further in this article https://docs.microsoft.com/en-us/office365/enterprise/office-365-networking-china

Finally, please ask any questions you may have in the comments section below and we will do our best to answer as quickly as possible.

4. Further reading

General best practice for Office 365 connectivity:

http://aka.ms/pnc

https://docs.microsoft.com/en-us/archive/blogs/onthewire/__guidance

Recorded Ignite sessions

https://myignite.techcommunity.microsoft.com/sessions/81561?source=sessions

https://myignite.techcommunity.microsoft.com/videos/64276

https://myignite.techcommunity.microsoft.com/videos/64275

Office 365 Partner Program

https://resources.techcommunity.microsoft.com/networking/

Current partners are Citrix, Netfoundry, NTT, SilverPeak and Zscaler

Network Connectivity performance testing

https://connectivity.office.com/

This tool runs some tests against Office 365 endpoints including the Optimize marked ones and give you some clear feedback around how connectivity looks for those endpoints and anything you can do to improve the connectivity.

Bandwidth planning

https://aka.ms/bandwidth/

This tool is one mechanism you can use to monitor user's Office 365 network traffic volumes to get a clear figure for bandwidth requirements for the wider business.

[Gladys Rodriguez]

Maybe App Proxy can help.  That way Conditional Access/Zero Trust can be used and better security can be implemented.
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy

[Dennis Gaida]

Good article. You should link to the official documentation of the IP ranges: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges instead of just posting them since they might change and the docs should always be up to date.

[Paul Collinge]

@Dennis Gaida Indeed, good advice but the article does already make a clear warning to check for updates, links to the URL/IP page, REST API and a script to query the web service for updates.

[Hitesh_Jansari]

Great article, MFA could be leverage with this solution as well.

[Zied Turki]

Thank you for sharing this valuable information.
COVID-19 should be an opportunity to enterprise to think move forward with zero-trust and software-defined perimeter (SDP). 

[Gladys Rodriguez]

Agree with Zied about zero-trust.  I am not sure how software-defined perimeter can help.  Can you collaborate a bit more?

I think the Graph Security API (https://docs.microsoft.com/en-us/graph/security-concept-overview) can help vendors interconnect with each other and allow more granular policies to be implemented including:

• Is the user account compromised?
• Is the user account using MFA?
• Is the user connecting from on-prem or from outside?
• Is the user connecting from a US IP or maybe Russia?
• Is the system managed?
• Is the system compliance?
• Is the system showing Indication of Compromise?
• Is the data sensitive?

And others ..  This will start help environments to use deep verifications and true Zero Trust

[TonyJ25]

Could I get a clarification on something? In response to Q1 you say to send authentication traffic over the VPN. Does this mean that I could then use conditional access rules to determine that the connection is from a trusted network and allow access that way?

Thanks in advance.

[Paul Collinge]

HI @TonyJ25 

                        You are 100% correct. If you continue to send the authentication traffic down the VPN so it can be egressed through your corporate internet connection then IP based conditional access rules will continue to apply, even though the user is able to connect directly to the service endpoint for the split tunnelled (Optimize marked) endpoints.

For example you may set a rule that authentication tokens for your tenant are only issued if the auth request originates from an IP block you own. Obviously this will then cause remote users doing direct authentication to fail, as the source will be their ISP's IP address. 

However, authentication traffic is relatively low volume and not massively latency sensitive so is absolutely fine to continue to hairpin this through a corporate VPN. 

That way the only way someone outside your corporate network can get a token to access your Office 365 tenant is:

A. They have the correct credentials to do so

and also

B. They also have a device with the rights and configuration to be able to VPN into your corporate network to send the authentication request via there. 

If you're using Tenant restrictions to prevent authentication to untrusted tenants then this will also continue to apply if auth traffic is sent into the corporate network via the VPN, the proxy implementing the feature will continue to manage the traffic and apply the policies set. 

Once they have the relevant token, this can then be used to access the service endpoint directly via the split tunnel. This way we continue to ensure a high level of security whilst bypassing the VPN bottleneck for the high volume and latency sensitive traffic to/from the service.

You can obviously add other conditional access elements where necessary such as User Attributes, Device state, Application, Risk etc and make risk based decisions based on the results such as Block, Allow, Require MFA. https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview gives a good overview. 

Hope that helps!

[Ian_M10]

Hi @Paul Collinge, we currently have all O365 bound routed via our corporate VPN.  We also use Tenant Restrictions and must continue to use it.  We are looking to implement split tunnelling for when our users are remote working and I expect to route both the Optimize & the Allow categorised endpoints directly.  We will therefore still need to route the 3 Tenant Restrictions URLs via the VPN and out via our Proxy and will send the Default categorised endpoints also via VPN & Proxy.

At the same time we are looking to deploy PAC files so that when our users are in the office\within the corporate network the Optimize & Allow (minus the 3 Tenant Restriction URLs) bypass our Proxy and route direct via Firewalls.

My questions are:

1) Do we need a PAC file for proxy bypass to support our target remote working/spilt tunnelling solution?

2) If we do not need a PAC file, will the use of a PAC file impact our target remote working/spilt tunnelling solution?

3) If we do need a PAC file, will it need to be different from the PAC file that will be used when our users are in the office\within the corporate network?

Thanks in advance :-).

[reevesjeremy]

@Paul Collinge  Re: @TonyJ25 

How do we separate the authentication traffic from the general traffic in order to obtain the authentication token from the internal IPs?  Are authentications going over specific ports? Which are they?

Our Conditional Access rule is set with token expiration of 1 hour when off the corporate network.  If the primary traffic is coming from the users home local IP, I suspect even with split tunneling for authentication traffic, since general traffic is coming over the users local IP it will trigger more frequent authentication interruptions (WAM popups/white screen). Am I wrong?

Finally, how about Conditional Access rules for IPv6? There are none available, and we have users whose ISPs use IPv6 and no IPv4 addresses. Our VPN will issue them both IPv6 and IPv4 for internal network, but there are inherent issues with this approach when we cannot configure our corporate IPv6 range in the Conditional Access rules. Authentications fail over internal IPv6 addresses whcih could pose issues if split tunnel defers to the internal IPv6 for authentication.

Thanks for the guidance!

[Paul Collinge]

@reevesjeremy  

Authentication traffic uses TCP port 443 so are not possible to split out via unique port. You'll find the URLs in question in row 56 of the URL/IP service. The specific authentication URLs are login.microsoftonline.com, login.microsoft.com, login.windows.net. Ensure these are sent down the VPN tunnel to the proxy or similar if you want to ensure they are sent to Microsoft via your corporate network. 

In terms of the conditional access rule, if you only split tunnel the optimize marked traffic then the auth traffic will continue to arrive at AAD from your corporate network and the rules you've set for that scenario will continue to apply. i.e when the user requests a token, the request is routed via the on premises environment and thus the policies applied to that scenario are applied. 

As for IPV6, as these auth endpoints (the three listed above) do not have IPv6 addresses assigned to them the client cannot/will not attempt to connect to them over IPV6, rather it'll use IPV4.

[Paul Collinge]

@Ian_M10  

These questions are relatively hard to answer verbosely without knowing your full network configuration/VPN solution etc but I’ve done my best to answer as much as is possible below. I would strongly recommend you consult VPN vendor if possible for explicit guidance in case there are any additional steps required for the particular solution.

1. Do we need a PAC file for proxy bypass to support our target remote working/spilt tunnelling solution?

The answer depends on your environment, and configuration on handling HTTP/HTTPS traffic. If you need/want to send traffic to an explicit proxy within the corporate network, but route other traffic such as the Optimize marked Office 365 endpoints via the local interface on the remote client. then yes, a PAC file is likely necessary to make this split.

Any traffic you want to send direct via the internet should be configured in the PAC file to return DIRECT, located above any logic which sends traffic to the proxy, a very simple example is shown below sending the OPTIMIZE traffic direct, the rest to the proxy, elements in italics being tenant specific:

// Define proxy server

    var proxyserver = "PROXY 10.10.10.10:8080";

    // Make host lowercase

    var lhost = host.toLowerCase();

    host = lhost;

    }

        //EXPRESS ROUTE DIRECT

    else if ((isPlainHostName(host))

                        || (shExpMatch(host, "contoso.sharepoint.com")) 

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

                        || (shExpMatch(host, "outlook.office.com")) 

                        || (shExpMatch(host, "outlook.office365.com")) 

                   )

    {

        return "DIRECT";

    }

        //Catchall for all other traffic to proxy

    else

    {

        return proxyserver;

    }

}

Once this split is made on the PAC file the VPN client also needs to be configured to recognise the traffic you want to allow to go direct via the local interface/gateway to the internet.

For example traffic to the proxy IP address/name e.g. 10.1.1.2 (proxy.contoso.com) will be configured in the VPN client to be routed down the VPN tunnel. Normally you would configure all your internal IP space to use the VPN tunnel.

Traffic to outlook.office365.com or the IP subnets that URL publicly resolves to should then be routed direct out of the user’s internet connection. How this is configured in the VPN client depends on the VPN solution itself. UDP traffic to Teams should work automatically via the local interface if a path is available via the internet for the IP subnets. (52.112.0.0/14 and 13.107.64.0/18)

2. If we do not need a PAC file, will the use of a PAC file impact our target remote working/spilt tunnelling solution?

If you don’t need a PAC file you are likely using a transparent proxy or direct network egress, in this scenario, the VPN client needs to have the configuration so that the Optimize marked IP subnets are sent out of the local interface, i.e. excluded from the traffic sent down the VPN tunnel. I’d suspect this isn’t a scenario you’re using (i.e. you’re likely using an explicit proxy as per answer #1 and thus are using a PAC file)

3. If we do need a PAC file, will it need to be different from the PAC file that will be used when our users are in the office\within the corporate network?

The answer to this question depends again on your internal network configuration. Does the internal network have a direct network egress for the Optimize traffic? If not (i.e. internet browsing has to go via the proxy on the corporate network). If the network doesn’t have a local network egress then traffic sent direct will get dropped. In this scenario you’ll need a different PAC file for the remote clients, which should be easy to do based on the IP subnet the client has e.g.

Client has IP subnet 10.1.0.0/16 = Corpnet client > Corpnet PAC

Client has IP subnet 10.2.0.0/16 = VPN Client > Remote Worker PAC

Or you can use myipaddress()  function to point the client to different proxy nodes based on the Client IP range within the same PAC file.

If you do provide direct and local egress for the Optimize marked traffic from your corporate network (via SDWAN/Local Firewall etc) as per best practice, then you should not need a separate PAC file.

Hope that helps! 

Paul & the Office 365 network team

[Ian_M10]

Hi @Paul Collinge + O365 network team.  Thank you very much for the response - it is v useful and helps clarify a question that we were not 100% sure on.

[cedbl]

@Paul Collinge, concerning pac files

The myipaddress() is not always advised to detect VPN access.

Unfortunately, the function may return the first address of a workstation that may be the native address of the network it is connected to and not the one of your VPN.

I've seen blogs mentioning that one could only check if the workstation is in the corporate subnet. Such a partial check may not be sufficient in some situations.

Another way could be to base the decision on the presence of a site (DirectAccess style). DNS resolution in PAC files is not always recommended, either.

So if anyone has a solution, I am all ears!

[TobiA]

Hi, is there a guide on how to achieve that configuration with Windows AlwaysOn VPN? It would be easy to have a normal split tunnel (separating company traffic from internet traffic). But what I would like to have is a forced tunnel with excludes for the O365 IP ranges here (split tunnel only for Office 365, rest through the company firewall / proxy to the internet). In best case with the option to dynamically update the ranges if they change.

[Petri X]

@Paul Collinge 

Would you like to clarify about the issue on forced VPNs and why this one IP address (13.107.60.1) should be added into there. So far I have not been able found any other documentation for support for this.

Other thing which would be nice to know, when using a split tunnel only for media on Teams, then how long time it is expected that media is working if VPN close down? Small hick ups are not causing issues, and this improves end user experience. But wish to understand that more deeper.

[Domoffice365]

Are there any updates on this issue? 

[Petri X]

Hi @Paul Collinge  and others,

When speaking about Live Event and network optimization you have released following details:

Reaching viewers when you have a VPN split-tunneling configuration 

This unfortunately does not includes the endpoints, and perhaps because of that there is following text a bit later:

Note

The above guidance will not be helpful for customers with a VPN+proxy configuration. Microsoft is working on a solution for such scenarios.

Do you have any update when we perhaps could get the endpoint FQDNs for these IP addresses and get above note removed?

[Paul Collinge]

Hi@Petri X ,

                      The issue with Live Events/Stream is that they currently require a wildcard domain *.azureedge.net. This wildcard contains may other Azure based elements other than those two services, and to implement a forced tunnel exception you need both the FQDN and all corresponding IPs that FQDN resolves to. As this isnt the case here, anything outside Live Events/Stream that sits in this namespace would end up getting blocked as you dont have the IP for it. The Live Events team are working on moving the service to dedicated namespaces to facilitate the current remote working requirements but it wont be a quick thing to implement as you can imagine, so unfortunately i dont have an ETA to share at this time. That said, in the interim it should be possible with the IPs provided to offload the traffic using a PAC file, something like the following should do the job. Not ideal i admit, but it is an option.

Paul

function FindProxyForURL(url, host) 

{
    var direct = "DIRECT";
    var proxyServer = "PROXY 10.0.0.199:8080";

//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;
    }

//Put any other URL based rules here

var resolved_ip = dnsResolve(host);

/* Don't proxy Teams Live Event or Stream traffic*/

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

{

returndirect;

}

// Default Traffic Forwarding.
    return proxyServer;                
}

[Petri X]

Big thanks @Paul Collinge to share that!

It is indeed a big change to regular infrastructure as the amount of DNS request would goes to sky. Perhaps we could isolate this section only for the FQDNs related to this. But that increase the complexity even more.

I also would like to ask the clarification about the names, as you also refers to *.azureedge.net. But at least, at the moment when analyzing the browser traffic it looks like this:

So is azureedge.net a namespace for future use, or do you expect that it should b already in use? In my mind that is not yet.

[Paul Collinge]

@Petri X  the domain is used as a CDN amongst other things. You may see it used in some scenarios and not others, it's required for the service to operate though and is listed in row 44 of the URL/IP Web service for Stream.

[Petri X]

@Paul Collinge 

I thought to use rule like following to be able to impact only audio/video streams:

if(shExpMatch(host, "*.streaming.mediaservices.windows.net"))
{
	var host_ip = dnsResolve(host);
 
	/* Check if Stream services are targets */
	if (isInNet(host_ip, '72.21.81.200', '255.255.255.255') ||
	isInNet(host_ip, '152.199.19.161', '255.255.255.255') ||
	isInNet(host_ip, '117.18.232.200', '255.255.255.255') ||
	isInNet(host_ip, '192.16.48.200', '255.255.255.255') ||
	isInNet(host_ip, '93.184.215.201', '255.255.255.255') ||
	isInNet(host_ip, '68.232.34.200', '255.255.255.255') ||
	isInNet(host_ip, '192.229.232.200', '255.255.255.255'))
	{
		returndirect;
	}

    return proxyServer;                
}

Then I could minimize the DNS queries. And above code is just a snap, not full .PAC file :)

[Paul Collinge]

@Petri X  Thanks, that's useful information. We were actually working on something similar but couldnt use/share it until we finished testing and confirmed we had comprehensive FQDN information and incorporate changes from the Live events Engineering side. I've now got that and we have a working PAC file scoped to the Live Events/Stream FQDNs/IPs. I'll write it up in a new Techcommunity post and hopefully publish tomorrow. 

Thanks again for the feedback.

Paul

[Sergg]

Just a small hint for testing, if you want to see what is the actual adapter (and source IP) you application is using

Download and run currports.   You can add teams.exe as a filter. Or you can see all applications and what way they are going.

It shows all sessions and the source IP.

• If source ip vpn it is tunnelled
• If source ip lan it is direct.

https://www.nirsoft.net/utils/cports.html

Note:  it does not show destination IP for UDP, but shows the number of packets.

Alternative + description https://www.nirsoft.net/utils/live_tcp_udp_watch.html

• CurrPorts displays the current table of active TCP connections and TCP/UDP listening ports. but this technique has some disadvantages, for example, if UDP packets are sent from your computer to remote network address, you won't see it with CurrPorts, because with UDP there is no really a connection and the UDP table contains only listening UDP ports. The advantage of CurrPorts is the ability to use it without elevation (Run As Administrator).
• NetworkTrafficView uses network sniffing technique - It analyzes every packet sent/received by your network card and displays extensive summary according to the display mode you choose. The disadvantages of this tool: You have to choose a network card and capture method for activating the network sniffer.
• LiveTcpUdpWatch uses event tracing API to get live information from Windows Kernel about every TCP/UDP packet sent/received on your system. As opposed to CurrPorts, it captures all UDP activity with process information, but without the need of using a network sniffer.

[Petri X]

Thank you @Sergg  to share that tool.

Need to say, that I'm still fan of Microsoft Network Monitor 3.4 (archive) . Old and grey, but still powerful network monitor. The most powerful feature is of course possibility to filtering traffic based on the process(es). Microsoft had also the super powerful and great tool for network (and others): Microsoft Message Analyzer. Unfortunately that is also left without Microsoft's attention. Someone has once more had look about $$$'s and noticed that these tools brings zero dollars to MS, but good reputation from administrators. But as money speaks, we are using over ten years old tools  

[viny1991]

Hi @Paul Collinge ,

Has the traffic optimization document for Live Events already been published?

[Petri X]

@viny1991 

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

[Sergg]

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

[David Phillips]

Is there another way to remotely verify traffic is egressing the local connection outside of using Netmon / Wireshark to monitor packets?

[viny1991]

@David Phillips, you can also use Microsoft's own Process Monitor which offers a very friendly and easy to understand interface

[Neiluk]

@Paul Collinge We have implemented split tunnel for Teams and now looking to do Exchange Online one issue we have come across is that delegate rights on mailboxes is now failing as authentication traffic for that seems to go outside of the tunnel. We know normal authentication goes inside over our VPN as our CA rules do not trigger when launching applications. 

Also noticed Outlook is not adhering to a 60 minute token refresh so unless you restart outlook you can send and receive mail even if our VPN is disconnected for a day which other applications do adhere too.

Any suggestions would be appreciated.

[Petri X]

Hi @Paul Collinge ,

Any possibilities to you to clarify this IP address:

13.107.60.1/32

How long time we should allow traffic into there?

Microsoft's Solution-Deployment have a script which only have a comment:

# Temporarily include additional IP address until Teams client update is released
$optimizeIpsv4 += "13.107.60.1/32"

What is the Teams client version this is referring?

[Paul Collinge]

@Petri X  it's no longer needed. The version of Teams required to work without it is outlined in the article on this subject which we maintain, specifically this section. https://docs.microsoft.com/en-us/office365/enterprise/office-365-vpn-implement-split-tunnel#configur...

[Petri X]

@Paul Collinge 

You were quick ! 

Big thanks for clarifying this.

[ukazim]

@Paul Collinge I have been scouring through blogs and documentation but I am not able to find IP Ranges for officecdn to use for Office 365 Updates. We are unfortunately have a limitation where we need to split tunnel our Office 365 Updates to use public internet for clients connected over VPN. Our original plan was to use CMG to deploy the updates but turns out Office 365 Updates are not supported over CMG\cloud Distribution points. The only alternative is to allow our clients to download the updates over the internet but in order to do that we need the IP ranges for the office CDN. We are currently running Windows Upgrades over our CMG. Any thoughts on how to over come this?