Edit

Securing Teams media traffic for VPN split tunneling

  • Article

Note

This article is part of a set of articles that address Microsoft 365 optimization for remote users.

Some Microsoft Teams administrators might require detailed information on how call flows operate in Teams using a split tunneling model and how connections are secured.

Configuration

For both calls and meetings, as long as the required Optimize IP subnets for Teams media are correctly in place in the route table, when Teams calls the GetBestRoute function to determine which local interface corresponds to the route it should use for a particular destination, the local interface will be returned for Microsoft destinations in the Microsoft IP blocks listed above.

Some VPN client software allows routing manipulation based on URL. However, Teams media traffic has no URL associated with it, so control of routing for this traffic must be done using IP subnets.

In certain scenarios, often unrelated to Teams client configuration, media traffic still traverses the VPN tunnel even with the correct routes in place. If you encounter this scenario, then using a firewall rule to block the Teams IP subnets or ports from using the VPN should suffice.

Important

To ensure Teams media traffic is routed via the desired method in all VPN scenarios, please ensure users are running Microsoft Teams client version 1.3.00.13565 or greater. This version includes improvements in how the client detects available network paths.

Signaling traffic is performed over HTTPS and isn't as latency sensitive as the media traffic and is marked as Allow in the URL/IP data and thus can safely be routed through the VPN client if desired.

Note

Microsoft Edge 96 and above also supports VPN split tunneling for peer-to-peer traffic. This means customers can gain the benefit of VPN split tunneling for Teams web clients on Edge, for instance. Customers who want to set it up for websites running on Edge can achieve it by taking the additional step of disabling the Edge WebRtcRespectOsRoutingTableEnabled policy.

Security

One common argument for avoiding split tunnels is that It's less secure to do so, i.e any traffic that doesn't go through the VPN tunnel won't benefit from whatever encryption scheme is applied to the VPN tunnel, and is therefore less secure.

The main counter-argument to this is that media traffic is already encrypted via Secure Real-Time Transport Protocol (SRTP), a profile of Real-Time Transport Protocol (RTP) that provides confidentiality, authentication, and replay attack protection to RTP traffic. SRTP itself relies on a randomly generated session key, which is exchanged via the TLS secured signaling channel. This is covered in great detail within this security guide, but the primary section of interest is media encryption.

Media traffic is encrypted using SRTP, which uses a session key generated by a secure random number generator and exchanged using the signaling TLS channel. In addition, media flowing in both directions between the Mediation Server and its internal next hop is also encrypted using SRTP.

Skype for Business Online generates username/passwords for secure access to media relays over Traversal Using Relays around NAT (TURN). Media relays exchange the username/password over a TLS-secured SIP channel. It's worth noting that even though a VPN tunnel may be used to connect the client to the corporate network, the traffic still needs to flow in its SRTP form when it leaves the corporate network to reach the service.

Information on how Teams mitigates common security concerns such as voice or Session Traversal Utilities for NAT (STUN) amplification attacks can be found in 5.1 Security Considerations for Implementers.

You can also read about modern security controls in remote work scenarios at Alternative ways for security professionals and IT to achieve modern security controls in today's unique remote work scenarios (Microsoft Security Team blog).

Testing

Once the policy is in place, you should confirm It's working as expected. There are multiple ways of testing the path is correctly set to use the local Internet connection:

  • Run the Microsoft 365 connectivity test that will run connectivity tests for you including trace routes as above. We're also adding in VPN tests into this tooling that should also provide additional insights.

  • A simple tracert to an endpoint within scope of the split tunnel should show the path taken, for example:

    tracert worldaz.tr.teams.microsoft.com

    You should then see a path via the local ISP to this endpoint that should resolve to an IP in the Teams ranges we have configured for split tunneling.

  • Take a network capture using a tool such as Wireshark. Filter on UDP during a call and you should see traffic flowing to an IP in the Teams Optimize range. If the VPN tunnel is being used for this traffic, then the media traffic won't be visible in the trace.

Additional support logs

If you need further data to troubleshoot, or are requesting assistance from Microsoft support, obtaining the following information should allow you to expedite finding a solution. Microsoft support's TSS Windows CMD-based universal TroubleShooting Script toolset can help you to collect the relevant logs in a simple manner. The tool and instructions on use can be found at https://aka.ms/TssTools.

Overview: VPN split tunneling for Microsoft 365

Implementing VPN split tunneling for Microsoft 365

Common VPN split tunneling scenarios for Microsoft 365

Special considerations for Stream and live events in VPN environments

Microsoft 365 performance optimization for China users

Microsoft 365 Network Connectivity Principles

Assessing Microsoft 365 network connectivity

Microsoft 365 network and performance tuning

Alternative ways for security professionals and IT to achieve modern security controls in today's unique remote work scenarios (Microsoft Security Team blog)

Enhancing VPN performance at Microsoft: using Windows 10 VPN profiles to allow auto-on connections

Running on VPN: How Microsoft is keeping its remote workforce connected

Microsoft global network