Design and validate VPN split tunneling
VPN Split tunneling is a method that allows certain endpoints to bypass the VPN tunnel and connect directly to the Microsoft 365 service from the user's location. This allows the Teams media traffic to be forced out of the VPN tunnel and directly to Microsoft 365. It also frees up capacity for important business traffic and eliminates the need for expensive upgrades.
VPN Split tunneling
A client virtual private network (VPN) allows traffic from a client or user; for example, a remote laptop user, to make a virtual point-to-point encrypted tunnel connection to a remote server, usually connecting them to the organization’s network. This allows access to resources on the organization’s network.
VPN tunneling is where all remote clients route their traffic over an encrypted tunnel back to the organization’s network before being routed onto the internet. This model was designed when most organizations had most of the resource’s users needed on servers on-premises and some traffic went to the internet.
However, with more resources “in the cloud” or on the internet, sending all client traffic from the client to the organization's network before breakout onto the internet is suboptimal. Therefore, if you use a client VPN, Microsoft recommends letting Teams and Office 365 traffic bypass the VPN and go directly to the internet from the client machine, commonly known as split-tunnel VPN.
Microsoft strongly recommends against sending Teams traffic over a VPN, for the following reasons:
VPNs are typically not designed or configured to support real-time media, and some don't support UDP, which is the optimum transport protocol for media traffic.
VPNs cause teams traffic to take a suboptimal route into the organization’s network before going onto the internet.
VPNs also introduce an extra layer of encryption on top of media traffic that's already encrypted.
Save load on your VPN and avoid it becoming a choke point for network traffic. This can be a real challenge with the amount of audio and video traffic teams generates.
In a split tunnel configuration, only a subset of traffic is routed over the VPN. You can either explicitly specify routes to exclude from the VPN or explicitly include routes to go over the VPN. If the VPN is used to connect to specific servers/services within the organizational network, it can be easier to configure the VPN to only route traffic for those specific IP addresses or subnets.
If your organization generally prefers to route internet traffic onto the organization's network, through the organization's proxies and firewalls before going onto the internet, you might want to exclude the specific Microsoft 365 addresses from the VPN route. Microsoft supplies a list of all Microsoft 365 IP addresses that you should exclude from your VPN.
Note
The services and IP address are constantly evolving; so, if choosing to explicitly exclude the Office 365 services from your VPN, you will need to check and update this configuration regularly.
In this picture, we see a split tunnel VPN. Traffic for Microsoft 365 is intentionally excluded from the VPN tunnel directly from the user to the service over their local internet connection. All other traffic is sent over the VPN to the organization's network.
How you configure your VPN depends on which VPN client software you or your organization require you to use, but split-tunneling is a functionality all common third party vendors are providing.
Important
Some organizations have policies that require every user to send all incoming and outgoing traffic over firewall appliances, and a split-tunneling can possibly violate these policies. Check what your organizations policies are and ensure you have policy approval for this configuration.
Validate VPN Split tunneling
Once you configure split tunneling, you can validate the configuration in a few different ways. A simple tracert in PowerShell on a remote VPN connected client machine to an endpoint/address that is configured to go directly to the internet, not via the VPN, should show that the path taken is directly via the clients ISP, not the VPN.
tracert worldaz.tr.teams.microsoft.com
The result shows you the different hops your packets going to take to reach the destination:
Tracing route to b-tr-teasc-euno-13.northeurope.cloudapp.azure.com [52.114.251.234]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms localrouter.box [192.168.10.1]
2 8 ms 53 ms 7 ms vt1.cor2.lond2.ptn.zen.net.uk [51.148.72.24]
3 8 ms 7 ms 8 ms lag-8.p1.ixn-lon.zen.net.uk [51.148.73.188]
4 8 ms 7 ms 7 ms lag-2.p1.thn-lon.zen.net.uk [51.148.73.132]
5 8 ms 7 ms 7 ms lag-1.br1.thn-lon.zen.net.uk [51.148.73.153]
6 9 ms * * 104.44.6.57
7 9 ms 22 ms 22 ms ae29-0.icr01.lon24.ntwk.msn.net [104.44.41.162]
8 18 ms 144 ms 18 ms be-100-0.ibr01.lon24.ntwk.msn.net [104.44.21.107]
9 18 ms 18 ms 18 ms be-3-0.ibr01.dub08.ntwk.msn.net [104.44.30.47]
10 18 ms 39 ms 17 ms ae102-0.icr02.dub08.ntwk.msn.net [104.44.11.66]
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * *
In this test, the remote client Internet service provider is called “Zen.” We can see we hop over addresses on the zen.net.uk network directly to Microsoft without going via a VPN. Look for names that relate to the relevant client ISP.
If you see this traceroute routing to the VPN, which you can recognize by seeing your VPN FQDN and IP addresses, you need to configure the VPN correctly for split tunneling.
It's normal for you to see “Request timed out” on the later hops. The destination’s firewall or other security device is blocking the traceroute request. Even if a firewall is preventing the final hops at the destination from showing up in traceroute output, the destination is likely still reachable, but configured not to reply to a traceroute.
Note
In certain scenarios, often unrelated to Teams client configuration, media traffic still traverses the VPN tunnel even with the correct client routes in place. If you encounter this scenario, you can configure firewall rule to block the Teams IP subnets or ports from using the VPN route.